* 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
* 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
* Support pinning java-version as "latest"
Add a `latest` alias for the `java-version` input that floats to the newest
available stable (GA) release. It is normalized to the SemVer wildcard at the
base-installer layer and always resolves from remote (like `check-latest: true`).
List-based distributions resolve it automatically via the existing newest-first
matching. Corretto selects its newest available major; Oracle and GraalVM look up
the newest GA major via the Adoptium API and request it, failing with an actionable
error if that major isn't published yet. The jdkfile distribution rejects `latest`.
Closes#832
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Clarify latest note for oracle/graalvm version resolution vs download
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* graalvm-community: float latest to its own newest GA release
GraalVM Community publishes its releases on GitHub, so the `latest`
alias now matches against that real release list using the SemVer
wildcard instead of asking the Adoptium API for the newest GA major.
This prevents `latest` from hard-failing when GraalVM lags behind a
freshly released Java major (e.g. Adoptium reports 26 before GraalVM
ships it). Oracle GraalVM has no listing endpoint, so it keeps deriving
the newest major from Adoptium and errors clearly if that major is not
yet published.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Give latest+qualifier inputs (e.g. latest-ea) a targeted error
Inputs like 'latest-ea' had their '-ea' suffix stripped and fell through
to the generic SemVer validation, failing with a confusing "'latest' is
not valid SemVer" message even though 'latest' is supported. Add an
explicit guard so any 'latest*' value other than exactly 'latest' throws
a targeted error explaining that 'latest' resolves GA releases only and
cannot be combined with '-ea' or other qualifiers.
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: Copilot Autofix powered by AI <175728472+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>
- installer: surface a clear error when the GraalVM Community releases
listing is not a JSON array, instead of silently treating an error
payload (rate limit, auth failure, etc.) as "no releases" which later
surfaced as a misleading "version not found" error.
- docs: fix the GraalVM Community advanced-usage example to check the
installed binary versions (java/native-image --version) rather than
running a non-existent HelloWorldApp classpath that fails when copied.
- tests: cover the new non-array release listing error path.
Rebuilt dist bundle.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Initial plan
* feat: add graalvm community distribution support
* build: update bundled dist for graalvm community support
* chore: address GraalVM community review feedback
* fix: tidy graalvm community validation follow-ups
* refactor: simplify GraalVM Community release resolution
* refactor: address review feedback on Community resolver
* refactor: rename pagination index for clarity
* test: fix graalvm installer test formatting
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.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
* Code updated to let code accept github token and refactored the code.
* github token accept through environment variable
* fix test error
* audit fix commit
* update package-lock.json
* Update GraalVM Tests
* Lint Issue Resolve
* Update Test case for Windows
* update with enhance code and test
Bruno Borges