* 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 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
- 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
* 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>
* 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>
* 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>
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>
* 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>
* 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>
* 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>
- 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>
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>
* 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>
Bruno Borges