adoptium / marketplace-api.adoptium.net

Adoptium Marketplace API 🚀

Adoptium marketplace

This repo contains:

• adoptium-marketplace-schema
  • Schema definition for vendors to advertise their binaries
• adoptium-marketplace-client
  • Client library for reading a repository with vendor data
• adoptium-marketplace-server
  • Implementation of the adoptium marketplace API
• exampleRepositories
  • Examples of a vendor repository

Build

Build with

./mvnw clean install

Testing

Tests rely on the data inside the exampleRepositories directory in order for tests to pass they must be signed. If you wish to modify test assets they need to be re-signed once they have been modified. The procedure would be as follows:

• Generate test keys
  • Look in the exampleRepositories/keys directory for scripts that detail generating keys
• Re-sign assets
  • Run SignTestAssets in the adoptium-marketplace-utils project.

Repository validation

A repository can be validated using the MarketplaceClient. The client pulls a repository and validates its contents. For example:

    String publicKey = "-----BEGIN PUBLIC KEY-----\n" +
    // Public key string here
    "-----END PUBLIC KEY-----";
    String repoUrl = "http://localhost:8080/repo";

    try {
        MarketplaceClient client = MarketplaceClient.build(repoUrl, SignatureType.BASE64_ENCODED, publicKey);
        ReleaseList releaseList = client.readRepositoryData();
    
        System.out.println("Found: " + releaseList.getReleases().size() + " releases");
    } catch (Exception e) {
        System.err.println("Validation failed");
        e.printStackTrace();
    }

Note that in this example we have used the default SignatureType.BASE64_ENCODED which specifies that the signature files are base64 encoded. If you require non-base64 encoded use SignatureType.SIG.

An example of running this can be seen in RepoTest class in the adoptium-marketplace-client module. To validate your repo using this test, edit it to add your public key and repo location, then run with:

VALIDATE_REPO=true ../mvnw test -Dtest=RepoTest#validateRepo

from inside the adoptium-marketplace-client directory.

marketplace-api.adoptium.net's Issues

adoptium-marketplace-staging-checker broken

The automated check just failed when trying to verify the April 2024 marketplace update:

• PR: rh-openjdk/marketplace#44
• Test run: https://github.com/rh-openjdk/marketplace/actions/runs/8757709430/job/24036958248?pr=44

Error:  Failed to execute goal io.quarkus:quarkus-maven-plugin:3.10.0.CR1:build (default) on project adoptium-marketplace-staging-checker: Execution default of goal io.quarkus:quarkus-maven-plugin:3.10.0.CR1:build failed: An API incompatibility was encountered while executing io.quarkus:quarkus-maven-plugin:3.10.0.CR1:build: java.lang.NoSuchMethodError: 'void io.quarkus.bootstrap.app.JarResult.<init>(java.nio.file.Path, java.nio.file.Path, java.nio.file.Path, java.lang.String, java.lang.String)'

certification archive lacks sha256sum line in json file

where

"package": {
                        "name": "java-17-openjdk-17.0.3.0.7-4.portable.jdk.el.x86_64.tar.xz",
                        "link": "https://openjdk-sources.osci.io/marketplace/17/java-17-openjdk-17.0.3.0.7-4.portable.jdk.el.x86_64.tar.xz",
                        "sha265sum": "47156f0eaba955602c9249054aa7e69a32e71de91d96359a0a3b672980d0f10d"
                    },

Allow marketplace to identify change in LINK by changing sum, the

 "aqavit_results_link": "https://openjdk-sources.osci.io/marketplace/17/java-17-openjdk-17.0.3.0.7-4.portable.jdk.el.x86_64.cert.tar.gz"

Is lacking this, and thus not allow the marektpalce to recognize the change in the aqavit_results_link, even allows to forge the results.

Can we have aqavit_results_sha265sum field and appropriate logic, which allows updating the results if overwritten?

Reorganize the tap result link aqavit_tapresult_link

Is your feature request related to a problem? Please describe.
Currently the marketplace test result link is designed per each binary (for example: "aqavit_results_link" : "https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.6%2B10/OpenJDK17U-jdk_x64_linux_hotspot_17.0.6_10.tap.zip","). As discussed and implemented in Ensure we are pushing AQAvit TAP files to the binaries repository for each release there will only be one final AQAvit TAP file per release ( for example https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.6%2B10/AQAvitTapFiles.tar.gz), most often for now the tap file will be uploaded to the release repo after all tests are triaged. We'd like to update the api query https://api.adoptium.net/v3/assets/feature_releases/${version}/ga?page_size=50&vendor=eclipse to get the aqavit_tapresult_link if AQAvitTapFiles.tar.gz is available.

Describe the solution you'd like
With that enabled and PR like https://github.com/adoptium/api.adoptium.net/compare/marketplace...sophia-guo:marketplace?expand=1 Marketplace-data can be auto updated by workflow https://github.com/adoptium/marketplace-data/blob/main/.github/workflows/temurin-updater.yml

Describe alternatives you've considered
Or any other solutions suggested, maybe the issue #34?

Additional context
Add any other context or screenshots about the feature request here.

Consider adding license identifier to the marketplace schema

The marketplace is open to binaries with different licenses, and it may be useful for clients to interrogate the license of the binary being offered.

Consider adding a String field to the Release information that allows publishers to provide the SPDX license identifier.

This is just an idea for discussion, I don't have a specific use case requiring it.

Use of scm_ref and openjdk_scm_ref in marketplace JSON

I'm not clear on how these two fields within the JSON file are meant to be used, especially as there is no reference to the repository which these references resolve against.

I'm guessing openjdk_scm_ref is intended to resolve against the upstream OpenJDK GitHub repository for that release (e.g. https://github.com/openjdk/jdk17u for 17) but I have no idea with scm_ref. Even the former is problematic for us with 8u, as we use https://github.com/openjdk/shenandoah-jdk8u rather than https://github.com/openjdk/jdk8u

Are these actually intended to be consumed in some way by the marketplace? Would it be worth having corresponding links to the repository in openjdk_scm and scm?

Consider a workflow that automatically alerts to the presences of new TAP results

Is your feature request related to a problem? Please describe.
This is a feature request that would benefit all vendors listing in the marketplace. The QSVL states that vendors need to send an email to [email protected] upon uploading of new TAP files to the marketplace. Having a workflow at the marketplace API that automatically does this would alleviate the need for each vendor to do this independently.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.