adoptium / api.adoptium.net Goto Github PK

Is your feature request related to a problem? Please describe.

Currently, all files have checksums.
To see what I mean, consider this API call:
https://api.adoptium.net/v3/assets/version/8.0.302%2B8?architecture=x64&heap_size=normal&image_type=jdk&jvm_impl=hotspot&lts=true&os=linux&page=0&page_size=10&project=jdk&release_type=ga&sort_method=DEFAULT&sort_order=DESC&vendor=adoptium

[
    {
        "binaries": [
            {
                "architecture": "x64",
                "download_count": 16509,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "hotspot",
                "os": "linux",
                "package": {
                    "checksum": "cc13f274becf9dd5517b6be583632819dfd4dd81e524b5c1b4f406bdaf0e063a",
                    "checksum_link": "https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u302-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u302b08.tar.gz.sha256.txt",
                    "download_count": 16509,
                    "link": "https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u302-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u302b08.tar.gz",
                    "metadata_link": "https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u302-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u302b08.tar.gz.json",
                    "name": "OpenJDK8U-jdk_x64_linux_hotspot_8u302b08.tar.gz",
                    "size": 102954777
                },
                "project": "jdk",
                "scm_ref": "jdk8u302-b08",
                "updated_at": "2021-07-29T19:22:53Z"
            }
        ],
        "download_count": 30952,
        "id": "MDc6UmVsZWFzZTQ3MDAwOTkx.ZZ5uD1yix/X1Qg==",
        "release_link": "https://github.com/adoptium/temurin8-binaries/releases/tag/jdk8u302-b08",
        "release_name": "jdk8u302-b08",
        "release_type": "ga",
        "timestamp": "2021-07-29T19:22:38Z",
        "updated_at": "2021-07-29T19:22:38Z",
        "vendor": "adoptium",
        "version_data": {
            "build": 8,
            "major": 8,
            "minor": 0,
            "openjdk_version": "1.8.0_302-b08",
            "security": 302,
            "semver": "8.0.302+8"
        }
    }
]

Describe the solution you'd like

Like maven artefacts, the builds should have GnuPG and/or X509 signatures.
There would also be the need of a file with all the signatures if using PGP, e.g. like so:
https://github.com/mojohaus/mojohaus.github.io/blob/441259e6a034798b390dbea54e9c5ce4b04af30e/src/site/resources/KEYS

For X509, users would need a trusted PKI.

Describe alternatives you've considered

None. Authenticity and correct transfer are currently only done via TLS. However, an attacker could forge the checksum as well if he gained access to the artifact storage.

Additional context

It would be nice to set up a policy (and a check!) that marketplace releases also must have a signature.

Describe the bug
The two links in NOTICE don't work.

To Reproduce
Steps to reproduce the behavior:

Go to https://api.adoptopenjdk.net/q/swagger-ui/
Click on v3 issue tracker or https://api.adoptopenjdk.net/README links.
Expected behavior
Clicking on the links takes you to the relevant page. Instead it appears the target of the anchor tags has been incorrectly generated:
https://api.adoptopenjdk.net/%22https://github.com/AdoptOpenJDK/openjdk-api-v3/issues/new/%22
https://api.adoptopenjdk.net/%22https://api.adoptopenjdk.net/README/%22

Screenshots
image

Inspecting the above in Edge:
image

Device (please complete the following information):

OS: Windows
Browser Edge
Version 94.0.992.31

This is related to adoptium/temurin-build#2728

For AdoptOpenJDK upstream releases the assets/feature_version/<version>/ea API endpoint return a source item pointing to the source tarball. This is missing for the Adoptium API. However, the "sources" artefact is there for EA JDK 8. See:
https://github.com/adoptium/temurin8-binaries/releases/tag/jdk8u-2021-10-12-04-24-beta

Upstream:

$ curl -s 'https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ea?vendor=openjdk' | jq '.[0] | .source'
{
  "link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u312-b06/OpenJDK8U-sources_8u312b06_ea.tar.gz",
  "name": "OpenJDK8U-sources_8u312b06_ea.tar.gz",
  "size": 89749272
}

Adoptium:

$ curl -s 'https://api.adoptium.net/v3/assets/feature_releases/8/ea?vendor=eclipse' | jq '.[0] | .source'
<nothing>

