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
* Add JDK caching
Cache resolved JDK tool-cache entries by exact platform and release identity, with a default-on cache-jdk input and explicit opt-out.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Apply batched suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Fix JDK cache CI validation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Update brace-expansion security fix
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Refresh brace-expansion license metadata
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Refine JDK cache semantics
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Refine JDK cache documentation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Simplify JDK cache identity
Use one normalized runner OS dimension, reset the internal cache key schema for the unreleased feature, and align documentation, tests, and bundles.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Align JDK cache OS identity
Use the established RUNNER_OS value directly and retain process.platform only as a non-Actions fallback.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Harden JDK cache saves and document tool-cache reuse
Bind each JDK cache key to the installation identity it was computed for,
keep post-job saves best-effort per entry, and state the real reuse and
verification guarantee in the documentation.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: restructure README caching section
Rename '## Caching dependencies' to '## Caching' and add a what-gets-cached
overview table covering the dependency, wrapper, and JDK caches. Lead with the
common 'cache: maven' example and the dependency-cache material, and demote JDK
caching into its own subsection.
Also corrects the IMPORTANT callout, which implied JDK caching required an
explicit opt-in; it is enabled implicitly whenever 'cache' is set.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: fix caching documentation defects
- Remove pull-request framing that compared behavior to `main`; state the
tool-cache and `jdkfile` behavior directly and unconditionally.
- Clarify that the JDK cache is a separate cache *entry* from the dependency
and wrapper caches, while its *enablement* is coupled to `cache`, so the
opening paragraph agrees with the enablement matrix.
- Cite the actions/setup-java-benchmarks repository instead of an open PR and
a self-referential PR comment, keeping the measured figures and caveats.
- Keep the `cache`/`cache-jdk` matrix only in docs/advanced-usage.md and
summarize the rules in prose in README.md to avoid divergence.
- Describe the guarantee that a cache key is only saved with the installation
it was computed for, instead of documenting inode/size/timestamp internals.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: add V6 what's new entry for JDK caching
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: e2755464-4e83-47b6-ba71-731bb481b418
---------
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: e2755464-4e83-47b6-ba71-731bb481b418
* 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>
* Add set-default option
This option allows to install an additional JDK without making it the
default one.
I have wanted this for quite a long time as I'm running custom GitHub
Actions with Java, which might require a specific JDK and I don't want
to pollute the JDK that is used by the overall workflow calling the
action.
And I'm apparently not alone as there was a preexisting issue.
Fixes#560
* Dedupe setJavaDefault and document multi-version/toolchain behavior
- Refactor setJavaDefault to delegate shared output/env logic to
setJavaEnvironment, avoiding duplication between the two.
- Document that set-default applies to all JDKs in a multiline
java-version, and that installed JDKs remain registered in Maven
toolchains regardless of set-default.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* test: fix Prettier formatting in base-installer test
Resolves the failing 'Basic validation / build' format-check on
__tests__/distributors/base-installer.test.ts (line exceeded print width).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
