mirror of
https://gitea.com/actions/setup-java.git
synced 2026-08-07 02:31:20 +00:00
143564d5b978d0600e5023425202da0c0c94b8c6
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Julien Dubois
|
f4bfb3ddea |
Report concrete versions for floating Oracle JDK downloads (#1213)
* 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> |
||
|
Bruno Borges
|
ab597f914a |
Cache resolved JDK releases to remove the vendor API from warm jobs (#1208)
* Cache resolved JDK releases to remove the vendor API from warm jobs Only Temurin is preinstalled in the runner tool cache, so for every other distribution `findInToolcache()` misses on essentially every job. That forces a call to the distribution's metadata API before the JDK cache key can even be computed, which makes the vendor a hard per-job dependency even when the JDK bytes are already cached, and turns a vendor 403, 429, or outage into a job failure. Store the resolved release in a small companion cache entry keyed only on inputs known before any network call: runner OS, architecture, distribution, package type, requested version, and stability. A job that finds a current entry installs the JDK without contacting the metadata API at all. `@actions/cache` derives a cache version by hashing the requested paths, so save and restore paths must match. The entry therefore uses a path that excludes the date bucket while the key includes it, which lets restore keys fall back to an older bucket. An entry older than the current day is not used directly: the metadata API is still queried so floating requests such as `java-version: 21` keep picking up new releases, and the older entry is used only when that query fails. Because the entry also carries the download URL and checksum, that fallback works even when the JDK itself is not cached. Releases whose URL is not content-addressed are never stored. Oracle JDK and Oracle GraalVM build a `/latest/` URL for a major-only version, and its bytes change when a new build is published, so the URL and checksum are only consistent at the moment they are resolved. Mark those releases floating and skip recording them. Restored payloads are validated as untrusted input, and the post-job save rewrites the payload the key was computed for rather than uploading whatever is on disk, since a restore in a later step targets the same path. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Widen the resolution freshness window from a day to a week A daily window gives no benefit to the repositories that need it most. A repository whose workflows run once a day would re-resolve on every job, and one running weekly would never see a current entry at all, yet those are exactly the repositories with nothing warm in the tool cache. Seven days is also the ceiling. GitHub removes cache entries that have not been accessed for seven days, so a longer window would leave the previous entry evicted by the time the window rolls over, removing the stale fallback at the moment it is most likely to be needed. It comfortably covers JDK release cadence, which is monthly at its fastest and usually quarterly. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Rebuild dist to match the linted source The pre-commit hook runs `eslint --fix` after `npm run check` has already built `dist/`, so the fix it applied to the resolution fallback warning in `base-installer.ts` never reached the bundle. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Rebuild dist to match the linted source The autofix accepted on the pull request edited the resolution fallback warning in `base-installer.ts` through the GitHub UI, which does not run `npm run build`, so `dist/` still carried the pre-fix bundle. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 |
||
|
Bruno Borges
|
885218c5e4 |
Move the extracted JDK into the tool-cache and speed up extraction (#1206)
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 |
||
|
Bruno Borges
|
3cc3643700 |
Optimize Temurin tool-cache fast path with lazy loading (#1179)
* Optimize Temurin tool-cache fast path - Lazy-load distribution installers so only the selected distro module is initialized - Defer cache feature/cache module loading until cache input is provided - Start cache restore early and await it safely alongside Java setup flow - Update orchestration and lazy-loading tests; regenerate dist artifacts Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cc2c0256-c55e-4a35-a584-5bed7e8b11ad * Address PR review comments - Lazy-load cache save in cleanup path so no-cache runs avoid cache module init in post action - Stage dist/setup/package.json in release script for chunked setup bundle completeness Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cc2c0256-c55e-4a35-a584-5bed7e8b11ad * Fix CodeQL comment tag filter finding Patch is-unsafe's XML comment-close detector during builds so generated bundles recognize both HTML comment end forms and satisfy CodeQL until the dependency publishes a fix. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 277302b1-aa95-4012-817b-9752cdaee14e * Rebuild generated dist bundles Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cc2c0256-c55e-4a35-a584-5bed7e8b11ad --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cc2c0256-c55e-4a35-a584-5bed7e8b11ad Copilot-Session: 277302b1-aa95-4012-817b-9752cdaee14e |