Backport of ClassCastException fix for JDK 11u16
#1381
Conversation
|
Nice! Great example of BOM/PCT testing catching real issues for the benefit of Jenkins users. |
|
FYI the same logic is present in jenkinsci/script-security-plugin#420 which only seems to have made it out as far back as 2.332.1, so we may want to consider a backport of that as well for completeness. |
Could do that too. In that case the fix is to |
I'm not sure if I understood everything, but I can confirm that the infra was upgraded earlier this week to use the latest 11u16 JDK:
Did this JDK upgrade broke things (additionnaly to the trilead thing)? |
Well, yes, it broke builds of this repository, which this PR corrects by picking up a change to production code that fixes a bug affecting u16 which I just backported to an older LTS line. So a good thing except to the extent that the failures were unexpected (interrupted progress on other things) and took me a while to track down since they were not associated with some versioned change. |
First of all, really sorry for this unexpected change and the wasted time. With the holidays rotation, we (infra-team) failed our hand overs and our communications. Thanks for the clarification. It's the 2nd time this year that the we (the infra team) are breaking builds like this by updating really early. @basil already mentionned this with the Maven 3.8.5 update. I propose the following 2 improvements on the future, the goal is to limit the waste of time WDYT of them?
|
seems overkill to me
+1, but don't go too overboard on every update, people can always subscribe to releases of https://github.com/jenkins-infra/packer-images/releases/tag/0.37.0 |
That would be helpful and sounds simple enough.
Yes but doing it right requires some forethought. There would need to be a way to specify a particular tool set version in project sources, with some assurances that this image or whatever will be available indefinitely (so you can go back and play with branches). And there needs to be a system, like Dependabot or updatecli, for automatically proposing updates in a timely PR flow. In this case such a system would have offered an update from u15 to u16, which would have gotten a failing check which we would immediately suspect was caused by the Java update, unrelated PRs could go through CD, and the fix of the test failures (in this case a plugin backport) would go into that automated PR or something filed by hand to subsume it. The cost is of course a higher volume of PRs, most of which are uninteresting. I have proposed something like this for |
Never found the time, but FTR if anyone (perhaps my future self) wishes to clean up: jenkinsci/script-security-plugin#161 (comment) |
In https://github.com/jenkinsci/workflow-cps-plugin/releases/tag/2660.2664.v4c114e93f4c1 I backported jenkinsci/workflow-cps-plugin#543 which (among other things) solves an error reproducible when using JDK 11u16 but not 11u15:
I guess CI agents recently updated Java versions @dduportal? Blocking an important #1379 (comment) and also seen in #1380 (https://github.com/jenkinsci/bom/pull/1380/checks?check_run_id=7686555358). Originally released in https://github.com/jenkinsci/workflow-cps-plugin/releases/tag/2705.v0449852ee36f but jenkinsci/workflow-cps-plugin#512 restricted that to a newer line so #940 did not pick this up on 2.319.x.