Describe the bug
Go to https://api.adoptium.net in order to access the swagger UI. It returns an HTTP/403

Screenshots

Device (please complete the following information):

• OS: [e.g. Linux, MacOS, Windows, iOS, Android] LInux
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22] 101.0

Additional context
Add any other context about the problem here.

To be consistent with the terminology used elsewhere, the API should describe the Eclipse Temurin vendor as "Eclipse" or possibly "Eclipse Foundation" / "eclipse" etc. and not "Adoptium".

Given the API is already live, it may be desirable to allow "adoptium" as an alias for "eclipse" for some time so as not to break existing users.

currently, the adoptium api is pulling adoptopenjdk docker image pull stats. We will likely need to delete the database and modify the adoptium one to only pull https://hub.docker.com/v2/repositories/library/eclipse-temurin/

See the download dashboard for context: https://deploy-preview-72--eclipsefdn-adoptium-dash.netlify.app/

Currently, we have to manually deploy API changes to AKS. We should automate the redeploys when changes are pushed

During a discussion with @johnoliver we talked about how it would be good to add a load testing capability to the project. The goal of this being to understand the current throughput that the API can handle.

Some initial thoughts are:

it would be nice if the tests were driven from the OpenAPI docs
possibly use Gatling or JMeter

Is your feature request related to a problem? Please describe.
While we do have endpoints that give us links for binary downloads I wasn't able to find anything the provides a checksum to verify against

Describe the solution you'd like
An endpoint that returns the checksum. Probably the same one that returns the binary but with an additional parameter that specifies the request is for a checksum

Describe alternatives you've considered
One alternative is to capture the redirect and append .sha256.txt at the end of the github url which happily returns the same but that isn't very user friendly

Describe the bug
The Swagger UI is not available as the response has 404 status code.

To Reproduce
Steps to reproduce the behavior:

1. Visit https://api.adoptium.net/swagger-ui as pointed by https://api.adoptium.net

Expected behavior

1. Displays Swagger UI for the API documentation

Screenshots

Device (please complete the following information):

• OS: macOS 11.6
• Browser: Chrome
• Version: 93.0.4577.82

Additional context
N/A

Is your feature request related to a problem? Please describe.
There is a new feature in the build scripts which allows one to produce source tarball snapshots (--create-source-archive switch). This is similar to upstream's releases here:
https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.13%2B6

For example OpenJDK11U-sources_11.0.13_6_ea.tar.gz. Yet, there is no good way via the API to be able to retrieve such a tarball. E.g. via a fictitious curl command such as:

$ curl -sL https://api.adoptium.net/v3/sources/latest/11/ga

Describe the solution you'd like
Define a new sources API which maps to downloading a source archive for a specific build.

Please update the marketplace scripts that pull in new build information from the new Microsoft repository. The details of the repository location and public key are given in the marketplace request.

Describe the bug
The feedback from the site is confusing at best.

• The generated URL's that report "TypeError: NetworkError when attempting to fetch resource (no 404 code)" work in applications
• The generated URL's that report a 404 code: Error: Not Found also give a short header block.
• So, it seems like everything you try using swagger is an error, and is quite frustrating!
  To Reproduce
  Steps to reproduce the behavior:

1. Go to https://api.adoptium.net/q/swagger-ui/#/Binary/getBinary
2. Click on 'Try it Out'
3. Fill in your choices:
   
4. Click 'Execute'
5. See error
   
   Expected behavior
   A clear and concise description of what you expected to happen.

• Something similar to the linux-x86 output
  

Screenshots
If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

• OS: [e.g. Windows]
• Browser [e.g. firefox]
• Version [e.g. 97.0.1 64-bit]

Additional context
Basically, if I see this:

• it is an unsupported feature_version, e.g., 10
• implying, unsupported is better supported by swagger than supported feature_versions

The repository README file still refers to the AdoptOpenJDK API, and should be updated to reflect the new adoptium.net API.

This might be related to adoptium/ci-jenkins-pipelines#194

