api.adoptium.net icon indicating copy to clipboard operation
api.adoptium.net copied to clipboard

api.adoptium.net broke with two list for 21.0.1+12

Open peterzhuamazon opened this issue 2 years ago • 3 comments

Please provide a brief summary of the bug

See this report: https://issues.jenkins.io/browse/JENKINS-72319

We have the same issue here that we cannot use jenkins global tools to install, due to the issues with the api return.

Thanks.

Please provide steps to reproduce where possible

See error: https://build.ci.opensearch.org/blue/organizations/jenkins/publish-opensearch-min-snapshots/detail/publish-opensearch-min-snapshots/432/pipeline/

Expected Results

Able to install the macos artifact on x64 mac with hotspot temurin 21.

Actual Results

Not able to found the binary, and there are two list of the 21.0.1+12.

What Java Version are you using?

21.0.1+12

What is your operating system and platform?

No response

How did you install Java?

No response

Did it work before?

No response

Did you test with the latest update version?

No response

Did you test with other Java versions?

No response

Relevant log output

No response

peterzhuamazon avatar Dec 06 '23 22:12 peterzhuamazon

@johnoliver suspect this is an issue with the Jenkins plugin but can you check to see our API is being consistent?

karianna avatar Dec 11 '23 04:12 karianna

Binaries of version jdk-21.0.1+12 are effectively not grouped under the same result, the Windows one outside of the rest. (see above)

Maybe a solution is to append the expected os and architecture to the REST call.

https://api.adoptium.net/v3/assets/feature_releases/21/ga?image_type=jdk&project=jdk&os=mac&architecture=x64

Current results when not specified: :point_down: image

xavierfacq avatar Dec 30 '23 11:12 xavierfacq

This is expected behaviour, the two versions of the releases are:

        "version_data": {
            "adopt_build_number": 1,
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1+12-LTS",
            "optional": "LTS",
            "security": 1,
            "semver": "21.0.1+12.1.LTS"
        }

and


        "version_data": {
            "build": 12,
            "major": 21,
            "minor": 0,
            "openjdk_version": "21.0.1+12-LTS",
            "optional": "LTS",
            "security": 1,
            "semver": "21.0.1+12.0.LTS"
        }

Note that they have different adopt_build_number, in effect openjdk_version to Adoptium releases are not 1:1 within the API, and therefore will be grouped into different release lists. As in this case we might re-spin a release, this would modify the adopt_build_number but would map to the same openjdk_version since they are built from the same tag of the OpenJDK repo, and would map to the same version in the upstream project.

The solution would be to either search all releases for the asset you are looking for, or as @xavierfacq says, make your query more specific to ensure that all returned releases contain an asset that meets your requirements.

johnoliver avatar Jan 02 '24 13:01 johnoliver