* Handle cache restore promise rejections
Validate dependency cache providers before Java installation and settle cache restore failures immediately while preserving setup error precedence.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Make cache-rejection regression test deterministic
Reject the cache restore only after it has started and while the Java
installation is still pending, instead of relying on event-loop timing.
Verified the test fails against the pre-fix implementation.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Validate cache input after required input checks
Move the package-manager validation out of the top of run() so that
missing java-version/java-version-file and toolchain id errors keep
their original precedence. Validation now happens immediately before
the cache restore is started, which still fails fast before any JDK
download.
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>
* Fix SapMachine early-access filtering
Ensure SapMachine EA requests exclude stable releases and cover string and boolean release metadata with competing fixture candidates.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Update distribution bundle
Regenerate the setup bundle for SapMachine release-class filtering.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Format SapMachine regression tests
Apply the repository Prettier format to the focused test additions.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
On Alpine, `getPlatformOption()` returned the glibc platform key for
Dragonwell, Corretto, Zulu, Liberica and Liberica NIK, so the action
resolved and installed a glibc JDK that cannot run under musl.
Add a shared `isAlpineLinux()` helper and use it to select each vendor's
musl artifacts:
| distribution | glibc | musl |
| ------------ | ------------- | -------------- |
| Dragonwell | `linux` | `alpine-linux` |
| Corretto | `linux` | `alpine` |
| Zulu | `linux_glibc` | `linux_musl` |
| Liberica | `linux` | `linux-musl` |
| Liberica NIK | `linux` | `linux-musl` |
Each key was verified against the vendor's live metadata API or manifest.
There is deliberately no silent fallback to glibc when a vendor has no
musl build for the requested version or architecture: the existing "could
not find a version that satisfies" error fires instead. This matches the
behaviour Temurin and SapMachine already have, and a glibc JDK would not
run on musl anyway.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
* Fix JDK resolution cache platform identity
Include the effective Linux libc platform in JDK resolution cache keys so Alpine/musl and glibc runners cannot restore each other's release metadata. Bump the cache namespace and share Alpine detection with affected distributors.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866
* Update generated action bundles
Regenerate setup and cleanup distributions for the platform-aware JDK resolution cache.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866
* Cover the platform-identity fallback and Alpine short-circuit
getJavaPlatformIdentity's `?? platform` fallback and the alias path for
platforms other than linux/darwin/win32 had no coverage, and isAlpineLinux
had no direct test at all.
Verified by mutation: replacing the fallback with a constant, and dropping
the `platform === 'linux'` short-circuit from isAlpineLinux, both left the
existing suite fully green. The added cases fail on each.
The short-circuit case matters beyond coverage bookkeeping: it is what keeps
the /etc/alpine-release probe from running on non-Linux runners, so a stray
file can never make Windows or macOS resolve as musl.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
* Carry the platform identity into the floating resolution request
Merging main brought in #1219, which added getFloatingResolutionRequest
as a second construction site for JdkResolutionRequest. It predates the
required `platform` field, so the merged tree did not compile.
The floating request already carries `source`, which pins the artifact
bytes, so this changes no lookup behaviour on its own -- it keeps the two
request builders consistent and the tree building.
Also refreshes dist/, which the textual merge left stale.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
A floating Oracle JDK or Oracle GraalVM request now skips the tool-cache
short-circuit entirely, so every job re-downloads and re-extracts the JDK
even when the exact bytes the mutable URL currently serves are already
installed locally.
The JDK resolution cache is keyed on the artifact's checksum (or, failing
that, its HTTP response fingerprint), so a hit proves which concrete
version the URL is serving right now. Once it has vouched for that
version, an existing tool-cache installation of exactly that version is
the artifact the download would have produced, and can be reused.
Reuse is therefore gated on the resolution cache hit, never on the
requested major: an unidentified floating artifact still downloads, as
does an explicit force-download.
Co-authored-by: Bruno Borges <brunoborges@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f2d9a891-a680-4b35-9644-cf2450f76f6d
* Isolate Maven signing keys
Import signing keys into an action-owned temporary GPG home, export GNUPGHOME, and remove the owned directory in the post action. Cover import failure, multiple keys and invocations, unrelated keyrings, missing state, and Windows path conversion.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Fix cleanup state assertion
Account for isolated GPG-home cleanup when cache saving is disabled.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Update generated action bundles
Apply repository formatting and commit the setup and cleanup bundles produced by the validated Node 24 build.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Address isolated GPG home review feedback
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>
* 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>
* 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
The generated toolchain ID is `${vendor}_${version}`, where vendor is the
mvn-toolchain-vendor input falling back to distribution. Two places described
this incorrectly.
action.yml claimed the default was "${distribution}_${java-version}", which
is wrong whenever mvn-toolchain-vendor is set, since overriding the vendor
also changes the generated ID.
The README used `${vendor}`, which is accurate but names something that is
not an action input, leaving readers to guess where the value comes from.
Both now name mvn-toolchain-vendor and state that it falls back to
distribution.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 664777db-7250-417d-b94d-d5529ec3fec2
The JDK caching section quoted informal figures from the feature PR. The
setup-java-benchmarks repository now has a JDK cache scenario workflow that
reproduces the comparison end to end, so cite its numbers across two
independent runs and name the workflow instead.
Also record the cold-run cost, the flat build-step control, and the fact
that the job-level median is noisier than the setup-step median, so the
tradeoff is explicit rather than implying the speedup is free or precise.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 664777db-7250-417d-b94d-d5529ec3fec2
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
- Fix stale claim that java-version and distribution are always mandatory
- Fix security note that claimed no checksum/signature verification exists
- Fix jdkfile toolchain example ID (jdkfile_1.6, not Oracle_1.6)
- Clarify default toolchain ID derives from the vendor, not the distribution
- Drop stale liberica-nik fallback claim; unsupported packages are rejected
- Document IBM Semeru and add missing TOC/nav entries
- Note that advanced-usage examples target the unreleased v6 on main
- Replace retired ubuntu-20.04 runner and fix a heading level
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* 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
* Implement new feature for user authentication and improve error handling
* Clarify README review feedback
Clarify distribution case sensitivity, GHES token defaults, and cache key placeholder notation in the README.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f0ff1923-c6ca-472e-83b2-3a813ec6d781
* Update README to clarify V6 development status and enhance contributions section
* Update README to recommend permissions for setup-java action in GitHub Actions
* Restore README usage heading
Rename the quick-start section to the conventional Usage heading used by setup actions.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f0ff1923-c6ca-472e-83b2-3a813ec6d781
---------
Copilot-Session: f0ff1923-c6ca-472e-83b2-3a813ec6d781
* Optimize Maven configuration warm path
Avoid eager Maven XML initialization on warm JDK runs by using deterministic serializers for new Maven settings/toolchains files, lazy-loading xmlbuilder2 for existing toolchains merges, and deferring Maven configuration modules until after Java setup.
Add targeted tests for XML escaping, lazy xmlbuilder2 loading, concurrent Maven configuration, and a manual benchmark workflow for warm-path validation.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
* Address Maven optimization PR feedback
Make the toolchain XML generator consistently async, remove redundant Maven configuration await handling, and reuse the existing XML test helper.
Configure CodeQL to skip generated dist output so newly split vendored chunks do not report duplicate generated-code alerts.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
* Apply rubber duck review suggestions
Document XML attribute escaping, simplify Maven configuration awaiting, and add a regression test that feeds fast-path toolchains output into the merge path.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
* Delete .github/codeql/codeql-config.yml
* Update codeql-analysis.yml
* Replace xmlbuilder2 in Maven toolchain merge
Use fast-xml-parser for existing toolchains.xml parsing and serialize merged Maven toolchains deterministically. This removes the bundled xmlbuilder2 DOM/XML builder chunk from dist while preserving merge behavior for custom attributes, custom toolchains, partial entries, duplicate filtering, and escaping.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
* Move Maven benchmark out of setup-java
Remove the Maven warm-path benchmark workflow and helper script from setup-java. Benchmark coverage is being moved to actions/setup-java-benchmarks so this action repository only carries the runtime optimization, tests, and generated distribution artifacts.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
---------
Copilot-Session: 4dc58426-5e20-44cb-af16-8da0965fac3b
* 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
* Restore dependency and wrapper caches concurrently
Run primary dependency and wrapper cache restores in parallel while preserving existing outputs and save semantics.
Add unit and E2E coverage for concurrent restore behavior, wrapper cache validation, and additional-cache error handling.
Include a manual benchmark workflow for baseline-vs-candidate restore timing comparisons across OSes.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: d43ec3dd-96c7-4eb3-909e-b8123cd12d3c
* Address PR review comments
Use env variables for cache-hit values in benchmark record steps to avoid expression expansion in run commands, and rename E2E restore step labels for clarity.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: d43ec3dd-96c7-4eb3-909e-b8123cd12d3c
* Stabilize wrapper cache restore checks
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: d43ec3dd-96c7-4eb3-909e-b8123cd12d3c
Run a representative smoke matrix on pull requests and main while reserving the exhaustive compatibility matrix for scheduled, manual, and release-branch runs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 235c81b4-58ae-494e-9907-e19c841c6a53
Make the setup entrypoint import-safe and cover its validation, installation sequencing, post-install collaborators, caching, and failure handling directly.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a5ba8975-a9ac-4d2c-b41d-97c99689d1bd
* Fix missing wrapper cache distributions
Skip optional Maven and Gradle wrapper cache saves when their distribution paths do not exist, while allowing the main dependency cache to save.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a43181c5-548d-4293-be58-b76c03cece79
* Use resolved paths for wrapper cache saves
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a43181c5-548d-4293-be58-b76c03cece79
* Rebuild action distributions
Regenerate the setup and cleanup bundles after updating additional cache saves to use resolved paths.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a43181c5-548d-4293-be58-b76c03cece79
---------
Copilot-Session: a43181c5-548d-4293-be58-b76c03cece79
* Clarify credential environment variable inputs
Rename credential-related inputs to make their environment-variable semantics explicit while preserving deprecated aliases with migration warnings.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 70a3daa8-dbc9-4eb0-a57b-df198a459315
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* chore(deps): bump @actions/cache to 6.2.0
Bump @actions/cache from ^6.1.0 to ^6.2.0 and rebuild the vendored
dist/ bundles. 6.2.0 honors ACTIONS_CACHE_MODE to skip restore/save
when the effective cache-mode disallows it, and surfaces a
core.warning (instead of failing the run) when the cache service
denies a read/write due to token scopes.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 0046a2b8-0238-4ac6-93f6-70c4e60b5630
* chore: update licensed record for @actions/cache 6.2.0
Refresh the cached licensed dependency record so the version matches
the bumped @actions/cache 6.2.0. License text, summary, and homepage
are unchanged; only the version field was stale, which failed the
"Check licenses" CI job.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 0046a2b8-0238-4ac6-93f6-70c4e60b5630
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* Use YAML anchors to reduce boilerplate in e2e-versions workflow
No-behavior-change refactor. Introduces a `&checkout_step` anchor for the
identical Checkout step (aliased via `*checkout_step` in the other 16 jobs)
and a `&default_os` anchor for the common
`[macos-latest, windows-latest, ubuntu-latest]` matrix list (aliased via
`*default_os` in the 11 other jobs that use that exact list). Lists that
differ (macos-15-intel, ubuntu-latest only, windows-latest+ubuntu-22.04)
are left untouched. Once anchors are expanded the document is byte-for-byte
equivalent to the original.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Fix merge conflicts: adopt consolidated jobs from main, preserve YAML anchors
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Merge the three EA jobs (zulu, temurin, sapmachine) into a single
setup-java-ea-versions job driven by a matrix include list, and merge
the two signature-verification jobs (temurin, microsoft) into a single
setup-java-signature-verification job with a distribution matrix
dimension. Test coverage is unchanged: all 15 EA combos and all 12
signature combos still run.
Copilot-Session: 9924b163-0ad2-4f8c-b038-0f00220a3157
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Extract repeated directory-check assertions into check-dir.sh helper
The e2e-cache.yml workflow repeated the same inline shell block many times
to assert a cache directory exists (and list it), plus inverse checks that a
directory does NOT exist (the gradle2/maven2/sbt2 cache-miss jobs).
Add `__tests__/check-dir.sh` (POSIX sh, executable) with a
`check-dir.sh <dir> [present|absent]` interface and replace every inline
check with a call to it, passing already-expanded $HOME paths to avoid
tilde-expansion pitfalls. The sbt jobs override working-directory, so they
call the helper via $GITHUB_WORKSPACE. Per-OS Coursier conditionals and all
build steps are left unchanged.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Address review: argc guard in check-dir.sh, fix sbt ubuntu matrix conditionals
- check-dir.sh: with set -u, invoking without a <dir> argument failed with an
opaque "parameter not set" error. Add an explicit argc check that prints a
usage message and exits 2 (distinct from the assertion failure code 1).
- e2e-cache.yml: the sbt-save and sbt-restore jobs run on an ubuntu-22.04
matrix entry, but their coursier-cache steps were guarded by
'if: matrix.os == "ubuntu-latest"', so those checks never executed on
Ubuntu. Align the conditionals with the matrix (ubuntu-22.04), matching the
newer sbt1/sbt2 jobs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Use gpg.passphraseEnvName instead of gpg.passphrase server
The maven-gpg-plugin's `gpg.passphrase`/`passphraseServerId` mechanism is
deprecated and fails when the plugin's `bestPractices` mode is enabled.
Stop writing the `gpg.passphrase` server to settings.xml and instead set
`gpg.passphraseEnvName` via an active profile when the configured passphrase
env var name differs from the plugin default (MAVEN_GPG_PASSPHRASE).
The default `gpg-passphrase` input value (GPG_PASSPHRASE) is unchanged, so the
plugin reads the same environment variable as before.
Fixes#760
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Fix settings.xml publishing validation
Update the publishing e2e check to assert the settings.xml generated when gpg-passphrase is MAVEN_GPG_PASSPHRASE. In that default case the action no longer writes a gpg.passphrase server entry.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Default gpg-passphrase to MAVEN_GPG_PASSPHRASE
Align the default `gpg-passphrase` input value with the maven-gpg-plugin
default environment variable name (MAVEN_GPG_PASSPHRASE). With this default,
setup-java writes no extra GPG configuration to settings.xml and the plugin
reads the passphrase from MAVEN_GPG_PASSPHRASE out of the box.
Also document that reading the passphrase from an environment variable via
`gpg.passphraseEnvName` requires maven-gpg-plugin 3.2.0 or newer.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Document gpg-passphrase breaking change in V6
Add a "Breaking changes in V6" section to the README covering the switch to
gpg.passphraseEnvName, the new MAVEN_GPG_PASSPHRASE default, and the
maven-gpg-plugin 3.2.0+ requirement.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Keep GPG_PASSPHRASE default for v5 compatibility
Revert the gpg-passphrase input default back to GPG_PASSPHRASE so existing v5
workflows that set the GPG_PASSPHRASE environment variable keep working without
changes. setup-java writes gpg.passphraseEnvName=GPG_PASSPHRASE into an active
profile, so the maven-gpg-plugin reads the same variable as before.
The only remaining compatibility requirement is maven-gpg-plugin 3.2.0+, which
is documented in the README and advanced usage guide.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Clarify GPG passphrase profile compatibility
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Merge cache-dependency-path e2e workflow into e2e-cache
Fold the standalone 'Validate cache with cache-dependency-path option'
workflow into e2e-cache.yml and delete the separate file. The three
gradle1-save/gradle1-restore/gradle2-restore jobs are copied verbatim,
preserving their matrix, cache-dependency-path inputs, and needs
relationships. No change in test coverage.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 635b89fa-5c35-49e1-a257-dc9001ebb8db
* Add cache-dependency-path e2e coverage for maven and sbt
Previously only gradle exercised the cache-dependency-path input. Mirror
the gradle save/restore(hit)/restore(miss) pattern for maven and sbt:
- maven1-save/maven1-restore/maven2-restore
- sbt1-save/sbt1-restore/sbt2-restore
Each save+restore pair uses the same cache-dependency-path so the restore
is a hit, while the second restore points at a new maven2/sbt2 fixture
whose different dependencies produce a different hash, so the cache is a
miss (directory not created). New fixtures added under __tests__/cache.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 635b89fa-5c35-49e1-a257-dc9001ebb8db
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Cache Maven wrapper distribution separately from the local repository
The Maven wrapper distribution (~/.m2/wrapper/dists) was cached in the same
entry as the local Maven repository (~/.m2/repository), keyed on a hash of
**/pom.xml (plus wrapper properties and extensions). Because pom.xml changes
frequently and no restoreKeys are used (by design, #269), almost every change
produces a full cache miss and the wrapper distribution is re-downloaded via
mvnw — which intermittently fails due to upstream rate limiting.
The wrapper distribution only depends on maven-wrapper.properties, which
changes very rarely. Give it its own cache entry keyed solely on
**/.mvn/wrapper/maven-wrapper.properties so it survives the frequent pom.xml
changes that rotate the main dependency cache key.
- Add a generic additionalCaches concept to PackageManager, restored and saved
independently with name-scoped state keys.
- Move ~/.m2/wrapper/dists out of the main maven path into a maven-wrapper
additional cache; skip silently when the project does not use mvnw.
- Keep cache-hit / cache-primary-key outputs driven by the main cache.
- Update tests, docs, and rebuild dist bundles.
Fixes#1095
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Cache Gradle wrapper distribution separately from the dependency cache (#1098)
The Gradle wrapper distribution (~/.gradle/wrapper) only depends on
gradle-wrapper.properties, which changes rarely, but it was previously
cached in the same entry as ~/.gradle/caches, keyed on volatile
**/*.gradle* files with no restoreKeys (issue #269). Every dependency
change therefore re-downloaded the wrapper.
Move ~/.gradle/wrapper into a dedicated `gradle-wrapper` additional
cache keyed only on **/gradle-wrapper.properties, reusing the
additionalCaches infrastructure introduced for the Maven wrapper fix.
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>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+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>
* Fix broken try/catch in saveAdditionalCache and rebuild dist
The autofix commits dropped the `} catch (error) {` line in
saveAdditionalCache, leaving a `try` block without a catch and a dangling
`error` reference, which broke compilation and Prettier. Restore the catch
clause, reformat, and regenerate the dist bundles.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Address cache.ts review feedback
- saveAdditionalCache: handle @actions/cache ValidationError (thrown when the
cache paths do not resolve, e.g. the wrapper distribution was never
downloaded) by skipping instead of failing the post step. Add a test.
- Point the Gradle wrapper cache comment at issue #269 (Gradle wrapper cache
churn) instead of the Maven-specific #1095.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Document Gradle Wrapper distribution caching in README
Add a parallel "Gradle Wrapper" note alongside the Maven Wrapper note, so the
new behavior for cache: 'gradle' (caching ~/.gradle/wrapper in a separate entry
keyed on **/gradle-wrapper.properties) is documented.
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>
* Update recommended configuration for GPG signing
This attempts to document the new recommended configuration to sign artifacts with the maven-gpg-plugin as part of the deploy process.
It imitates this PR from the maintainer of the maven-gpg-plugin:
https://github.com/xerial/sqlite-jdbc/pull/1082/files
Notes that this requires the maven-gpg-plugin version 3.2.0 or above, not sure if this is worth adding to the documentation as I expect this guide will mostly be followed by people setting up a new project (hopefully using the latest version of the plugin by default).
@cstamas I hope I got it right, feel free to suggest any improvements
* Remove unnecessary comment
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* docs: tidy GPG signing section for bc signer
- Remove leftover gpg.passphrase server from the GitHub Packages settings.xml example
- Clarify that the bc signer needs no gpg binary, keychain import, or pinentry loopback
- Document the legacy gpg-private-key/gpg-passphrase input path alongside it
- Note the MAVEN_GPG_KEY must be an ASCII-armored (TSK) secret key
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 50be9bf4-3414-43f2-8454-03c2d9e61973
* docs: add legacy GPG signing example alongside bc signer
Restore a complete, clearly-labeled legacy path (setup-java gpg-private-key/
gpg-passphrase inputs) for maven-gpg-plugin < 3.2.0 or the gpg executable:
full workflow YAML, the generated gpg.passphrase server, and the
--pinentry-mode loopback pom.xml snippet.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 50be9bf4-3414-43f2-8454-03c2d9e61973
---------
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Add the `liberica-nik` distribution (Liberica Native Image Kit), a
GraalVM-based build from BELL Software resolved via the Bell-SW
`/v1/nik/releases` API.
- `java-version` matches the embedded JDK version (from the release's
`liberica` component), consistent with every other distribution.
- `java-package: jdk` installs the `standard` bundle; `jdk+fx` installs
the `full` bundle with JavaFX/Swing support.
- Supported on Linux, macOS and Windows for x64 and aarch64.
Signed-off-by: asm0dey <pavel.finkelshtein@gmail.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* Preserve Maven toolchains across repeated setup-java runs (#1099)
Toolchain generation was gated behind the `overwrite-settings` input,
which is documented to control only regeneration of `settings.xml`.
Because `generateToolchainDefinition` already performs a non-destructive
merge (existing JDK, custom, and user-managed toolchains are preserved,
and only an entry with the same `type` + `provides.id` is replaced),
skipping the write when `overwrite-settings: false` caused later
setup-java executions to drop toolchain entries registered by earlier
runs.
Decouple toolchains generation from `overwrite-settings`: the toolchains
file is now always written, so consecutive runs accumulate every JDK.
`settings.xml` behavior (auth.ts) is unchanged.
- src/toolchains.ts: drop overwriteSettings from configureToolchains /
createToolchainsSettings / writeToolchainsFileToDisk; always write.
- __tests__/toolchains.test.ts: update call sites, rewrite the
"does not overwrite" test to assert non-destructive extension, and add
a regression test for consecutive configureToolchains executions.
- docs/advanced-usage.md: clarify merge is non-destructive and
independent of overwrite-settings.
- dist/setup/index.js: rebuilt.
Fixes#1099
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 0bcec457-b86b-4902-b6e6-6dfd6b2570f7
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+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>
---------
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>
- Update Tencent Kona documentation to list JDK 25 as supported
- Add Kona 25 to the e2e verification matrix (ubuntu, windows, macos)
- Extend Kona test fixture with real Kona 25.0.3 release entries
- Add unit tests covering Kona 25 selection across all platforms
Signed-off-by: John Jiang <johnsjiang@tencent.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* 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>
Address post-merge review feedback on #1094: the intro paragraph
described the cache too narrowly. setup-java caches both
~/.m2/repository and ~/.m2/wrapper/dists, and the default key hashes
**/pom.xml plus .mvn/wrapper/maven-wrapper.properties and
.mvn/extensions.xml, so changing wrapper/extensions files also
invalidates the cache.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: document Maven cache seeding for plugin dependencies (#990)
Explain that setup-java's maven cache only stores what a run downloads and
is not re-saved on a hit, so plugin dependencies resolved lazily (e.g. by
maven-shade-plugin) can be missing from the cache. Document a dependency
resolution 'seed' step (dependency:go-offline + dependency:resolve-plugins)
in README and a fuller advanced-usage section with a goal-comparison table,
single-job and separate-seed-job examples, and caveats.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: note gradle cache has the same limitation, point to setup-gradle (#990)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: shorten README maven cache note, link to advanced docs (#990)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: cover the parallel multi-job cache race in the seed-job example (#705)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Java's version scheme (JEP 322) can contain more than the three numeric
fields SemVer allows, e.g. 18.0.1.1 or 11.0.9.1. normalizeVersion()
rejected these inputs. Convert exact multi-field versions to SemVer build
notation (18.0.1.1 -> 18.0.1+1) before validation, reusing the existing
convertVersionToSemver() helper. Ranges, EA tags, and inputs that already
carry build metadata are left untouched.
Fixes: #326
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* feat: expose cache-primary-key output (#597)
Expose the primary cache key computed by the caching logic as a new
`cache-primary-key` action output, so workflows can compose the built-in
setup-java cache key with actions/cache or actions/cache/restore across
steps and dependent jobs.
- src/cache.ts: set the `cache-primary-key` output in restore()
- action.yml: declare the new output
- README.md: document the new output
- __tests__/cache.test.ts: assert the output is set
- dist: rebuild
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>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+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>
* chore: rebuild dist
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>
The javac problem matcher only recognized javac's native diagnostic
format (File.java:12: warning: msg), which works for plain javac and
Gradle but not Maven. The maven-compiler-plugin reformats diagnostics
to [WARNING] /path/File.java:[12,5] msg, so Maven builds produced zero
annotations.
Add a new maven-javac matcher owner that recognizes the Maven format,
capturing severity, file, line, column, and message. Maven builds now
annotate consistently with Gradle and plain javac.
Fixes: #1085
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Infer distribution from asdf .tool-versions vendor prefix
asdf-java encodes the JDK vendor as a prefix on the version string in
.tool-versions (e.g. `java temurin-17.0.3+7`). Capture that prefix and
map it to a setup-java distribution, mirroring the existing .sdkmanrc
behavior. Unknown prefixes warn and fall back to the distribution input.
Fixes#1081
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>
---------
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>
* Rename jdkFile input to jdk-file with deprecated alias
Add a standardized `jdk-file` input to match the lowercase-dash naming
used by every other action input. The camelCase `jdkFile` input is kept
as a deprecated alias: it still works, but emits a deprecation warning and
may be removed in a future release. `jdk-file` takes precedence when both
are provided.
Updates docs and the local-file e2e workflow (one case intentionally keeps
using the deprecated alias for coverage) and regenerates the dist bundles.
Fixes#1077
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: keep jdkFile in switching-to-v2 guide
The switching-to-v2 migration guide uses actions/setup-java@v2, which only supports the camelCase jdkFile input. Keep the new jdk-file spelling in current-version docs only.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The Azul Metadata API's `arch=x86` returns both 32-bit (i686) and 64-bit
(x64) packages. Because the two variants share identical java_version and
distro_version, setup-java cannot distinguish them and may resolve an
explicit `architecture: x86` request to a 64-bit JDK (and for Java 21+,
where 32-bit is dropped, x86 silently returns x64 instead of failing).
The legacy Zulu Discovery API used `arch=x86&hw_bitness=32` to target only
32-bit builds. The Metadata API exposes the equivalent via `arch=i686`,
which returns only genuine 32-bit builds with full version parity to the
old behavior. Map x86 -> i686 to restore correct 32-bit resolution.
Co-authored-by: Copilot App <223556219+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>
* Initial plan
* feat: add .mvn/extensions.xml to Maven cache key pattern
Closes#990
Maven build extensions declared in `.mvn/extensions.xml` can introduce
additional plugin dependencies (e.g. lifecycle participants, custom
packaging types). Including this file in the cache key hash ensures that
changes to extensions — which affect what plugin JARs Maven downloads —
properly invalidate the cache, preventing stale caches from missing
newly-required plugin dependencies.
Changes:
- src/cache.ts: add `**/.mvn/extensions.xml` to Maven pattern array
- __tests__/cache.test.ts: update pattern expectations; add new test
- README.md: document the new file in the Maven cache key hash list
* test: update maven cache error test name for extensions.xml
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* Use Azul metadata API
* Document arm64 -> aarch64 mapping in README.md
* Paginate through all available versions
* Fix typo: win_aarhc4
* Only query for linux_glibc packages
* Add Zulu CRaC package support to metadata migration
Fold CRaC-related work into the Zulu metadata API migration by wiring crac_supported query handling, extending Zulu package docs, and updating installer tests for jdk+crac/jre+crac behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Harden Zulu metadata pagination with safety cap
- Stop paginating on a short page to avoid an extra empty request
- Guard against undefined results (not just null)
- Cap iterations at 100 pages and warn if the limit is hit to
prevent a runaway loop if the API misbehaves
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Preserve JDK build number from Azul Metadata API
The Azul Metadata API returns java_version as a 3-element array
(e.g. [17,0,7]) and reports the build number separately in
openjdk_build_number. The migration mapped version directly from
java_version, dropping the build and breaking exact-version lookups
like 17.0.7+7 (e2e failure: "No matching version found for SemVer").
Add openjdk_build_number to IZuluVersions and append it to
java_version before converting to semver so resolved versions retain
the build (e.g. 17.0.7+7). Update the zulu test fixtures to mirror the
real API shape (3-element java_version plus openjdk_build_number) so
unit tests exercise the actual response format, and rebuild dist.
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>
* feat: Add distribution detection support to .sdkmanrc file
Extends .sdkmanrc support to automatically detect Java distribution from SDKMAN identifiers (e.g., java=21.0.5-tem maps to temurin distribution).
Makes distribution input optional when using .sdkmanrc with distribution suffix.
* fix: align SDKMAN sem identifier mapping
* fix: support SDKMAN albba identifier
* docs: clarify sdkmanrc distribution inference scope
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add Tencent Kona SDKMAN mapping and format sdkmanrc docs as a table
- Map SDKMAN 'kona' identifier to the 'kona' distribution (added in #672)
- Add a .sdkmanrc test case for the kona suffix
- Convert the inline SDKMAN suffix mapping in advanced-usage.md to a table
- Rebuild dist bundles
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
* docs: document the Java problem matcher and how to disable it
Add an advanced-usage section explaining the javac/java problem matcher that
setup-java registers, and how to turn it off for a job using the built-in
::remove-matcher:: workflow command (owners javac and java).
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: document Maven Wrapper caching and generated interactiveMode
- README: note that cache: 'maven' also caches/restores the Maven Wrapper
distribution (~/.m2/wrapper/dists), not just the local repository.
- advanced-usage: note that the generated settings.xml sets interactiveMode=false
for non-interactive CI runs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Clarify Java problem matcher annotations
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.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>
* fix: Maven Toolchains grows unexpectedly
On self-hosted runners toolchains.xml may survive multiple runs and unexpectedly
grow as a result of the toolchains setup simply appending the JDK definition
even if one with the same `type` and `provides.id` already exists.
Restructuring the parsing step and filtering the potentially existing list of
toolchain definitions prevents this and also fixes toolchain.xml files that
already contain duplicates.
Fixes#530
* fix: guard toolchain dedup and preserve existing root attributes
Address reviewer feedback on the Maven toolchains dedup logic:
- Treat jdk toolchains without a string `provides.id` as non-deduplicatable
and use optional access when comparing ids, so partially-formed or
nonstandard toolchains.xml files no longer crash setup.
- Preserve the existing `<toolchains>` root attributes (xmlns,
schemaLocation, …) when present, falling back to the 1.1.0 defaults only
for attributes the existing file is missing. This avoids silently
rewriting user-managed metadata or changing the effective namespace.
Adds tests covering custom root attributes and id-less jdk toolchains, and
rebuilds dist/.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* feat: suppress Maven transfer progress via MAVEN_ARGS by default
Set MAVEN_ARGS to include -ntp (--no-transfer-progress) so Maven invocations
in the job produce cleaner CI logs without download/transfer progress noise.
Add a new optional 'show-download-progress' input (default false); set it to
true to keep the progress output.
The change preserves any existing MAVEN_ARGS value (the flag is appended,
not overwritten) and is idempotent (it won't add the flag twice if -ntp or
--no-transfer-progress is already present). Applies on all platforms; honored
by Maven 3.9.0+ and the Maven Wrapper, and is a no-op for non-Maven builds.
- action.yml: add show-download-progress input
- src/constants.ts: add input + MAVEN_ARGS constants
- src/maven-args.ts: new configureMavenArgs()
- src/setup-java.ts: invoke configureMavenArgs() during setup
- __tests__/maven-args.test.ts: unit tests
- docs/advanced-usage.md: document the behavior and input
- dist: rebuild bundled action
Co-authored-by: Copilot <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>
* Update generated dist for Maven args log change
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* Updated jetbrains https.request command to catch errors. This fixes leaking tests as well
* Removed deprecated lines from pre-commit and pre-push
* added suggestion from PR feedback
* Add verify-signature plumbing and Temurin verification support
* Rebuild dist after signature verification changes
* Refine signature verification errors and regenerate dist
* refactor: make gpg.ts generic, move Adoptium-specific constant to temurin distribution
* fix: mock renameWinArchive in temurin tests and add signature e2e job
* refactor: bundle Adoptium public key, replace keyserver lookup with local import
* feat: add verify-signature-public-key input to allow custom GPG key override
* refactor: extract Adoptium public key to adoptium-key.ts; tighten gpg.ts cleanup scope
* Add verify-signature plumbing and Temurin verification support
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+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>
* Add Microsoft signature verification support
* Regenerate dist bundles for Microsoft signature checks
* Harden Microsoft signature URL handling
* Add setup-java-microsoft-signature-verification e2e job
* chore: regenerate dist files
* Fix e2e-versions: remove duplicate job, update signature jobs to checkout@v7 with env vars
* Fix Prettier formatting in test files
* fix: mock renameWinArchive in microsoft-installer tests to fix Windows CI failure
* fix: use --homedir flag instead of GNUPGHOME env var for Windows GPG compatibility
The Git-bundled GPG on Windows (MSYS2-based) does not automatically convert
Windows-style paths in environment variables like GNUPGHOME. This caused GPG
to fail with exit code 2 when verifying Microsoft JDK signatures on Windows,
because the GNUPGHOME path (D:\a\_temp\...) was not recognized as a valid
POSIX path.
Fix: pass --homedir as an explicit command-line argument to both gpg --import
and gpg --verify. MSYS2 does correctly convert Windows paths in command-line
arguments, so this approach works reliably on Windows, Linux, and macOS.
* fix: convert Windows paths to POSIX format for MSYS2 GPG on Windows
The Git-bundled GPG on Windows (C:\Program Files\Git\usr\bin\gpg.exe) is
an MSYS2-based binary that uses POSIX path conventions internally. When
Windows-style paths with backslashes and drive letters (D:\a\_temp\...)
are passed as arguments, GPG may fail to resolve them correctly, resulting
in a fatal error (exit code 2).
Fix: add a toGpgPath() helper that converts Windows paths to MSYS2 POSIX
format (/d/a/_temp/...) before passing them to any gpg command. On Linux
and macOS the helper is a no-op.
Applied to all four paths used in verifyPackageSignature:
- gpgHome (--homedir argument)
- publicKeyFile (--import argument)
- signaturePath (--verify signature argument)
- archivePath (--verify data argument)
* Fix gpg test formatting
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* chore: enforce pre-PR validation with aggregate scripts, git hooks, and PR checklist
Add tooling to help contributors run the same checks as CI before
submitting a pull request, reducing avoidable format/lint/build failures.
- Add aggregate npm scripts:
- `npm run check` runs format-check + lint + build + test (mirrors CI)
- `npm run fix` runs format + lint:fix + build
- Add husky + lint-staged git hooks (installed via `npm install`):
- pre-commit formats and lints staged files
- pre-push rebuilds dist/ and runs the test suite
- Add a checklist item to the PR template prompting contributors to run
`npm run check` locally
- Document the aggregate scripts and hooks in docs/contributors.md
dist/ is intentionally not auto-committed by CI to avoid pwn-request
security risks; the existing `Check dist/` workflow continues to verify it.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.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>
* docs: note jdkfile approach for Early Access / unreleased JDK builds
Clarify in advanced-usage that the existing 'jdkfile' distribution can be
used to install Early Access (EA) or other unreleased JDK builds not
provided directly by setup-java, by downloading the archive in a prior
step and pointing jdkFile at it. Adds a concrete EA example.
Addresses #612.
Co-authored-by: Copilot <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>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+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>
* Harden workflows with least-privilege permissions and zizmor
Apply GitHub Actions security best practices to the action's own
workflows and integrate zizmor to catch regressions.
- Add explicit least-privilege `permissions:` to every workflow
(contents: read for read-only workflows; default-deny `{}` with
job-scoped grants for codeql, publish-immutable-actions and
update-config-files).
- Set `persist-credentials: false` on all checkout steps that don't
need the GITHUB_TOKEN afterwards.
- Move `${{ ... }}` expansions out of `run:` blocks into `env:` vars
to avoid template injection.
- Pin the alpine container image (alpine:latest -> alpine:3.21).
- Add a zizmor CI workflow that uploads SARIF to code scanning, plus a
`.github/zizmor.yml` pinning policy (ref-pin for actions/* and
github/*, hash-pin for third-party actions).
zizmor now reports no findings (offline and online).
Co-authored-by: Copilot <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>
* Fix indentation of if: in zizmor SARIF upload step
The `if:` key on the "Upload SARIF results to code scanning" step had no
indentation, producing invalid YAML ("Nested mappings are not allowed in
compact mappings"). This broke `npm run format-check` (prettier) in Basic
validation.
Indent `if:` to 8 spaces so it nests under the step alongside uses/with.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Document how to make the installed JDK trust an internal CA at application
runtime by importing it into $JAVA_HOME/lib/security/cacerts with keytool
after setup-java runs. Clarifies this is the runtime trust layer, distinct
from the download/transport layer (NODE_EXTRA_CA_CERTS), and notes hosted vs
self-hosted persistence caveats.
Refs #640#1035
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds an advanced-usage section explaining the 'self signed certificate in
certificate chain' error seen on GitHub Enterprise Server and behind
TLS-inspecting proxies. Recommends the secure fix of trusting the internal
CA via NODE_EXTRA_CA_CERTS (or the OS trust store on self-hosted runners),
with a GitHub Enterprise callout, and warns against disabling TLS
verification since the JDK download has no checksum fallback.
Refs #640
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Initial plan
* docs: replace HelloWorldApp references with java --version in README and advanced-usage
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* docs: enhance custom jdk file installation
* Update jdkFile note for case sensitivity
Clarify that 'distribution' must be set to 'jdkfile' in lowercase when using jdkFile input.
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
* Update undici license cache to 6.27.0
The Licensed check failed because the cached license record for undici
was pinned to 6.24.1 while the installed dependency is 6.27.0, causing
"license: mit, allowed: false" / source enumeration errors.
Regenerate the cached record with `licensed cache` so it matches the
installed version. `licensed status` now reports 0 errors.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Rebuild dist with undici 6.27.0
The committed dist/ bundle was built with undici 6.24.1, but the
lockfile resolves undici 6.27.0. The check-dist workflow rebuilds the
bundle and detected this drift (uncommitted changes after build).
Rebuild dist/setup and dist/cleanup with `npm run build` so the
committed bundle matches the installed undici 6.27.0, aligning with the
license cache update in this PR.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add required: false to java-version, java-version-file, job-status, and token, which had defaults or were optional but lacked the explicit flag
- Add default: '' to gpg-private-key to match its stated description
- Fix java-version-file description: the input accepts .java-version, .tool-versions, and .sdkmanrc, not only .java-version
- Fix gpg-passphrase description: GPG_PASSPHRASE is only defaulted when gpg-private-key is provided, not unconditionally
Co-authored-by: Kranthi Poturaju <Kranthi.Poturaju1@aexp.com>
Co-authored-by: Panuganti Saketh <sakethpanuganti@gmail.com>
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
Distributions like JetBrains Runtime publish 4-segment versions such as
'17.0.8.1+1080.1' that the semver package rejects. Both compareBuild and
satisfies throw on these, which surfaced to users as "Error: Invalid
Version: 17.0.8.1+1080.1" and aborted the whole install when any
available version was non-semver. Guard with an early semver.valid check
so unparseable versions are treated as a non-match.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Make the Adoptopenjdk package type look at the Temurin repo first for latest assets
* Address Copilot code review comments
- Use strict equality (===, !==) instead of loose equality (==, !=) for all comparisons
- Properly handle caught errors with instanceof type narrowing before accessing properties
- Only fall back to legacy AdoptOpenJDK for specific version-not-found errors
- Rethrow unexpected errors to avoid masking real issues (network failures, rate limits, etc.)
- Fix error message check to match actual error text ('No matching version found')
- Remove unnecessary undefined check since method return type is never undefined
- Add @internal JSDoc annotation to TemurinDistribution.findPackageForDownload()
- Update tests to properly mock Temurin lookup failures for fallback behavior testing
- Rebuild dist files
* Always fall back to legacy AdoptOpenJDK but log all Temurin failures
- Change error handling to gracefully fall back for all errors, not just version-not-found
- Log version-not-found errors as notices with migration guidance
- Log other Temurin failures as debug messages for troubleshooting
- Improves resilience: users always get a result even if Temurin API has issues
- Maintains visibility: failures are still logged for debugging
* Fixes from review
* Fixes from review
* Fixes from review
* Regenerate dist
* Use Link headers for Adoptium pagination
* Fix nullable pagination URL types and rebuild dist
* Add 1000-page safeguard for JetBrains pagination
* Adjust plan for pagination safeguard scope
* Move pagination safeguard to non-JetBrains installers
* Add 1000-page safeguard to Adopt Temurin and Semeru pagination
* Fix Prettier formatting in adopt, semeru, and temurin installer files
* Fix CI audit failure by updating vulnerable transitive deps
* Address PR review: RFC-compliant Link parsing, SSRF validation, centralized constant
- Make getNextPageUrlFromLinkHeader RFC 8288 compliant by splitting
link-values and checking for rel=next anywhere in the parameters,
not just as the first parameter after the semicolon.
- Add validatePaginationUrl utility to reject pagination URLs that
point to unexpected origins (SSRF mitigation).
- Centralize MAX_PAGINATION_PAGES in util.ts instead of duplicating
across Adopt, Semeru, and Temurin installers.
- Add tests for rel not being the first parameter, and for URL
origin validation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Address code review feedback on pagination implementation
- Tighten rel regex with word boundary to prevent false positives
(e.g., rel="nextsomething" no longer matches).
- Use parsed.origin comparison in validatePaginationUrl to correctly
handle explicit default ports (e.g., :443 for HTTPS).
- Fix pagination safeguard tests to use same-origin URLs so they
actually exercise the 1000-page limit instead of being rejected
by origin validation on the first request.
- Add test for rel="nextsomething" not matching.
- Add test for explicit default port acceptance.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix prettier formatting in util.test.ts
* Rebuild dist/ to fix check-dist CI failure
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.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
Updated the Java version in the README setup examples from 21 to 25
to reflect the latest supported version. This change ensures that
users are guided to use the most current Java version for their
projects.
- Updated all instances of 'java-version: 21' to 'java-version: 25'
- Modified supported version syntax to include '25'
* Upgrade @actions/cache to v5
- Bump @actions/cache from 4.0.3 to 5.0.0
- Update license cache files for new/updated dependencies
- Rebuild dist bundles
- Mark @actions/http-client as reviewed in licensed config (MIT license text present but detected as 'other')
* chore: Update version to 5.0.1 in package.json and package-lock.json
* upgrade actions/cache to 5.0.1
---------
Co-authored-by: Aparna Jyothi <aparnajyothi-y@github.com>
* chore(e2e-versions): Add e2e test scenario on `setup-java-version-from-file-major-minor-patch-with-dist` for `.sdkmanrc`
* chore(e2e-versions): Update `setup-java-version-from-file-major-minor-patch-with-dist` test to include the file name of the java-version-file that is used
* feat: Add support for `.sdkmanrc` as *Java Version File*
* chore: Add test for the latest known sdkman java versions
* docs(advanced-usage): Document support for `.sdkmanrc` as java-version-file
* chore(docs): Anyone can contribute and maintain 🤷
* Update advanced-usage.md
Add example step/file for `.sdkmanrc`
* Update advanced-usage.md
* Update util.ts
* chore: format and rebuild
* chore: untouch toolchains.ts
* fix check dist error
---------
Co-authored-by: mahabaleshwars <147705296+mahabaleshwars@users.noreply.github.com>
* 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
This workflow file publishes new action releases to the immutable action package of the same name as this repo.
This is part of the Immutable Actions project which is not yet fully released to the public. First party actions like this one are part of our initial testing of this feature.
* Updated Error message for Semuru
* Enhanced error message
* Added architecture to semeru
* updated code to provide aarch64 for arm64 architecture for semeru
* updated semver message
* updated semver error message
* Enhanced the error message for semeru
* Enhanced error messaged for semeru distribution
* enhanced error message for semeru
* patch to extract file from other location
* patch to extract filename from other directories
* removed code failing checks
* changed the validation for .java-version type
* added support for tool version file
* testing with one regex
* working regex
* Checked for the file extension
* added e2e checks for tool version
* removed error warning
* updated regex to support early version
* updated regex for early version support
* updated regex for early version
* updated regex to accept early versions
* added coreinfo to analyze
* updated the regex
* updated regex
* new regex for early version
* updated regex to match the new version file format
* new regex
* changed the regex
* redex updated
* used java version regex
* regex updated
* regex modified
* regex updated
* regex updated
* regex updated
* updated regex to support early versions
* Regex updated to support all java versions
* Documentation updated to add tool version description
* Documentation updated for the tool version file
* update the advanced doc and readme file to specify tool version changes
* Added Windows Arm64 Support for Windows Arm64 Runners
* microsoft test file update and tool-version test file
* Delete .DS_Store
* added test cases for windows and linux for zulu, liberica and microsoft
* adding different data files for each OS
* added changes to distribution files
* added more version support for microsoft
Update examples and references to Java where older Java versions are used to
highlight the support of Java 21.
Specific provider examples are only updated where they support Java 21.
Fixes#557
* Fixing issues with the handling of the token and avoiding error on when the token is undefined
* chore: rebuild action
---------
Co-authored-by: Ivan Zosimov <ivanzosimov@github.com>
* eat: bump to use node20 runtime, actions/checkout to v4
* docs: update version of setup-java in documentation and e2e tests
---------
Co-authored-by: Ivan Zosimov <ivanzosimov@github.com>
* Add versions properties to cache
* lint fix
npm run format change
* [FIX] unit test
* docs: fix typo in the Readme.md
* docs: update link to the toolkit/cache package
---------
Co-authored-by: Ivan Zosimov <ivan.zosimov@Ivans-MacBook-Pro.local>
Azul API stopped to support arm64 architecture, the only supported
option for ARM cpus is now 'arm'. This requires to set up hw_bitness
properly to get 64 bits version. 32 bits version can be obtained by
using 'arm' as an architecture.
* Add microsoft distribution of the JDK.
* Fix formatting to match prettier.
* Rebuild js.
* Fix archive suffix for Windows.
* Update src/distributions/microsoft/installer.ts
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
* Update src/distributions/microsoft/installer.ts
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
* Add support for the microsoft distribution.
* revert lockfile changes
* npm run format
* fix e2e-versions.yml
* eliminate duplication in version numbers
* Fix test
Co-authored-by: Brendan Burns <brendan.d.burns@gmail.com>
Co-authored-by: Brian Cristante <33549821+brcrista@users.noreply.github.com>
This deletes the secret key(s) and public keys(s) for the fingerprint
of the installed GPG_PRIVATE_KEY.
If the installed GPG_PRIVATE_KEY only contains a signing subkey without
the primary private key, the --delete-secret-and-public-key will
successfully delete the keys.
Signed-off-by: BJ Hargrave <bj@hargrave.dev>
To cache deps successfully even on Windows, it's better to add `--no-daemon` option
to the Gradle build, or the save process will fail due to 'permission denied' error.
refs https://github.com/actions/cache/issues/454
* implement a core logic to cache dependnecies
* integrate the cache logic to entry points
* add a user doc about the dependency cache feature
* reflect changes to the dist dir
* add a prefix to the cache key
https://github.com/actions/setup-java/pull/193/files#r669521434
* test: extract build.gradle to a file in __tests__ dir
* run the restore e2e test on the specified OS
* add an e2e test for maven
* fix the dependency among workflows
* stabilize the cache on the Windows in e2e test
* add .gitignore files to __tests__/cache directories
* try to run restore after the authentication
* use the key in state to save caches in the post process
* suggest users to run without daemon if fail to save Gradle cache on Windows
* add missing description in the README.md
* run clean-up tasks in serial
* Add validation for post step (#3)
* work on fixing cache post step
* fix tests
* Update src/cleanup-java.ts
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
* Update src/cache.ts
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
* style: put the name of input to the constants.ts
* format: run `npm run build` to reflect changes to the dist dir
* chore: update licensed files by `licensed cache`
it still has three errors as follows:
>* setup-java.npm.sax
> filename: /Users/kengo/GitHub/setup-java/.licenses/npm/sax.dep.yml
> - license needs review: other
>
>* setup-java.npm.tslib-1.14.1
> filename: /Users/kengo/GitHub/setup-java/.licenses/npm/tslib-1.14.1.dep.yml
> - license needs review: 0bsd
>
>* setup-java.npm.tslib-2.3.0
> filename: /Users/kengo/GitHub/setup-java/.licenses/npm/tslib-2.3.0.dep.yml
> - license needs review: 0bsd
* fix: rerun ncc on macOS with node v12
* build: follow the suggestion at PR page
https://github.com/actions/setup-java/pull/193#issuecomment-901839546
* fix: throw error in case of no package manager file found
Co-authored-by: Dmitry Shibanov <dmitry-shibanov@github.com>
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
* Add support for Adoptium OpenJDK
Refs https://github.com/actions/setup-java/issues/191
* Rename distribution to Eclipse Temurin
* Update end-to-end tests in GitHub workflows
* Exclude e2e tests for Temurin JREs for now
* fix version
* Update e2e-versions.yml
* Handle Eclipse Temurin version suffixes ("beta")
* Add test for new version suffix "beta"
* Add updated `index.js`
* fix an issue
Co-authored-by: Maxim Lobanov <maxim-lobanov@github.com>
The extendedJavaHome environment variable contains `.` symbols in the version. This causes the environment variable to be ignored by the action runner. It's best to replace those and other non standard symbols with and underscore.
For reference:
> Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set .
This will support specifying EA versions in the following format examples. E.g.:
14-ea
14.0.0-ea
14.0.0-ea.28
Notes:
- For the last form above, which is needed for requesting a specific ea build, we must only add '.x' if there are less than 3 dots in the version, hence the change from != 3 to < 3
- The prior parsing logic for e.g. 14.0.0-ea "spelling" will ignore precedence between build numbers in the form of e.g. 14.0.0-ea+b27 vs. 14.0.0-ea+b27 (so it will end up with the earliest rather than the latest ea build in the cdn), and does not allow specifying an ea build number (it will match 14.0.0-ea+b29 to a cdn 14.0.0-ea+b2). The new logic [copupled with the CDN populating EA builds in the form 14.0.0-ea.28) will resolve that.
author Bryan Clark <clarkbw@github.com> 1573862473 -0800
committer Bryan Clark <clarkbw@github.com> 1574976093 -0800
Adding maven auth support
ignore vscode directory
move required parameters to auth module
username and password are required from within the auth module now. Update the tests to ensure this is the case.
Add generated auth and setup-java
Move auth to the bottom of setup
Support ids
generated and pretty files
use server-id instead of ambigous id
Use console.log where appropriate
Adding maven auth support
ignore vscode directory
move required parameters to auth module
username and password are required from within the auth module now. Update the tests to ensure this is the case.
Add generated auth and setup-java
Move auth to the bottom of setup
generated and pretty files
use server-id instead of ambigous id
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This action sets up a java environment for use in actions by:
Set up Java for GitHub Actions workflows. `setup-java` installs a requested Java distribution, adds it to `PATH`, configures `JAVA_HOME`, and can optionally cache build dependencies for Apache Maven, Gradle, and sbt; generate Maven publishing configuration, verify JDK package signatures, manage multiple JDKs, and manage Maven toolchains.
- optionally downloading and caching a requested version of java by version and adding to PATH. Default downloads are populated from the [Zulu Community distribution of OpenJDK](http://static.azul.com/zulu/bin/)
- registering problem matchers for error output
# Usage
See [action.yml](action.yml)
Basic:
```yaml
steps:
- uses:actions/checkout@v1
- uses:actions/setup-java@v1
with:
java-version:'9.0.4'# The JDK version to make available on the path. Takes a whole or semver JDK version, or 1.x syntax (e.g. 1.8 => Jdk 8.x). To specify a specific version for JDK 8 or older use the following pattern (8.0.x)
java-package:jdk# (jre, jdk, or jdk+fx) - defaults to jdk
architecture:x64# (x64 or x86) - defaults to x64
- run:java -cp java HelloWorldApp
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
- run:java --version
```
From local file:
> [!NOTE]
> V6 is still in development on the `main` branch and is not yet recommended for production workflows. To use it, you must explicitly reference the `main` branch in your workflow, as in
>
> ```yaml
> - uses: actions/setup-java@main
> ```
>
> For production workflows, it is recommended to use the latest stable release `v5`.
- [Supported version syntax](#supported-version-syntax)
- [Caching](#caching)
- [Multiple JDKs and Maven toolchains](#multiple-jdks-and-maven-toolchains)
- [Publishing packages](#publishing-packages)
- [Advanced usage](#advanced-usage)
## What it does
- Downloads and installs Java from a supported distribution.
- Uses a requested Java version, a version file, or the `latest` stable release alias.
- Extracts and caches a custom JDK archive from a local file.
- Configures Maven `settings.xml`, Maven Toolchains, Maven GPG signing inputs, and environment-variable based credentials for publishing workflows.
- Registers Java problem matchers for compiler diagnostics and uncaught exceptions.
- Caches dependencies for Maven, Gradle, and sbt.
- Caches downloaded JDK installations between jobs.
- Verifies downloaded archive checksums when a distribution publishes authoritative checksums.
- Optionally verifies package signatures for supported distributions.
`setup-java` works with Java, Scala, Kotlin, Gradle, Maven, and sbt projects.
## What's new
### V6 (in development)
- Migrated the action implementation to ESM to support the latest `@actions/*` packages.
- Added the `oracle-openjdk` distribution for OpenJDK builds from Oracle.
- Added `java-version: latest` to resolve the newest stable GA release from the distribution's remote metadata.
- JDK downloads now automatically verify authoritative checksums for [supported distributions](#download-integrity-and-signatures).
- Added `force-download: true` to bypass the tool cache and perform a reproducible fresh install.
- Dependency caching now supports custom paths with `cache-path` and restore-only operation with `cache-read-only: true`.
- Downloaded JDKs are now [cached](#caching-jdk-installations) automatically when `cache` is set; use `cache-jdk` to enable or disable it independently.
- Set `problem-matcher: false` to disable Java compiler and uncaught-exception annotations.
- GraalVM distributions now set `GRAALVM_HOME` in addition to `JAVA_HOME`.
- Invalid boolean values, unsupported distribution/package/platform combinations, and mismatched Maven toolchain ID counts now fail with targeted errors.
- Renamed environment-variable-name inputs so they are not mistaken for secret values:
-`server-username` -> `server-username-env-var`
-`server-password` -> `server-password-env-var`
-`gpg-passphrase` -> `gpg-passphrase-env-var`
- Deprecated aliases still work, but emit warnings.
- Maven GPG passphrases are now passed through `gpg.passphraseEnvName` instead of a deprecated `gpg.passphrase` server entry in `settings.xml`. This requires `maven-gpg-plugin` 3.2.0 or newer. See [GPG](docs/advanced-usage.md#gpg).
- Legacy AdoptOpenJDK distributions were removed. Use `temurin` instead of `adopt` or `adopt-hotspot`, and `semeru` instead of `adopt-openj9`.
### V5
- Upgraded the action runtime from Node 20 to Node 24. Self-hosted runners must use version `v2.327.1` or later. See the [runner release notes](https://github.com/actions/runner/releases/tag/v2.327.1).
- Added support for [GraalVM Community](#supported-distributions) and [Tencent Kona](#supported-distributions).
- Expanded `java-version-file` support with `.sdkmanrc` files and automatic distribution detection from SDKMAN and asdf vendor identifiers.
- Added optional package-signature verification for Eclipse Temurin and Microsoft Build of OpenJDK downloads.
- Added `set-default: false` for installing a JDK without changing `JAVA_HOME` or `PATH`.
- Improved dependency caching with separate Maven and Gradle wrapper caches, Maven extension-aware cache keys, and the `cache-primary-key` output.
- Improved Maven and Java build behavior by preserving toolchain entries across repeated action invocations, suppressing transfer progress by default, generating non-interactive Maven settings, and matching `javac` compiler errors.
- Renamed the `jdkFile` input to `jdk-file`; the old name remains available as a deprecated alias.
- See the [complete V5 release history](https://github.com/actions/setup-java/releases?q=v5&expanded=true) for enhancements and fixes across all V5 releases.
### Older versions
> [!WARNING]
> `actions/setup-java` versions `v1` through `v4` are deprecated. Upgrade workflows to `actions/setup-java@v5`, the latest stable release.
## Usage
### Install Eclipse Temurin
```yaml
steps:
- uses:actions/checkout@v1
- uses:actions/setup-java@v1
with:
java-version:'4.0.0'
architecture:x64
jdkFile:<path to jdkFile># Optional - jdkFile to install java from. Useful for versions not found on Zulu Community CDN
- run:java -cp java HelloWorldApp
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
- run:java --version
```
Matrix Testing:
### Install Microsoft Build of OpenJDK
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:microsoft
java-version:'25'
- run:java --version
```
### Read the version from a file
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version-file:.java-version
- run:java --version
```
Supported version files are `.java-version`, `.tool-versions`, and `.sdkmanrc`. A `.sdkmanrc` file can also provide the distribution when it contains a recognized suffix, such as `java=21.0.5-tem`.
### Use the newest stable Java
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:latest
- run:java --version
```
`latest` resolves the newest stable GA release from remote metadata rather than from the runner tool cache. Distributions that do not publish a release listing (such as `oracle` and `graalvm`) resolve the newest GA feature version from the Adoptium available-releases API and then request that version from their own catalog. `latest` is not supported with `java-version-file`, early-access versions, or `distribution: jdkfile`.
## Inputs
| Input | Description | Default |
| --- | --- | --- |
| `java-version` | Java version to install. Supports whole versions, semver ranges, early-access versions, and `latest`. Required unless `java-version-file` is set. | |
| `java-version-file` | Path to `.java-version`, `.tool-versions`, or `.sdkmanrc`. Used when `java-version` is not set. | |
| `distribution` | Java distribution keyword. Values are case-sensitive and must match one of the supported keywords below. Required unless `java-version-file` points to `.sdkmanrc` with a recognized distribution suffix. | |
| `java-package` | Package variant such as `jdk`, `jre`, `jdk+fx`, `jre+fx`, `jdk+crac`, `jre+crac`, `jdk+jmods`, `jdk+jcef`, `jre+jcef`, `jdk+ft`, or `jre+ft`. Support varies by distribution. | `jdk` |
| `architecture` | Package architecture. Canonical values are `x86`, `x64`, `armv7`, `aarch64`, `ppc64le`, `ppc64`, and `s390x`. Aliases `ia32`, `amd64`, `arm`, and `arm64` are normalized. | Runner architecture |
| `check-latest` | Check remote metadata for the latest version satisfying the version spec before using the runner tool cache. | `false` |
| `force-download` | Always download Java and replace any matching version in the tool cache. | `false` |
| `set-default` | Add Java to `PATH` and set `JAVA_HOME`. When `false`, only version-specific `JAVA_HOME_<major>_<arch>` variables are set. | `true` |
| `problem-matcher` | Register Java compiler and uncaught exception problem matchers. | `true` |
| `verify-signature` | Verify downloaded Java package signatures when supported. Currently supported for `temurin` and `microsoft`. | `false` |
| `verify-signature-public-key` | ASCII-armored GPG public key to use for signature verification. Overrides the bundled key. | |
| `token` | Token for fetching GitHub.com-hosted version manifests, useful on GitHub Enterprise Server when unauthenticated requests are rate-limited. | `${{ github.token }}` on GitHub.com; empty string on GHES |
| `cache` | Enable dependency caching for `maven`, `gradle`, or `sbt`. | |
| `cache-jdk` | Cache downloaded JDK installations between jobs. When omitted, JDK caching is enabled only if `cache` is set. Set explicitly to `true` or `false` to override. | Enabled when `cache` is set |
| `cache-dependency-path` | Dependency file paths used for cache key hashing. Supports globs and multiline values. | Auto-detected by package manager |
| `cache-path` | Cache paths to use instead of the package manager's default dependency cache path. Supports multiline values and exclusions. | |
| `cache-read-only` | Restore dependency, wrapper, and JDK caches without saving changes in the post step. | `false` |
| `server-id` | Maven repository ID used in generated `settings.xml`. | `github` |
| `server-username-env-var` | Environment variable name for Maven repository username. | `GITHUB_ACTOR` |
| `server-password-env-var` | Environment variable name for Maven repository password or token. | `GITHUB_TOKEN` |
| `settings-path` | Directory where `settings.xml` is written. | `~/.m2` |
| `overwrite-settings` | Overwrite an existing `settings.xml`. | `true` |
| `gpg-private-key` | GPG private key to import into an isolated temporary keyring. | |
| `gpg-passphrase-env-var` | Environment variable name for the GPG private key passphrase. | `GPG_PASSPHRASE` when a key is set |
| `mvn-toolchain-id` | Maven Toolchain ID. When multiple Java versions are installed, the number of IDs must match the number of versions. | `${mvn-toolchain-vendor}_${java-version}` |
| `show-download-progress` | Keep Maven artifact download and transfer progress in logs. When `false`, the action adds `-ntp` to `MAVEN_ARGS`. | `false` |
-`java-package`: Supported package types are `jdk`, `jre`, `jdk+fx`, `jre+fx`, `jdk+crac`, `jre+crac`, `jdk+jmods`, `jdk+jcef`, `jre+jcef`, `jdk+ft`, and `jre+ft`. Availability varies by distribution.
Deprecated aliases `jdkFile`, `server-username`, `server-password`, and `gpg-passphrase` remain accepted for compatibility, but should be replaced with the current input names.
## Outputs
| Output | Description |
| --- | --- |
| `distribution` | Distribution that was installed. |
| `version` | Actual Java version that was installed. |
| `path` | Installation path, also used for `JAVA_HOME` when `set-default` is enabled. |
| `cache-hit` | Whether an exact dependency cache match was restored. |
| `cache-primary-key` | Primary cache key computed for the selected package manager. Empty when caching is disabled or skipped. |
> Distribution availability, package variants, architectures, and version metadata differ by vendor. Check the vendor documentation when a specific version or platform matters.
Additional distribution notes:
- Oracle OpenJDK builds are archived after a limited number of releases and no longer receive security updates. To continue receiving security patches, use Oracle JDK or another vendor.
- Azul Zulu maps `arm64` to `aarch64` when querying the Azul Metadata API.
- GraalVM Community is available as `distribution: graalvm-community` for stable JDK 17 and later releases.
- On Ubuntu runners, commands executed with `sudo` do not inherit the `JAVA_HOME` and `PATH` set by `setup-java` and may fall back to the system-default JDK.
## Supported version syntax
`java-version` accepts exact versions, version ranges, early-access versions, and `latest`.
| Syntax | Examples |
| --- | --- |
| Major version | `8`, `11`, `17`, `21`, `25` |
| Specific feature or patch version | `11.0`, `11.0.4`, `17.0`, `8.0.282+8` |
| JEP 322 multi-field versions | `11.0.9.1`, `18.0.1.1` |
| Early access | `15-ea`, `15.0.0-ea`, `27-ea` |
| Latest stable GA release | `latest` |
When `check-latest` is `false`, the action first tries the runner tool cache for the requested distribution, package type, architecture, and version range. It downloads Java only when no matching cached version is found. When `check-latest` is `true`, the action checks remote metadata first and downloads if the cached version is not current.
GitHub-hosted runners primarily pre-cache Eclipse Temurin JDKs. See the installed Java versions for [Ubuntu](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md#java), [Windows](https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md#java), and [macOS](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md#java). On a fresh GitHub-hosted runner, requests for other distributions usually miss the tool cache and resolve from remote metadata. For broad version ranges such as a major version (`21`, `25`), this often behaves similarly to `check-latest: true` because the action downloads the latest available release that satisfies the range.
## Download integrity and signatures
`setup-java` automatically verifies downloaded archive checksums when a selected distribution publishes an authoritative checksum. Automatic checksum verification currently applies to `temurin`, `semeru`, `corretto`, `dragonwell`, `kona`, `sapmachine`, `graalvm`, `graalvm-community`, `zulu`, `oracle`, `oracle-openjdk`, `microsoft`, and `jetbrains`.
Distributions or individual releases without an authoritative checksum continue to install normally, with the omission reported in debug logs. Installations resolved directly from the runner tool cache — including JDKs preinstalled on the runner image and JDKs installed by an earlier step of the same job — are not downloaded again and are not reverified, even when `verify-signature: true` is set. Use `force-download: true` to always download and verify the archive.
Use `verify-signature: true` to verify package signatures for distributions that support it. Currently supported distributions are `temurin` and `microsoft`; setting it for an unsupported distribution fails the workflow.
## Caching
`setup-java` manages three kinds of caches. Each one is restored and saved as a separate cache entry.
| Cache | What it stores | Key based on | How it is enabled |
| --- | --- | --- | --- |
| Dependency cache | Downloaded dependencies, such as `~/.m2/repository`, `~/.gradle/caches`, or the sbt cache paths | Runner OS, architecture, package manager, and a hash of the dependency files | Set `cache` to `maven`, `gradle`, or `sbt` |
| Wrapper caches | Maven and Gradle wrapper distributions (`~/.m2/wrapper/dists`, `~/.gradle/wrapper`) | Runner OS, architecture, wrapper cache name, and a hash of the wrapper properties | Set `cache` to `maven` or `gradle` |
| JDK cache | The downloaded JDK installation | Runner OS, architecture, distribution, package type, resolved version, release identity, and signature-verification identity | Enabled implicitly whenever `cache` is set, or explicitly with `cache-jdk: true`. Opt out with `cache-jdk: false` |
Set `cache` to `maven`, `gradle`, or `sbt` to cache dependencies with minimal configuration.
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
cache:maven
- run:mvn verify
```
The primary dependency cache key is `setup-java-<runner-os>-<node-arch>-<package-manager>-<file-hash>`, where `<node-arch>` is the runner's Node.js process architecture. The primary cache stores dependency directories such as `~/.m2/repository`, `~/.gradle/caches`, or the sbt cache paths. Its file hash is based on these files by default:
| Package manager | Files used for the primary dependency-cache key |
`cache-path` changes what is restored and saved, but not the cache key. Jobs that should share a cache key must use the same OS, architecture, package manager, dependency files, and cache paths.
### Wrapper caches
Maven and Gradle wrapper distributions are restored and saved as additional cache entries, separate from the primary dependency cache. These entries have their own keys in the form `setup-java-<runner-os>-<node-arch>-<wrapper-cache-name>-<file-hash>`.
| Package manager | Wrapper cache name | Cached path | Files used for wrapper-cache key |
These wrapper caches are independent from dependency caches, so they remain useful even when dependency files change frequently. The wrapper properties are also part of the Maven and Gradle primary dependency-cache key because wrapper changes can affect how dependencies are resolved, but the wrapper distribution files themselves are stored in the separate wrapper cache entries above.
For advanced Gradle caching features such as build output caching, configuration cache support, encrypted cache storage, cleanup, and fine-grained cache control, consider [`gradle/actions/setup-gradle`](https://github.com/gradle/actions/tree/main/setup-gradle).
### Caching JDK installations
The JDK cache stores the downloaded JDK installation so later runs skip the download. It is enabled implicitly whenever dependency `cache` is set, so most workflows that cache dependencies are already caching the JDK. Set `cache-jdk: true` to enable it without dependency caching, or `cache-jdk: false` to opt out while keeping dependency caching. With neither `cache` nor `cache-jdk` set, nothing is cached.
> [!IMPORTANT]
> Because JDK caching is on by default whenever `cache` is set, review [Caching JDK installations](docs/advanced-usage.md#caching-jdk-installations)
> for the full `cache`/`cache-jdk` matrix, cache identity and storage impact.
### Read-only caches
Set `cache-read-only: true` to restore dependency, wrapper, and JDK caches without saving changes in the post action. This is useful for pull requests, merge queues, short-lived branches, and matrix fan-out jobs that should only consume caches produced elsewhere.
Cache downloads are split into segments. To reduce the chance of a stuck segment blocking a workflow, set `SEGMENT_DOWNLOAD_TIMEOUT_MINS`:
```yaml
env:
SEGMENT_DOWNLOAD_TIMEOUT_MINS:'5'
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
cache:gradle
- run:./gradlew build --no-daemon
```
## Multiple JDKs and Maven toolchains
Install multiple Java versions by providing a multiline `java-version` value. All configured JDKs are installed. The last one added to `PATH` becomes the default.
```yaml
steps:
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:|
8
11
17
21
25
```
Other installed JDKs are available through version-specific variables such as `JAVA_HOME_17_X64`. To use a specific version later in the job, set `JAVA_HOME` and prepend its `bin` directory to `PATH`.
`setup-java` writes a Maven Toolchains declaration for each installed JDK. When multiple JDKs are installed, the declaration contains all of them. Customize the generated toolchain values with `mvn-toolchain-id` and `mvn-toolchain-vendor`.
## Testing with a Java matrix
```yaml
jobs:
build:
runs-on:ubuntu-16.04
runs-on:ubuntu-latest
strategy:
matrix:
# test against latest update of each major Java version, as well as specific updates of LTS versions:
The scripts and documentation in this project are released under the [MIT License](LICENSE)
`setup-java` generates Maven `settings.xml` and Maven Toolchains configuration. For Gradle publishing, it installs Java for the workflow; the Gradle build file remains responsible for reading credentials from environment variables.
# Contributions
### Maven
Contributions are welcome! See [Contributor's Guide](docs/contributors.md)
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
server-id:github
server-username-env-var:GITHUB_ACTOR
server-password-env-var:GITHUB_TOKEN
- run:mvn --batch-mode deploy
env:
GITHUB_TOKEN:${{ secrets.GITHUB_TOKEN }}
```
### GPG signing
```yaml
steps:
- uses:actions/checkout@v7
- uses:actions/setup-java@v5
with:
distribution:temurin
java-version:'25'
gpg-private-key:${{ secrets.GPG_PRIVATE_KEY }}
gpg-passphrase-env-var:GPG_PASSPHRASE
- run:mvn --batch-mode deploy
env:
GPG_PASSPHRASE:${{ secrets.GPG_PASSPHRASE }}
```
Maven GPG signing requires `maven-gpg-plugin` 3.2.0 or newer because `setup-java` passes the passphrase through `gpg.passphraseEnvName`.
## Recommended permissions
When using the `setup-java` action in your GitHub Actions workflow, it is recommended to set the following permissions to ensure proper functionality:
```yaml
permissions:
contents:read# access to check out code and install dependencies
```
Publishing workflows may require additional permissions depending on the target registry.
## Advanced usage
See [advanced usage](docs/advanced-usage.md) for detailed examples:
- [Selecting a Java distribution](docs/advanced-usage.md#selecting-a-java-distribution)
'Caching is only supported on GHES version >= 3.5. If you are on a version >= 3.5, please check with your GHES admin if the Actions cache service is enabled or not.';
"Unsupported checksum algorithm 'md5' from https://vendor.example/checksum.txt"
);
expect(message).not.toContain('secret-value');
expect(message).not.toContain('token=');
expect(message).not.toContain('#private');
});
it('surfaces file read errors',async()=>{
awaitexpect(
verifyChecksum(
'/missing/archive',
{algorithm:'sha256',value:'a'.repeat(64)},
{distribution:'Test',version:'17'}
)
).rejects.toMatchObject({code:'ENOENT'});
});
});
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.