* feat: expose cache-primary-key output (#597)
Backport of the cache-primary-key output to the v5 release line.
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 (CommonJS)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Apply PR #1088 review suggestions to v5 backport
Port the review feedback from the main-line PR (#1088) into the v5 backport:
- src/cache.ts: use the STATE_CACHE_PRIMARY_KEY constant for the output name
instead of a duplicated string literal
- action.yml / README.md: clarify that the output is also empty when caching
is skipped (e.g. the cache service is unavailable)
- dist: rebuild
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+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
(cherry picked from commit cf9e5e7084)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Regenerate the CommonJS bundle so the compiled dist/ reflects the
source changes backported from main, without the ESM migration (#1078).
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>
(cherry picked from commit 4db08ef6bf)
* 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>
(cherry picked from commit 7dbccc66ee)
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>
(cherry picked from commit 8a3e8157a1)
* 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>
* 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>
* 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>
* 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>
* 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>