$ curl -v https://api.adoptium.net/v3/binary/latest/17/ea/windows/x64/jdk/hotspot/normal/adoptium
*   Trying 20.62.244.126:443...
* Connected to api.adoptium.net (20.62.244.126) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=api.adoptium.net
*  start date: Aug 14 11:29:17 2021 GMT
*  expire date: Nov 12 11:29:15 2021 GMT
*  subjectAltName: host "api.adoptium.net" matched cert's "api.adoptium.net"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET /v3/binary/latest/17/ea/windows/x64/jdk/hotspot/normal/adoptium HTTP/1.1
> Host: api.adoptium.net
> User-Agent: curl/7.76.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Date: Fri, 01 Oct 2021 18:32:18 GMT
< Content-Type: application/octet-stream
< Content-Length: 174
< Connection: keep-alive
< 
* Connection #0 to host api.adoptium.net left intact
{"errorMessage":"Multiple binaries match request: [OpenJDK17U-jdk_x64_windows_hotspot_2021-09-29-04-45.zip, OpenJDK17U-static-libs_x64_windows_hotspot_2021-09-28-23-30.zip]"}

Note that since September 29 static-libs are being produced by builds.

Describe the bug
API's are still reporting the latest LTS as JDK 11

To Reproduce
Steps to reproduce the behavior:

❯ curl -X 'GET' \
>   'https://api.adoptium.net/v3/info/available_releases' \
>   -H 'accept: application/json'

{
    "available_lts_releases": [
        8,
        11
    ],
    "available_releases": [
        8,
        11,
        16,
        17
    ],
    "most_recent_feature_release": 17,
    "most_recent_feature_version": 17,
    "most_recent_lts": 11,
    "tip_version": 18
}

Expected behavior
This is what I think it should look like:

{
    "available_lts_releases": [
        8,
        11,
        17
    ],
    "available_releases": [
        8,
        11,
        16,
        17
    ],
    "most_recent_feature_release": 17,
    "most_recent_feature_version": 17+35,
    "most_recent_lts": 17,
    "tip_version": 18
}

To allow clients, including the marketplace website, to determine that a build is older than the latest security update for a given OpenJDK release, it would be desirable to have a field that shows which OpenJDK source tag the binary is based upon.

While publishers may have their own patches, and therefore the binary may not be exactly built from a specific OpenJDK tagged source, this is is probably the best mechanism for clients to know if a binary contains the latest security vulnerability fixes.

Vendors need to publish information about the JVMs they are distributing, that need to be included in the marketplace API. In order to do this they need to make that data available in a well defined structured format that the market place API can consume. Define a schema for this data.

Describe the bug
The API is returning OpenJDK 19 releases when specifying release_type=ga. This is reflected in the response JSON, for example:
https://api.adoptium.net/v3/assets/release_name/eclipse/jdk-19%2B36-RC1-beta?architecture=x64&heap_size=normal&image_type=jdk&jvm_impl=hotspot&os=linux&project=jdk

{
  ...
  "release_link": "https://github.com/adoptium/temurin19-binaries/releases/tag/jdk-19%2B36-RC1-beta",
  "release_name": "jdk-19+36-RC1-beta",
  "release_type": "ga",
  "version_data": {
    "build": 36,
    "major": 19,
    "minor": 0,
    "openjdk_version": "19-beta+36-pre",
    "optional": "pre",
    "pre": "beta",
    "security": 0,
    "semver": "19.0.0-beta+36.0.pre"
  }
}

To Reproduce
Visit https://api.adoptium.net/v3/assets/version/%5B8%2C%29?release_type=ga&jvm_impl=hotspot&heap_size=normal&os=windows&architecture=x64&image_type=jdk&project=jdk&vendor=eclipse&page_size=1&sort_order=DESC

This should (as of today) return the most recent 18 GA release, but instead returns a beta 19 release.

Additional context
See related issue: ScoopInstaller/Java#419

Describe the bug

docker-compose up will run into missing dependencies

To Reproduce
Steps to reproduce the behavior:

1. Clone repo
2. docker-compose up

Expected behavior

Docker containers will come up.

Screenshots

n/a

Device (please complete the following information):

• OS: Linux
• Version current main

Additional context

Workaround: Will build fine using mvnw clean install in Dockerfile, which is a code smell.

Describe the bug
Certificate has expired that is why we can not install java versions through the action. Sorry, If it's not right place to report. Could you please take a look on it, because it breaks all the builds using adoptium.

Could you please take a look on it, because it's critical for us.
To Reproduce

• https://api.adoptium.net/
• actions/setup-java#248

Expected behavior Update certificate.

Screenshots

