* feat: support Maven server credential origins
* Refactor origin construction to include port if necessary
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* fix: validate Maven server credential origins
* docs: note mvn-server-repository-origins requires Maven 3.10+
Co-authored-by: Copilot App <[email protected]>
---------
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot App <[email protected]>
Accept 4-part versions with build metadata (X.Y.Z.P+B -> X.Y.Z+P.B) and
match exact Temurin requests against OpenJDK-derived version keys, since the
Adoptium API semver folds the patch into the build number (26.0.2+101) and
adds LTS metadata (25.0.4+7.0.LTS).
Co-authored-by: Copilot App <[email protected]>
Azul reports hotfix releases like 25.0.4.1 as java_version=[25,0,4,1]
with openjdk_build_number=1 (SDKMAN '25.0.4+1.1'). Sorting candidates via
semver.compareBuild ranked 25.0.4+7 above 25.0.4+1.1, so ranges such as
'25' resolved to the older build. Compare java_version, build number and
distro_version numerically instead.
Fixes: #1275
Co-authored-by: Copilot App <[email protected]>
* Initial plan
* Fix signature verification GPG homes on long runner paths
* Keep macOS GPG verification homes within socket limits
Use /tmp for signature verification on macOS while preserving runner temp behavior elsewhere. Cover long and canonical OS temp paths and regenerate action bundles.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 32d31c8d-ddbc-4e57-a5c3-f70588fef3f3
---------
Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 32d31c8d-ddbc-4e57-a5c3-f70588fef3f3
* Fix import-safe checks when scripts are run from a path with symlinks
In v6, setup-java was made "import-safe" to facilitate testing. This
prevents setup-java & cleanup-java from doing anything when their
sources get imported.
This works fine in the general case, but actually invoking the script
(`node setup-java/index.js`) when the path to the script contains
symlinks led to the script incorrectly believing it was imported, and
refuse to actually run.
To fix this, we pass `process.argv[1]` through `fs.realpathSync`, which
resolves symlinks in the path.
Fixes#1264
* Preserve import safety when resolving symlink entrypoints
Share entrypoint detection between setup and cleanup, handle non-file entrypoints safely, and normalize both paths for preserved symlinks. Add real-process regression coverage and rebuild action bundles.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 831c32f2-a275-45bd-a92b-c387372a1554
* Update js-yaml to fix merge-source denial of service
Bump the transitive development dependency from 3.15.1 to 3.15.2 to address GHSA-2883-xcg3-v3hh without changing dependency ranges or CI checks.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 831c32f2-a275-45bd-a92b-c387372a1554
---------
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 831c32f2-a275-45bd-a92b-c387372a1554
Update public examples and release messaging to make v6 the recommended stable version, include late-cycle v6 features, and increase the JetBrains test timeout to avoid cold-run flakes.
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: 24e3d384-3bda-4ca3-b1fc-f49e340c174f
* Add Red Hat Build of OpenJDK support
Co-authored-by: Copilot App <[email protected]>
* Fix Red Hat tests on Windows
Co-authored-by: Copilot <[email protected]>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* Update compiled Red Hat distribution
Co-authored-by: Copilot <[email protected]>
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* Updated microsoft openjdk setup-java action
* Update generated distribution
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* Applied new fixes from npm run check
* Update generated distribution
---------
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Bruno Borges <[email protected]>
* 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 <[email protected]>
* Update distribution bundle
Regenerate the setup bundle for SapMachine release-class filtering.\n\nCo-authored-by: Copilot App <[email protected]>
* Format SapMachine regression tests
Apply the repository Prettier format to the focused test additions.\n\nCo-authored-by: Copilot App <[email protected]>
---------
Co-authored-by: Bruno Borges <[email protected]>
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 <[email protected]>
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 <[email protected]>\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 <[email protected]>\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 <[email protected]>
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 <[email protected]>
Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db
---------
Co-authored-by: Bruno Borges <[email protected]>
Co-authored-by: Copilot App <[email protected]>
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 <[email protected]>
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: f2d9a891-a680-4b35-9644-cf2450f76f6d
* Fix floating Oracle JDK version resolution
Co-authored-by: Copilot App <[email protected]>
* Update generated distribution bundles
Co-authored-by: Copilot App <[email protected]>
* Harden floating artifact cache identity
Co-authored-by: Copilot App <[email protected]>
* Regenerate setup bundle after cache hardening
Co-authored-by: Copilot App <[email protected]>
* Temporarily enable hosted full validation
Co-authored-by: Copilot App <[email protected]>
* Export hosted formatting results
Co-authored-by: Copilot App <[email protected]>
* Apply repository formatting
Co-authored-by: Copilot App <[email protected]>
* Run hosted validation after formatting
Co-authored-by: Copilot App <[email protected]>
* Correct floating version regression tests
Co-authored-by: Copilot App <[email protected]>
* Remove temporary validation wiring
Co-authored-by: Copilot App <[email protected]>
* 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 <[email protected]>
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Bruno Borges <[email protected]>
* 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 <[email protected]>
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 <[email protected]>
Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* 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 <[email protected]>
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 <[email protected]>
Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
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 <[email protected]>
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 <[email protected]>
Copilot-Session: 664777db-7250-417d-b94d-d5529ec3fec2
