* Fix floating Oracle JDK version resolution
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Update generated distribution bundles
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Harden floating artifact cache identity
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Regenerate setup bundle after cache hardening
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Temporarily enable hosted full validation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Export hosted formatting results
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Apply repository formatting
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Run hosted validation after formatting
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Correct floating version regression tests
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Remove temporary validation wiring
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* 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 <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
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
Julien Dubois