Device (please complete the following information):

• OS: [e.g. Linux, MacOS, Windows, iOS, Android]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

The result of /v3/info/release_versions doesn't contains enough information to construct a download request.

Result:

{
  "versions": [
    {
      "major": 0,
      "minor": 0,
      "security": 0,
      "patch": 0,
      "pre": "string",
      "adopt_build_number": 0,
      "semver": "11.0.0+28",
      "openjdk_version": "11.0.4+10-201907081820",
      "build": 0,
      "optional": "string"
    }
  ]
} 

Solution 1: Contain all attributes to create the Installer/Binary request

Solution 2: Include the url for installer / binary request

Describe the bug

HTML tags in hints in input fields, see screenshot.

To Reproduce
Steps to reproduce the behavior:

1. Go to api.adoptium.net
2. Click on swagger docs
3. Scroll down to any API call with input fields
4. See html tags

Expected behavior

formatting

Screenshots

Device (please complete the following information):

any

Additional context

Will file a PR later today

Should be a case of crawling all repos that are returned in https://github.com/search?p=1&q=https%3A%2F%2Fapi.adoptopenjdk.net%2Fv2&type=Code

Is your feature request related to a problem? Please describe.
IBM Has released 2 versions of the Semeru Runtimes, Open Edition and Certified Edition. Open Edition is released under the standard GPL v2 +CE License and Certified Edition is released under IBM Commercial License. We would like to have both versions be available via the API.

Describe the solution you'd like
My initial thought is to add a "filter" or parameter similar to heap_size called edition. Initially it would likely have 3 values, default for all non-Semeru builds, open and certified. This parameter could likely be reused in the future if needed by another variant or vendor.

Describe alternatives you've considered
I also thought about using license filter since the 2 editions are released under different licenses, but I think I like edition more.

Additional context
https://developer.ibm.com/languages/java/semeru-runtimes/downloads?license=GPL
https://developer.ibm.com/languages/java/semeru-runtimes/downloads?license=IBM

I can use https://api.adoptium.net/v3/binary/latest/18/ea/alpine-linux/x64/jdk/hotspot/normal/adoptium to fetch the latest alpine-linux nightly, but it isn't possible to generate this URL using https://api.adoptium.net/q/swagger-ui/#/Binary/getBinary

The vendor menu only has eclipse in it, and it misses adoptium.

See discussion at https://adoptium.slack.com/archives/C09NW3L2J/p1645009050578689?thread_ts=1645003789.204649&cid=C09NW3L2J

Describe the bug
I was trying to fetch the set of LTS version strings and then fetch the respective binaries using the former. Works for everything else other than jdk8u302-b08.1

To Reproduce
Steps to reproduce the behavior:

$ curl -X 'GET' \
  'https://api.adoptium.net/v3/info/release_names?architecture=x64&heap_size=normal&image_type=jdk&lts=true&os=windows&page=0&page_size=3&project=jdk&release_type=ga&sort_method=DEFAULT&sort_order=DESC&vendor=adoptium' \
  -H 'accept: application/json'
{
  "releases": [
    "jdk-11.0.12+7",
    "jdk8u302-b08.1",
    "jdk8u302-b08"
  ]
}

and then try to fetch the binary for jdk8u302-b08.1:

$ curl -X 'GET' \
  'https://api.adoptium.net/v3/binary/version/jdk8u302-b08.1/linux/x64/jdk/hotspot/normal/adoptium?project=jdk' \
  -H 'accept: */*'
{"errorMessage":"No releases match the request"}

Expected behavior
Either redirect to a valid release or remove the listed version from the repository

Hello,
I was playing with both the api.adoptopenjdk.net and api.adoptium.net and there is a strange behavior that I can't explain.

I thought that by saying "Good-bye AdoptOpenJDK Hello Adoptium!" that will mean that there won't be any binary loss or API degradation but it doesn't seem to be true. Can someone please explain to me what am I missing here ?

To Reproduce

Try to fetch the header from api.adoptopenjdk.net:

$ curl -IX 'GET'   'https://api.adoptopenjdk.net/v3/assets/feature_releases/11/ga?architecture=x86&heap_size=normal&image_type=jre&jvm_impl=hotspot&os=windows&page=0&page_size=10&project=jdk&sort_method=DEFAULT&sort_order=DESC&vendor=adoptopenjdk'   -H 'accept: application/json'

