On Alpine, `getPlatformOption()` returned the glibc platform key for
Dragonwell, Corretto, Zulu, Liberica and Liberica NIK, so the action
resolved and installed a glibc JDK that cannot run under musl.
Add a shared `isAlpineLinux()` helper and use it to select each vendor's
musl artifacts:
| distribution | glibc | musl |
| ------------ | ------------- | -------------- |
| Dragonwell | `linux` | `alpine-linux` |
| Corretto | `linux` | `alpine` |
| Zulu | `linux_glibc` | `linux_musl` |
| Liberica | `linux` | `linux-musl` |
| Liberica NIK | `linux` | `linux-musl` |
Each key was verified against the vendor's live metadata API or manifest.
There is deliberately no silent fallback to glibc when a vendor has no
musl build for the requested version or architecture: the existing "could
not find a version that satisfies" error fires instead. This matches the
behaviour Temurin and SapMachine already have, and a glibc JDK would not
run on musl anyway.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
Two wall-clock optimizations on the JDK install path.
`tc.cacheDir` recursively copies the extracted tree into RUNNER_TOOL_CACHE,
so a 200-600MB JDK is written to disk twice. The extraction directory and
the tool-cache normally share a filesystem, so `cacheJdkDir` renames it
instead and writes the `.complete` marker itself, mirroring the destination
layout `tc.cacheDir` produces. It falls back to the copy when the tool-cache
location is unknown, when the source is not a real directory (a symlinked
source would otherwise leave a dangling entry once RUNNER_TEMP is cleaned),
or when the rename fails - a cross-device tool-cache, or anti-virus holding
a handle on Windows. The rename is atomic, so the source is still intact
for the fallback.
Extraction now uses `pigz` for tarballs when the runner provides it, and
Windows zips go through the bundled `tar.exe` rather than `tc.extractZip`,
which shells out to PowerShell's much slower `Expand-Archive`. Both fall
back to the stock extraction and clean up the abandoned directory first.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644
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>
* Migrate to ESM and upgrade dependencies
* fix: update import statement for JSON module in kona-installer test
---------
Co-authored-by: George Adams <georgeadams1995@gmail.com>
* Use Azul metadata API
* Document arm64 -> aarch64 mapping in README.md
* Paginate through all available versions
* Fix typo: win_aarhc4
* Only query for linux_glibc packages
* Add Zulu CRaC package support to metadata migration
Fold CRaC-related work into the Zulu metadata API migration by wiring crac_supported query handling, extending Zulu package docs, and updating installer tests for jdk+crac/jre+crac behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Harden Zulu metadata pagination with safety cap
- Stop paginating on a short page to avoid an extra empty request
- Guard against undefined results (not just null)
- Cap iterations at 100 pages and warn if the limit is hit to
prevent a runaway loop if the API misbehaves
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Preserve JDK build number from Azul Metadata API
The Azul Metadata API returns java_version as a 3-element array
(e.g. [17,0,7]) and reports the build number separately in
openjdk_build_number. The migration mapped version directly from
java_version, dropping the build and breaking exact-version lookups
like 17.0.7+7 (e2e failure: "No matching version found for SemVer").
Add openjdk_build_number to IZuluVersions and append it to
java_version before converting to semver so resolved versions retain
the build (e.g. 17.0.7+7). Update the zulu test fixtures to mirror the
real API shape (3-element java_version plus openjdk_build_number) so
unit tests exercise the actual response format, and rebuild dist.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Refactor error handling for version not found cases across multiple installers
* Mock core.error in tests to suppress error logs
* fix(graalvm): improve error messages for EA version not found scenarios
* refactor(tests): update error messages for version not found scenarios
* fix(graalvm): enhance error messages for version not found scenarios
* fix(graalvm): improve error messages for version not found scenarios with updated download URL
* fix(graalvm): improve error handling for EA version not found scenarios with clearer messages
* Added Windows Arm64 Support for Windows Arm64 Runners
* microsoft test file update and tool-version test file
* Delete .DS_Store
* added test cases for windows and linux for zulu, liberica and microsoft
* adding different data files for each OS
* added changes to distribution files
* added more version support for microsoft
Azul API stopped to support arm64 architecture, the only supported
option for ARM cpus is now 'arm'. This requires to set up hw_bitness
properly to get 64 bits version. 32 bits version can be obtained by
using 'arm' as an architecture.
Bruno Borges