[JENKINS-51823] Upgrade Groovy from 2.5.x to 3.0.x

[timja]

Jenkins core currently depends on Groovy 2.4.21 (released on November 29, 2020), which is out of date. Once we upgrade to 2.5.x, the next major version of Groovy is 3.0.x. At the time of this writing, the latest version of Groovy 3.0.x is 3.0.11 (released on May 28, 2022). Groovy 3.0 is required to run on Java 11+ without reflective access warnings logged on startup.

As described in jenkinsci/jenkins#5112 (comment) and jenkinsci/jenkins#5116 (comment), the main concern when upgrading Groovy is ensuring that sandboxed script execution remains secure.

---

Originally reported by oleg_nenashev, imported from: Upgrade Groovy from 2.5.x to 3.0.x

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

alexanderstohr:

is it possible? yes/no
i have varying indications, e.g. this one tells about 2.5.x was used: https://issues.jenkins.io/browse/JENKINS-53372?focusedCommentId=370924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-370924

[timja]

ianw:

oleg_nenashev, OP says groovy 3.x required to tun on Java 10.

The the discussion is to move core baseline to Java 11, does that not also require a move to Groovy 3.x?

[timja]

oleg_nenashev:

ianw yes, it may require a move to Groovy 3.x. Note that we do not have a consensus about moving to Java 11+ at the moment. We will be updating the Docker images to use Java 11 by default, and then we will see what is the feedback

[timja]

ianw:

As long as the Jenkins team keep this in mind when making any decision for 8 -> 11. Would the to see that go ahead and then all sorts of things go South, worse than tables to divs, based on the level of effort and potential blast radius if Groovy u/g was overlooked, especially since as it stand now, 8's availability will exceed 11's .

[timja]

timja:

I did a spike on this awhile back

Updating the version itself does work work in Jenkins, basic smoke testing produced no issues.

But there's a lot more work needed to be done to validate it,

See some comments on the work required:
https://github.com/jenkinsci/jenkins/pull/5112#issuecomment-744429487
https://github.com/jenkinsci/jenkins/pull/3605#issuecomment-465557917

[timja]

jglick:

One approach might be to redesign the sandbox compiler transformer (and perhaps also the CPS transformer, since they are somewhat interlinked) so that it defaults to rejecting unrecognized language constructs. I am not sure offhand if this is technically feasible, but it would certainly make updates much safer than they are today. This is by no means a complete solution, since Groovy updates also change behavior beyond the syntactic level in ways that can open up sandbox escapes in complex ways.

[timja]

[Originally duplicated by: JENKINS-63444]

[timja]

[Originally depends on: JENKINS-53372]

[timja]

[Epic: JENKINS-68689]