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

Provide Groovy workflow build step

    XMLWordPrintable

Details

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

    Description

      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

      Attachments

        Issue Links

          Activity

            tg9541 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

            tg9541 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
            jglick 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.

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

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

            docwhat 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 added a comment -

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

            jglick Jesse Glick added a comment - JENKINS-37011 should make this much easier to implement; needs to be prototyped.
            jglick 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.

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

            PR 22 now offers a withGroovy step.

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

            Link to PR22 which still needs a review.

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: