Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
peterzhuamazon opened this issue Dec 6, 2023 · 3 comments
Open

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

peterzhuamazon opened this issue Dec 6, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@peterzhuamazon
Copy link

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

@karianna
Copy link
Contributor

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

@xavierfacq
Copy link
Member

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: 👇
image

@johnoliver
Copy link
Contributor

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.

froque added a commit to froque/crawler that referenced this issue Apr 1, 2024
api.adoptium.net may respond with a duplicate release name if a new build
was required [1]. In this case, adopt_build_number should be present and
incremented.

> 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.

[1] adoptium/api.adoptium.net#829

Should fix JENKINS-72319 Unable to install JDK 21.0.
MarkEWaite added a commit to jenkins-infra/crawler that referenced this issue Apr 1, 2024
* Merge JDK release binaries if it shares a release name

api.adoptium.net may respond with a duplicate release name if a new build
was required [1]. In this case, adopt_build_number should be present and
incremented.

> 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.

[1] adoptium/api.adoptium.net#829

Should fix JENKINS-72319 Unable to install JDK 21.0.

* Update adoptopenjdk.groovy

Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>

---------

Co-authored-by: Mark Waite <mark.earl.waite@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants