• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • groovy-plugin
    • Jenkins 1.580.2.1
      Workflow (all) 1.1
    • 2.4

      Provide a built in step in its own interpreter for running Groovy code to separate it out from the workflow DSL.

      Although its possible ti run a groovy script from within the sh task having a native capability would be better.

      NB this is blocked by https://issues.jenkins-ci.org/browse/JENKINS-26055

          [JENKINS-26635] Provide Groovy workflow build step

          Thomas Goeppel added a comment - - edited

          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

          Thomas Goeppel added a comment - - edited 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

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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 ).

          Thomas Goeppel added a comment - 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.

          Christian Höltje added a comment - 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.

          Jesse Glick added a comment -

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

          Jesse Glick added a comment - JENKINS-37011 should make this much easier to implement; needs to be prototyped.

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.

          Jesse Glick added a comment -

          PR 22 now offers a withGroovy step.

          Jesse Glick added a comment - PR 22 now offers a withGroovy step.

          Link to PR22 which still needs a review.

          Christian Höltje added a comment - Link to PR22 which still needs a review.

            jglick Jesse Glick
            nharniman Nigel Harniman
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: