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