adoptium / api.adoptium.net Goto Github PK
View Code? Open in Web Editor NEWAdoptium API ๐
Home Page: https://api.adoptium.net
License: Apache License 2.0
Adoptium API ๐
Home Page: https://api.adoptium.net
License: Apache License 2.0
Currently this functionality is duplicated in both the API and build codebases
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
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.
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 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
Reported by the VS Code team.
Steps Are:
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
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.
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):
Additional context
Add any other context about the problem here.
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.
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
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
docker-compose up
will run into missing dependencies
To Reproduce
Steps to reproduce the behavior:
docker-compose up
Expected behavior
Docker containers will come up.
Screenshots
n/a
Device (please complete the following information):
Additional context
Workaround: Will build fine using mvnw clean install
in Dockerfile
, which is a code smell.
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.
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
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"
}
}
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
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
Describe the bug
HTML tags in hints in input fields, see screenshot.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
formatting
Screenshots
Device (please complete the following information):
any
Additional context
Will file a PR later today
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
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".
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
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.
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.
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
Expected behavior Update certificate.
Screenshots
Device (please complete the following information):
Additional context
Add any other context about the problem here.
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<s=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
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
}
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
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>
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<s=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
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
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
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.
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
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.
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/
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.
curl -OJL 'https://api.adoptium.net/v3/binary/latest/17/ea/linux/x64/jdk/hotspot/normal/eclipse'
Tarball is downloaded.
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.
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.
The repository README file still refers to the AdoptOpenJDK API, and should be updated to reflect the new adoptium.net API.
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:
18.0.2+101
Execute
Expected behavior
Allow using semver
string instead of openjdk_version
, which now seems to differ
Device (please complete the following information):
Additional context
Add any other context about the problem here.
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!
Describe the bug
The feedback from the site is confusing at best.
Screenshots
If applicable, add screenshots to help explain your problem.
Device (please complete the following information):
Additional context
Basically, if I see this:
feature_version
, e.g., 10swagger
than supported feature_versions
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 Swagger UI is not available as the response has 404 status code.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Device (please complete the following information):
Additional context
N/A
Our API 302's to GitHub which in turn relies on AWS S3 - we don't see the rate limiting or rejection chain
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?
./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
Currently, we have to manually deploy API changes to AKS. We should automate the redeploys when changes are pushed
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.