Getting data in, and out of such a Groovy build step should be as easy, and unobstrisive as possible:

• data in -> e.g. env,
• data out -> e.g. map like in Workflow Input step
• adding jars to the class path should be simple -> e.g. cp relative to workspace in Groovy tool configuration

"data out" is maybe the same as JENKINS-26133

Needs to allow selection of JRE and Groovy installation, but with a fallback to the JRE of the slave agent and the Groovy library used by Workflow itself, so that there is no special prerequisite on the slave for typical cases. Along with other command-line options, classpath customization needs to be allowed though in most cases (public libraries) you can just use @Grab.

Could even allow passing Serializable objects as input and output with the help of a wrapper script, though I see no straightforward way to share instances of classes defined in the script itself. Still might be useful even if limited to built-in types like Map and Collection plus String and primitives.

In March I didn't know about '@NonCPS import', and in the meantime I've found work-arrounds using standard Groovy libraries and @NonCPS Groovy functions, and serializable CPS built-in types. On executor nodes I now run Groovy wrapped in Gradle tasks. I've removed my vote for the ER, but a Workflow compatible Gradle build step would still be nice ( -> JENKINS-27393 ).

This would still be nice to have for system groovy scripts, assuming the script approval stuff would still work.

It would be handy for maintenance jobs.

JENKINS-37011 should make this much easier to implement; needs to be prototyped.

nice to have for system groovy scripts

All Pipeline script is essentially “system Groovy” already: you can access Jenkins internal types, subject to script security.

PR 22 now offers a withGroovy step.

Link to PR22 which still needs a review.