HTTP/2 200
date: Wed, 08 Sep 2021 09:40:28 GMT
content-type: application/json
set-cookie: b7b892882bae631693e1ea44963ef628=f5366a02d77f28e4d00cf7de250eefda; path=/; HttpOnly; Secure
cache-control: private
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 68b7372aec634a80-FRA
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400

As we can see ; it's correct! We can even fetch and read the data if we remove the header-only flag.

Now let's look at the api.adoptium.net by changing the FQDN and the vendor to adoptium.

$ curl -IX 'GET'   'https://api.adoptium.net/v3/assets/feature_releases/11/ga?architecture=x86&heap_size=normal&image_type=jre&jvm_impl=hotspot&os=windows&page=0&page_size=10&project=jdk&sort_method=DEFAULT&sort_order=DESC&vendor=adoptium'   -H 'accept: application/json'

HTTP/1.1 404 Not Found
Date: Wed, 08 Sep 2021 09:42:25 GMT
Content-Type: application/json
Connection: keep-alive

As we can see; it's not working! We get a 404 error which is somehow unexpected.

Expected behavior

I was expecting to get a 200 response with some information about available binaries.

Stay safe and healthy!

Is your feature request related to a problem? Please describe.
https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/ says "Please migrate to using this new API as soon as possible" but no info what that means.

I assume it is change https://api.adoptopenjdk.net/ to https://api.adoptium.net/ but neither pages mention it.

Describe the solution you'd like

A mention on https://api.adoptopenjdk.net/ that it is deprecated and https://api.adoptium.net/ should be used instead.

And have https://api.adoptium.net/ actually have overview, migration info and usage docs linked up as otherwise adoptopenjdk still looks the better option.

Is your feature request related to a problem? Please describe.
Recently a patch was added to the temurin build repository which builds static-libs for supported releases. See also the overall tracking issue for this: adoptium/temurin-build#2699

Since Adoptium builds for Alpine Linux and other Linux distributions (musl vs. glibc), the static libs get qualified by -musl or -glibc for Linux. This isn't the case for any other platform (there is only one C library/build for them per architecture). Yet, the current API supports staticlibs queries like these:

$ curl -v https://api.adoptium.net/v3/binary/latest/11/ga/linux/x64/staticlibs/hotspot/normal/adoptium

For such a query it's not clear what it should return. The musl version or a glibc version? When this was implemented in the API there was only a glibc version.

Describe the solution you'd like
Perhaps support something like:

$ curl -v https://api.adoptium.net/v3/binary/latest/11/ga/linux/x64/staticlibs/hotspot/normal/adoptium?clib=<value>

where <value> is either glibc or musl.

An example build with static libs is here:
https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-x64-hotspot/

As this is probably not a persistent link I'll paste to-be expected file names for linux here:

OpenJDK11U-static-libs-glibc_x64_linux_hotspot_2021-09-28-08-28.tar.gz
OpenJDK11U-static-libs-musl_x64_linux_hotspot_2021-09-28-08-28.tar.gz

There is no checksum for the AQAvit results in the JSON file, as there is for the binaries. This means that the results could potentially be replaced with different contents, while using the same filename.

Is this intentional? Or is there a plan to phase in something more like the package block for binaries, where the results have a name and checksum as well as the link?

The architecture option for Intel/AMD 64-bit is x64: https://api.adoptium.net/q/swagger-ui/#/Binary/getBinary

However, Linux uname -m on such architectures returns x86_64; therefore, for example, cross-compiling container image builds for multiple architectures can't just be, for example:

wget https://api.adoptium.net/v3/binary/latest/11/ga/linux/$(uname -m)/jdk/hotspot/normal/eclipse

Instead it has to be something clunky like:

wget https://api.adoptium.net/v3/binary/latest/11/ga/linux/$(if [ "$(uname -m)" = "x86_64" ]; then echo "x64"; else uname -m; fi)/jdk/hotspot/normal/eclipse

It would be nice if this API could take the alias x86_64 for x64.

Output of uname -m on some common architectures (all but x86_64 map correctly in the API):

$ podman run --rm -it docker.io/amd64/fedora uname -m
x86_64
$ podman run --rm -it docker.io/arm64v8/fedora uname -m
aarch64
$ podman run --rm -it docker.io/ppc64le/fedora uname -m
ppc64le
$ podman run --rm -it docker.io/s390x/fedora uname -m
s390x

