* Fix JDK resolution cache platform identity
Include the effective Linux libc platform in JDK resolution cache keys so Alpine/musl and glibc runners cannot restore each other's release metadata. Bump the cache namespace and share Alpine detection with affected distributors.\n\nCo-authored-by: Copilot App <[email protected]>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866
* Update generated action bundles
Regenerate setup and cleanup distributions for the platform-aware JDK resolution cache.\n\nCo-authored-by: Copilot App <[email protected]>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866
* Cover the platform-identity fallback and Alpine short-circuit
getJavaPlatformIdentity's `?? platform` fallback and the alias path for
platforms other than linux/darwin/win32 had no coverage, and isAlpineLinux
had no direct test at all.
Verified by mutation: replacing the fallback with a constant, and dropping
the `platform === 'linux'` short-circuit from isAlpineLinux, both left the
existing suite fully green. The added cases fail on each.
The short-circuit case matters beyond coverage bookkeeping: it is what keeps
the /etc/alpine-release probe from running on non-Linux runners, so a stray
file can never make Windows or macOS resolve as musl.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
* Carry the platform identity into the floating resolution request
Merging main brought in #1219, which added getFloatingResolutionRequest
as a second construction site for JdkResolutionRequest. It predates the
required `platform` field, so the merged tree did not compile.
The floating request already carries `source`, which pins the artifact
bytes, so this changes no lookup behaviour on its own -- it keeps the two
request builders consistent and the tree building.
Also refreshes dist/, which the textual merge left stale.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
---------
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
* Fix floating Oracle JDK version resolution
Co-authored-by: Copilot App <[email protected]>
* Update generated distribution bundles
Co-authored-by: Copilot App <[email protected]>
* Harden floating artifact cache identity
Co-authored-by: Copilot App <[email protected]>
* Regenerate setup bundle after cache hardening
Co-authored-by: Copilot App <[email protected]>
* Temporarily enable hosted full validation
Co-authored-by: Copilot App <[email protected]>
* Export hosted formatting results
Co-authored-by: Copilot App <[email protected]>
* Apply repository formatting
Co-authored-by: Copilot App <[email protected]>
* Run hosted validation after formatting
Co-authored-by: Copilot App <[email protected]>
* Correct floating version regression tests
Co-authored-by: Copilot App <[email protected]>
* Remove temporary validation wiring
Co-authored-by: Copilot App <[email protected]>
* Cache checksum-less floating artifacts by their response fingerprint
Oracle and Oracle GraalVM do not always publish a `.sha256` sibling next
to a `/latest/` artifact. Those floating releases were excluded from both
the resolution cache and the JDK cache, so `cache-jdk` users lost caching
entirely for them.
A floating URL is a constant string, so it cannot serve as a cache
identity on its own — a stale entry would be reused forever. Instead,
derive a validator from the headers of the HEAD request that already
resolves the artifact: the ETag when present, otherwise `Last-Modified`
combined with `Content-Length`. Republishing changes the validator, which
changes the cache key, so a new build is downloaded rather than masked.
`getJdkReleaseIdentity` now falls back to that fingerprint before the
URL, and the floating cache gates ask whether the release has a stable
identity (checksum or fingerprint) rather than a checksum specifically. A
floating release with neither is still left uncached.
Co-authored-by: Copilot App <[email protected]>
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Bruno Borges <[email protected]>
