Map Zulu x86 architecture to i686 for Azul Metadata API - #1079
Merged
brunoborges merged 1 commit intoJul 8, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The Azul Metadata API's `arch=x86` returns both 32-bit (i686) and 64-bit (x64) packages. Because the two variants share identical java_version and distro_version, setup-java cannot distinguish them and may resolve an explicit `architecture: x86` request to a 64-bit JDK (and for Java 21+, where 32-bit is dropped, x86 silently returns x64 instead of failing). The legacy Zulu Discovery API used `arch=x86&hw_bitness=32` to target only 32-bit builds. The Metadata API exposes the equivalent via `arch=i686`, which returns only genuine 32-bit builds with full version parity to the old behavior. Map x86 -> i686 to restore correct 32-bit resolution. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes Azul Zulu architecture resolution for explicit architecture: x86 requests after the migration to the Azul Metadata API, ensuring x86 consistently targets true 32-bit builds rather than sometimes resolving to 64-bit packages.
Changes:
- Map Zulu x86 architecture requests to Azul Metadata API arch=i686 to return only 32-bit packages.
- Update Zulu installer tests to assert the new arch=i686 query parameter and expected architecture mapping.
- Rebuild dist/ to reflect the source change.
| File | Description |
|---|---|
| src/distributions/zulu/installer.ts | Changes x86 mapping to i686 to ensure only genuine 32-bit Zulu builds are returned by the Metadata API. |
| dist/setup/index.js | Updates the compiled distribution output to match the new x86 → i686 mapping. |
| tests/distributors/zulu-windows-installer.test.ts | Updates URL/query assertions and architecture mapping expectations for Windows Zulu. |
| tests/distributors/zulu-linux-installer.test.ts | Updates URL/query assertions and architecture mapping expectations for Linux Zulu. |
| tests/distributors/zulu-installer.test.ts | Updates URL/query assertions and architecture mapping expectations in the generic Zulu installer tests. |
Review details
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 4/5 changed files
- Comments generated: 0
- Review effort level: Low
Sorry, something went wrong.
Copy link
Copy Markdown
Member
|
Should we not include i386 in this logic too? Or does the Azul API specifically map to i686? |
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
Author
|
Seems clear to me this is a matter of them mapping i686 |
Sorry, something went wrong.
zendesk-ops-ci
pushed a commit
to zendesk/setup-java
that referenced
this pull request
Jul 17, 2026
The Azul Metadata API's `arch=x86` returns both 32-bit (i686) and 64-bit (x64) packages. Because the two variants share identical java_version and distro_version, setup-java cannot distinguish them and may resolve an explicit `architecture: x86` request to a 64-bit JDK (and for Java 21+, where 32-bit is dropped, x86 silently returns x64 instead of failing). The legacy Zulu Discovery API used `arch=x86&hw_bitness=32` to target only 32-bit builds. The Metadata API exposes the equivalent via `arch=i686`, which returns only genuine 32-bit builds with full version parity to the old behavior. Map x86 -> i686 to restore correct 32-bit resolution. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 8a3e815)
zendesk-ops-ci
pushed a commit
to zendesk/setup-java
that referenced
this pull request
Jul 17, 2026
actions#1084) Regenerate the CommonJS bundle so the compiled dist/ reflects the source changes backported from main, without the ESM migration (actions#1078). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #1010 (Azul Metadata API migration). Fixes a regression where an explicit architecture: x86 request for the Zulu distribution could resolve to a 64-bit JDK.
Problem
The migration mapped code arch x86 → API arch=x86. However, the Azul Metadata API's arch=x86 returns both 32-bit (i686) and 64-bit (x64) packages. The two variants share identical java_version and distro_version, so findPackageForDownload cannot distinguish them and picks whichever the API returns first.
Consequences for architecture: x86:
The legacy Zulu Discovery API avoided this by using arch=x86&hw_bitness=32, which returned only 32-bit builds.
Fix
Map x86 → i686. The Metadata API's arch=i686 returns only genuine 32-bit builds, with verified full version parity to the legacy 32-bit behavior:
x64 and aarch64 resolution are unaffected.
Testing