Looking at https://api.adoptium.net/v3/assets/feature_releases/11/ea?heap_size=normal&image_type=jdk&page=0&page_size=10&project=jdk&sort_method=DEFAULT&sort_order=DESC&vendor=eclipse the latest release is from 21 days ago even though we are still pushing builds (most recent one was today https://github.com/adoptium/temurin11-binaries/releases/tag/jdk11u-2022-03-04-07-35-beta). Something seems to have gone wrong

Describe the bug
Website is not showing the JRE packages for JDK17 despite their presence in https://github.com/adoptium/temurin17-binaries/releases/tag/jdk-17.0.1%2B12

To Reproduce
Steps to reproduce the behavior:
API address https://api.adoptium.net/v3/assets/feature_releases/17/ga?architecture=x64&heap_size=normal&image_type=jre&jvm_impl=hotspot&os=linux&page=0&page_size=10&project=jdk&sort_method=DEFAULT&sort_order=DESC&vendor=eclipse gives no results - if you use 11 for the release, or use image_type=jdk then it gives results.

Expected behavior
JREs should be visible from the API. This will be preventingi them showing on the website too.

We currently have to pull, would rather there be a push of things like "Hey, we're blocking 5% of traffic today for reason X".

Our API 302's to GitHub which in turn relies on AWS S3 - we don't see the rate limiting or rejection chain

You do need to pass in GITHUB_TOKEN and APP_INSIGHTS instrumentation key.

Originally posted by @karianna in #129 (comment)

Describe the bug
When new binaries get released to our GitHub temurinX-binaries repositories the API doesn't always pick them up and an administrator is forced to 'restart' or kick the API (that process is not documented).

Describe the bug
The api recently changed to no longer accept the semver string from v3/info/release_versions as filter parameter for other apis like
v3/assets/version/18.0.2+101. Those now return a 404 instead.

We use those api to suggest java updates, but they started failing recently

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on 'Try it out'
3. Scroll down to 'version'
4. Add 18.0.2+101
5. Scroll down to Execute
6. See 404

Expected behavior
Allow using semver string instead of openjdk_version, which now seems to differ

Screenshots

Device (please complete the following information):

• OS: Linux, Windows
• Browser Chrome, curl
• Version latest available, doesn't matter

Additional context
Add any other context about the problem here.

Describe the bug
For v3/info/release_versions the "release_type" filter doesn't work

release_typestring(query) | Type of release. Either a release version, known as General Availability(ga) or an Early Access(ea)
Available values : ga, ea
Default value : ga

To Reproduce
Steps to reproduce the behavior:

Filter on GA give me 3 EA release :
curl -X GET "https://api.adoptopenjdk.net/v3/info/release_versions?page=0&page_size=10&release_type=ga&sort_method=DEFAULT&sort_order=DESC&vendor=adoptopenjdk&version=%5B11%2C11.1%29" -H "accept: application/json" |grep ea
11.0.7-ea+10.1
11.0.8-ea+10
11.0.9-ea+11

and filtering on EA give me no EA but only what I think is nightly

curl -s -X GET "https://api.adoptopenjdk.net/v3/info/release_versions?page=0&page_size=10&release_type=ea&sort_method=DEFAULT&sort_order=DESC&vendor=adoptopenjdk&version=%5B11%2C11.1%29" -H "accept: application/json" |grep ea

A clear and concise description of what you expected to happen.

I expect that the ga filter doesn't return EA build
I expect ea filter return the 3 build seen in ga
Maybe we must add a filter for nightly .. or rename ea with nightly and ga with gaAndEA

The latest route at:

https://api.adoptium.net/q/swagger-ui/#/Assets/getLatestAssets

Does not support the list of optional parameters that for instance the feature_release endpoint does:

https://api.adoptium.net/q/swagger-ui/#/Assets/searchReleases

Add these optional parameters.

It seems like only the latest build version can be selected on the marketplace, even though there're multi-releases descriped on the index.json file of BiSheng JDK.

Currently this functionality is duplicated in both the API and build codebases

Reported by the VS Code team.

Steps Are:

• Fetch metadata from https://api.adoptium.net/v3/assets/latest/17/hotspot
• Download corresponding JDK with its 'binary.installer.link' property, which points to github.com

