Migrate from Zulu Discovery API to Azul Metadata API#1010
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Migrates the Zulu (Azul) distribution from the deprecated zulu/download/community/v1.0 API to the new metadata/v1/zulu/packages API, updating request parameters, response model fields, and architecture mapping accordingly.
Changes:
- Switched API endpoint and renamed query parameters (e.g.,
ext→archive_type,bundle_type→java_package_type,javafx→javafx_bundled); replacedhw_bitness/abiwith a singlearchvalue and addedavailability_types,page,page_sizeparameters. - Updated
IZuluVersionsmodel to use new field names (package_uuid,download_url,java_version,distro_version,latest,availability_type). - Updated tests and fixture data to align with the new API contract; updated README note about arch mapping.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/distributions/zulu/models.ts | Updated IZuluVersions interface to new Azul Metadata API schema. |
| src/distributions/zulu/installer.ts | Updated request URL/params, response field references, and simplified getArchitectureOptions to return a single string. |
| tests/distributors/zulu-installer.test.ts | Updated expected URLs and arch mapping assertions for macOS. |
| tests/distributors/zulu-linux-installer.test.ts | Updated expected URLs and arch mapping for Linux. |
| tests/distributors/zulu-windows-installer.test.ts | Updated expected URLs and arch mapping for Windows. |
| tests/data/zulu-windows.json | Regenerated fixture to match new API response schema. |
| tests/data/zulu-linux.json | Regenerated fixture to match new API response schema. |
| tests/data/zulu-releases-default.json | Regenerated fixture to match new API response schema. |
| README.md | Updated note about Zulu architecture mapping. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| `archive_type=${extension}`, | ||
| `java_package_type=${bundleType}`, | ||
| `javafx_bundled=${javafx}`, | ||
| `arch=${arch}`, | ||
| `hw_bitness=${hw_bitness}`, | ||
| `release_status=${releaseStatus}`, | ||
| abi ? `abi=${abi}` : null, | ||
| features ? `features=${features}` : null | ||
| ] | ||
| .filter(Boolean) | ||
| .join('&'); | ||
| `availability_types=ca`, | ||
| `page=1`, | ||
| `page_size=1000` | ||
| ].join('&'); |
There was a problem hiding this comment.
This is beyond me so here's what Claude output in response to this comment:
⏺ The live API response tells the full story. All 5 results with javafx_bundled=true have -fx- in their filenames (e.g., zulu26.30.11-ca-fx-jdk26.0.1-linux_x64.tar.gz), confirming the filter works correctly.
The Copilot comment is not a legitimate issue. Here's why:
The reviewer is applying old-API logic to the new API. In the old API (/zulu/download/community/v1.0/bundles/), you needed two separate parameters to get JavaFX bundles:
- javafx=true
- features=fx
In the new Metadata API (/metadata/v1/zulu/packages/), javafx_bundled is a dedicated, purpose-built boolean field that directly filters for JavaFX-bundled packages — it's not an alias for javafx; it's an entirely different parameter on a different API. The live API confirms: passing javafx_bundled=true returns only packages whose names contain -fx-.
There's no features parameter on the new Metadata API at all — it's not just that we dropped it, it doesn't exist in the new API. Adding features=fx to the new URL would likely be ignored or cause an error.
The tests were correctly updated to match the new API's behavior, not to hide a regression.
| `availability_types=ca`, | ||
| `page=1`, | ||
| `page_size=1000` | ||
| ].join('&'); |
There was a problem hiding this comment.
Implemented with d9458f0.
src/distributions/zulu/installer.ts
- Replaced the single page=1&page_size=1000 request with an infinite loop starting at page=1
- Each iteration requests page_size=100 entries; the loop breaks when the API returns an empty array
- Matches the pattern already used by the Adopt distribution, adapted for Azul's 1-based page indexing
Three test files (zulu-installer.test.ts, zulu-windows-installer.test.ts, zulu-linux-installer.test.ts)
- Changed the beforeEach default mock to return [] so URL verification tests terminate the loop after one call
- Updated load available versions in each file to use mockReturnValueOnce(data) followed by mockReturnValueOnce([]) to simulate a single full page then end-of-pagination
- Updated all URL string expectations from page_size=1000 to page_size=100
| }, | ||
| { | ||
| "package_uuid": "test-uuid-12446", | ||
| "name": "zulu17.48.15-ca-jdk17.0.10-win_aarhc4.zip", |
There was a problem hiding this comment.
zulu17.48.15-ca-jdk17.0.10-win_aarch64.zip is the correct file name according to https://cdn.azul.com/zulu/bin.
| **NOTE:** AdoptOpenJDK got moved to Eclipse Temurin and won't be updated anymore. It is highly recommended to migrate workflows from `adopt` and `adopt-openj9`, to `temurin` and `semeru` respectively, to keep receiving software and security updates. See more details in the [Good-bye AdoptOpenJDK post](https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/). | ||
|
|
||
| **NOTE:** For Azul Zulu OpenJDK architectures x64 and arm64 are mapped to x86 / arm with proper hw_bitness. | ||
| **NOTE:** For Azul Zulu OpenJDK, architecture `arm64` is mapped to `aarch64` when querying the Azul Metadata API. |
There was a problem hiding this comment.
I'm definitely not an expert on this but I suspect the x64 mapping is an appropriate change and won't need to be called out in README.md.
df4cd23 to
874ffb6
Compare
Used Claude Sonnet 4.6 to implement https://docs.azul.com/core/detailed/metadata-api-migration.html. If it's way off the mark then we can close it but if it's salvageable then please feel free to push any necessary commits on top of what is already done although I believe the changes I've made for this PR are complete.
Summary
Migrates the
zuludistribution from the deprecated Zulu Discovery API (https://api.azul.com/zulu/download/community/v1.0/bundles/) to the new Azul Metadata API (https://api.azul.com/metadata/v1/zulu/packages/).Background
The old Zulu Discovery API was returning HTTP 520 errors for a few hours, breaking all
distribution: zuluworkflows. Since the beginning of 2023 Azul has recommended the Metadata API and published a migration guide.Changes
src/distributions/zulu/models.tsUpdated
IZuluVersionsto match the new API response shape:id: number→package_uuid: stringurl→download_urljdk_version→java_versionzulu_version→distro_versionlatest: booleanandavailability_type: stringsrc/distributions/zulu/installer.tshttps://api.azul.com/metadata/v1/zulu/packages/ext→archive_type,bundle_type→java_package_type,javafx→javafx_bundledhw_bitnessandabiquery parameters (no longer part of the API)availability_types=cato restrict to free community buildsgetArchitectureOptions(): now returns a plainstringinstead of{arch, hw_bitness, abi}. Architecture mapping:x64→x64,x86→x86,arm64/aarch64→aarch64linux_glibcinstead oflinuxto exclude musl packages, which standard GitHub-hosted runners do not usewin_aarhc4→win_aarch64README.mdUpdated the architecture-mapping note to reflect the new API's conventions (
arm64→aarch64).Test fixtures and tests
zulu-releases-default.json,zulu-linux.json,zulu-windows.json) to use the new field namesgetArchitectureOptionstest cases to expect strings instead of objectsDistroArchtype (no longer needed)Related issue
Fixes #795
Check list
README.md)