Discussion: Should we cherry-pick cacert updates before branching?

[adamfarley]

Should we cherry pick cacerts updates that occur in the master branch between the branching for the dry-run and the final GA builds?
OpenJ9 noticed an issue where there ones were different from ours because they are not currently basing things from our release branches.
References:

• Slack thread: https://adoptium.slack.com/archives/C09NW3L2J/p1738169329374839
• OpenJ9 issue with investigation/details: jdk_security3_0 FAILED sun/security/ssl/X509TrustManagerImpl/Entrust/Distrust.java ValidatorException: No trusted certificate eclipse-openj9/openj9#21027
• PR which did the update in temurin-build/master: Update CA Certs #4105

Originally posted by @sxa in #64

[sxa]

My 2¢ on the subject - it would be preferable to use the closest to the GA to be as up to date as is practical at the time we ship (since we would typically not refresh a release just for a cacerts update so I would rather cherry pick.
The docs should be updated if we start doing this to indicate that the cherry pick should be done on the day before release (or maybe on the Tuesday and ideally run one build job though to ensure the new file doesn't cause any failures.

[tellison]

I agree with @sxa's position described above. Pick up the cacerts during the release process if ti has changed - although likely a bit longer than 'a day before' to avoid surprises.

[sxa]

Discussed on today's community call. We will aim to implement this (and I'll handle the doc updates) and also look at identifying the subset of tests that will utilise the cacerts bundle so we can have a process as follows:

1. Check whether there has been a cacerts update in master since the branch of temurin-build was created (e.g. https://github.com/adoptium/temurin-build/pulls?q=is%3Apr%22update+ca+certs%22+)
2. If so, cherry pick the commit across to the release branch
3. Run at least one build pipeline with the change (A quick one, such as Linux/aarch64 at present would make sense) including the smoke tests and either:

• A suitable set of tests enabled (sanity.openjdk and extended.openjdk)
• A separate Grinder job run with the specific test buckets that will exercise the functionality (Details and re-run link will be provided later in this comment once identified)

If the 3(ii) route is chosen it is likely that this can be done within about an hour on at least one platform, so I feel it would be ok to do this on the Monday the day before the GA tags become available, which will still leave leaving most of Tuesday for any additional remedial action if needed.