actions/setup-java
5
0
Fork 0
mirror of https://gitea.com/actions/setup-java.git synced 2026-08-07 02:31:20 +00:00
Code Activity

Cache resolved JDK releases to remove the vendor API from warm jobs (#1208)

Browse Source 
* 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
This commit is contained in:
Bruno Borges
2026-08-04 23:58:03 -04:00
committed by GitHub
parent ef9440a2b8
commit ab597f914a
17 changed files with 1624 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/advanced-usage.md
+44
View File
@@ -574,6 +574,50 @@ step and skips the save with a warning, so a key is never saved with content
other than the installation it identifies. This guarantee holds without
rehashing hundreds of megabytes of JDK content on every job.
### Caching release resolution
Only Temurin is preinstalled in the runner tool cache, so for every other
distribution setup-java has to ask the distribution's metadata API which release
satisfies `java-version` before it can look up a JDK cache entry. That makes the
vendor API a dependency of every job, even one whose JDK is already cached.
When JDK caching is enabled, setup-java also stores the resolved release itself
in a small companion cache entry, keyed on the runner operating system,
architecture, distribution, package type, requested version, and stability. A job
that finds a current entry installs the JDK without contacting the distribution's
metadata API at all.
Entries carry the seven-day window they were resolved in. An entry from an
earlier window is not used directly: setup-java still queries the metadata API,
so a floating request such as `java-version: 21` keeps picking up new releases.
The older entry is used only when that query fails, which keeps a job working
through a vendor outage or rate limit. Because the entry also holds the download
URL and checksum, this fallback works even when the JDK itself is not cached and
still has to be downloaded. When the fallback is used, setup-java reports it with
a warning.
Seven days is deliberate. GitHub removes cache entries that have not been
accessed for seven days, so a longer window would mean the previous entry is
already evicted by the time the window rolls over, leaving no fallback at the
moment one is most likely to be needed. It also comfortably covers JDK release
cadence, which is monthly at its fastest and usually quarterly, and it means a
repository whose workflows run infrequently still benefits. Use
`check-latest: true` for a workflow that must resolve the newest release on every
run.
Restored entries are validated before use: the download URL and any signature URL
must be well-formed HTTPS URLs and the checksum must use a supported algorithm.
An entry that fails validation is ignored and the metadata API is queried
instead. `check-latest: true`, `java-version: latest`, and `force-download: true`
always query the metadata API and never read or write these entries.
Releases whose download URL is not content-addressed are never stored. Oracle JDK
and Oracle GraalVM build a `/latest/` URL when `java-version` names only a major
version, and the bytes behind that URL change whenever a new build is published,
so its URL and checksum are only consistent with each other at the moment they
are resolved. Requesting a more specific version, such as `java-version: 21.0.2`,
resolves an archived URL that is stored normally.
JDK caching trades cache storage and cold-run save work for faster warm setup.
A warm run restores the installed JDK instead of downloading, verifying, and
extracting it, while the first run pays to upload it and every cached identity