Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26635

Provide Groovy workflow build step

XMLWordPrintable

    • 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

          Nigel Harniman created issue -
          Nigel Harniman made changes -
          Description Original: Provide a built in step in its own intepreter 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           		New: 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
          Summary Original: Provide Groovy workflow step New: 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 made changes -
          Link New: This issue depends on JENKINS-26055 [ JENKINS-26055 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-26192 [ JENKINS-26192 ]

          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.

          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 ).

          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 ).
          Patrick Wolf made changes -
          Epic Link New: JENKINS-34657 [ 170293 ]
          Jesse Glick made changes -
          Epic Link Original: JENKINS-34657 [ 170293 ] New: JENKINS-35390 [ 171183 ]

          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.

          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.

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

              Created:
              Updated:
              Resolved: