You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add force-download option for reproducible builds #979
Justification:
Currently, GitHub runner images use apt-get install temurin-${version}-jdk to pre-install Java. Adoptium's Debian packages include a dependency on adoptium-ca-certificates (or integrate with
ca-certificates-java). The cacerts file gets symlinked to /etc/ssl/certs/adoptium/cacerts, which is a shared keystore that integrates with the system's certificate store via update-ca-certificates.
This means the version of cacerts in the tool-cache is system dependent. When using a tool like jlink/jpackage, the cacerts gets bundled into the custom Java runtime image, making the build non-reproducible.
Forcing this action to perform a fresh download means that Java is simply extracted from the relevant .zip or tar.gz without modification of the cacerts file, resolving the issue.
Workaround
The workaround for now is to delete any Java installations in the tool-cache before running setup-java:
It deletes the cached JDK in the runner, including the cacerts it contains. setup-java then installs a fresh JDK (without any interference from the system certificates).
Yes, I did. With check-latest: true, setup-java queries the remote manifest for the newest version satisfying the spec instead of accepting whatever is in the tool cache - but it then checks whether that resolved version already exists in the cache, and if it does, it uses the cached copy anyway.
Activity
v-gowridurgad commentedon Feb 9, 2026
Hello @craigraw👋,
Thank you for reporting this feature request. We will investigate it and get back to you as soon as we have some feedback.
brunoborges commentedon Jul 14, 2026
@craigraw how is the workaround helping with the ca-certs?
craigraw commentedon Jul 15, 2026
@brunoborges Can you be more specific? The workaround ensures a consistent cacerts file.
brunoborges commentedon Jul 15, 2026
The workaround deletes the JDK but not the CA certs?
craigraw commentedon Jul 15, 2026
It deletes the cached JDK in the runner, including the cacerts it contains. setup-java then installs a fresh JDK (without any interference from the system certificates).
brunoborges commentedon Jul 15, 2026
@craigraw have you tested with
check-latest: true?craigraw commentedon Jul 16, 2026
Yes, I did. With
check-latest: true, setup-java queries the remote manifest for the newest version satisfying the spec instead of accepting whatever is in the tool cache - but it then checks whether that resolved version already exists in the cache, and if it does, it uses the cached copy anyway.