Repository navigation
Support optional custom cacerts input for installed JDK #1035
Description
Summary: Add an optional action input that allows providing a custom cacerts file to be used by the installed JDK.
Background: PR #284 proposed this capability, but the branch is now very old and heavily conflicted. The feature request can continue in a fresh implementation.
Proposed behavior:
- New optional input for path to a cacerts file
- If provided, configure the installed Java runtime to use that cacerts content
- Keep default behavior unchanged when input is not set
Scope:
- Re-implement on current main instead of reusing the old branch
- Add tests for enabled and default paths
- Document usage and caveats for hosted and self-hosted runners
Out of scope:
- Unrelated runtime or lockfile changes
Reference: PR #284
Activity
brunoborges commentedon Jun 23, 2026
Related (but distinct) to #640. For clarity: #1035 (this issue) is about the installed JDK's runtime
cacertstrust store; #640 is about the action's download-time TLS (verifying an internal CA while downloading the JDK on GH Enterprise). Different layers — cross-linking so they're tracked together but not merged.brunoborges commentedon Jun 23, 2026
Rather than adding a dedicated
cacertsaction input, this is solved cleanly with documentation, since the installed JDK exposes its own trust store at$JAVA_HOME/lib/security/cacertsandkeytoolcan import a custom CA aftersetup-javaruns.NODE_EXTRA_CA_CERTSso the JDK can be downloaded on GitHub Enterprise / behind a TLS-inspecting proxy.keytool -importcertstep into$JAVA_HOME/lib/security/cacerts, with hosted vs self-hosted persistence caveats.A built-in input would add config surface, tests, and maintenance for something a single documented step handles, so we'll go with docs. Closing as resolved-by-documentation; see #1051 for the exact guidance. If a first-class custom-cacerts input is still desired later, we can reopen with that specific scope.
docs: add post-install keytool import for the JDK cacerts trust store (…