From our observation, a big part of users failed to download the installer from github.com

And occasionally there's also cases that they failed to access api.adoptium.net, like below, which I believe is mainly their networking issue.

RequestError: Error: getaddrinfo ENOTFOUND api.adoptopenjdk.net api.adoptopenjdk.net:443

Is your feature request related to a problem? Please describe.
The landing page you are presented with when you hit https://api.adoptium.net/ feels a little bland.

Describe the solution you'd like
All the page offers is a link to the Swagger docs, maybe https://api.adoptium.net/ should just serve up the Swagger docs as per https://api.adoptium.net/q/swagger-ui/

Describe alternatives you've considered
Alternatively, if we want to keep the existing page, enhance the landing page to be a bit more informative.

Possibly including links into the GitHub repo ("Fork me" style) for contributions would be nice.

Hello,

Currently V3 API provides versioning according to JEP 322 (like aa.bb.cc.dd+ee.ff).
My updater sometimes encounters situations when only "MSI" style of version is available for local installations (like AA.BB.CC.DD).

If possible, I would like to have both version styles available in V4 API, like:

    "version": { ... }, // the same block like in V3 assets
    "msi_version": "11.0.9.101", // maybe for msi assets only?

so that comparison logic could be controlled from within the Adoptium project, without having to change the updater.

I believe it should be possible to extract the necessary format from MSI packages / build process somehow and make it available in the API.

Also, currently my version comparison logic is a bit tricky because it tries to take different versioning schemes and workarounds into account. Implementing this would make comparison logic much simpler, straightforward and reliable.

Related issues:
adoptium/temurin-build#2248

As discussed in AdoptOpenJDK/openjdk-website#753 (comment), it seems that the /v3/assets/latest route doesn't contain the release_link field which would be useful for the website.

./mvnw site

...
[INFO] <<< jdepend-maven-plugin:2.0:generate < compile @ adoptium-api-v3 <<<
[INFO]
[INFO] 'compile' forked phase execution for jdepend-maven-plugin:generate report preparation done
[INFO] 2 reports detected for jdepend-maven-plugin:2.0: generate-no-fork, generate
[INFO] configuring report plugin org.codehaus.mojo:versions-maven-plugin:2.8.1
[INFO] 3 reports configured for versions-maven-plugin:2.8.1: dependency-updates-report, plugin-updates-report, property-updates-report
[INFO] configuring report plugin org.jacoco:jacoco-maven-plugin:0.8.7
[INFO] 2 reports configured for jacoco-maven-plugin:0.8.7: report, report-aggregate
[INFO] PMD version: 6.38.0
Downloading from central: https://repo.maven.apache.org/maven2/io/aexp/nodes/graphql/nodes/0.5.0/nodes-0.5.0.jar

Hello,

This URL used to work just fine for downloading the latest early access builds. It returns a selection of some JDK builds. I cannot see it documented on https://api.adoptium.net/q/swagger-ui/#/Binary/getBinary though.

Reproducer

 curl -OJL 'https://api.adoptium.net/v3/binary/latest/17/ea/linux/x64/jdk/hotspot/normal/eclipse'

Expected

Tarball is downloaded.

Actual

The response is this text:

{"errorMessage":"Multiple binaries match request: 
[OpenJDK17U-jdk_x64_linux_hotspot_2022-05-27-19-32.tar.gz, 
OpenJDK17U-sbom_x64_linux_hotspot_2022-05-26-23-30.tar.gz]"}

Similar with curl -OJL 'https://api.adoptium.net/v3/binary/latest/17/ea/linux/aarch64/jdk/hotspot/normal/eclipse'.

JDK 11 seems to download just fine.

Thx for hints.

Hi,

I'm currently trying to switch from AdoptOpenJDK to Adoptium because the JDK 17 builds from AdoptOpenJDK are not up-to-date.

While checking I noticed that https://api.adoptium.net/v3/assets/feature_releases/17/ea or any other version is not accessible via Browser or Postman. For some reasons curl works, though.

This is e.g. used in Spring-Boot - see https://github.com/spring-projects/spring-boot/blob/main/ci/scripts/detect-jdk-updates.sh#L12 so it would be nice if this is fixed so we can switch there.

Cheers,
Christoph