* 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
* 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
* 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 <[email protected]>
* Apply batched suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
* Fix JDK cache CI validation
Co-authored-by: Copilot App <[email protected]>
* Update brace-expansion security fix
Co-authored-by: Copilot App <[email protected]>
* Refresh brace-expansion license metadata
Co-authored-by: Copilot App <[email protected]>
* Refine JDK cache semantics
Co-authored-by: Copilot App <[email protected]>
* Refine JDK cache documentation
Co-authored-by: Copilot App <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* docs: add V6 what's new entry for JDK caching
Co-authored-by: Copilot App <[email protected]>
Copilot-Session: e2755464-4e83-47b6-ba71-731bb481b418
---------
Co-authored-by: Copilot App <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
Copilot-Session: e2755464-4e83-47b6-ba71-731bb481b418
* Migrate to ESM and upgrade dependencies
* fix: update import statement for JSON module in kona-installer test
---------
Co-authored-by: George Adams <[email protected]>
* 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 <[email protected]>
* Update src/cache.ts
Co-authored-by: Konrad Pabjan <[email protected]>
* 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 <[email protected]>
Co-authored-by: Konrad Pabjan <[email protected]>
