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

Provide a way to write full-fledged Steps in CPS-transformed Groovy

    • Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: Critical Critical
    • workflow-cps-plugin
    • None

      A number of things are much easier to write in CPS-transformed Groovy than in Java, but we'd still like to be able to expose that code as an actual Step, not just as a GlobalVariable, so that we can eventually get Snippet Generator support, introspection, etc. So let's have a way to do that. =)

          [JENKINS-37011] Provide a way to write full-fledged Steps in CPS-transformed Groovy

          master PR that in turn depends on other pending PRs.

          Kohsuke Kawaguchi added a comment - master PR that in turn depends on other pending PRs.

          Jesse Glick added a comment -

          There seems to be overlap with JENKINS-32731. One of the problems with docker-workflow is that there is no Snippet Generator support beyond a docker global variable beneath which we can put a blob of HTML. Does this change help with that at all, or did we screw up by putting this functionality under the namespace of a global variable rather than doing it all as top-level functions?

          Jesse Glick added a comment - There seems to be overlap with JENKINS-32731 . One of the problems with docker-workflow is that there is no Snippet Generator support beyond a docker global variable beneath which we can put a blob of HTML. Does this change help with that at all, or did we screw up by putting this functionality under the namespace of a global variable rather than doing it all as top-level functions?

          Jesse Glick added a comment -

          Since docker-workflow already defines steps like withDockerRegistry etc., perhaps we would not be losing much by just removing the isAdvanced override and encouraging people to use them directly in place of Docker.groovy. Other than the magic fingerprinting, it does not give you much that you would not get from running these steps plus sh 'docker …' directly. inside could be implemented as a step in Groovy so that the initial conditional docker pull can be durable. withRun could still be offered as a convenience using a step in Groovy like dockerWithRun; the loss of a fluid syntax is IMO compensated by the much better Snippetizer support.

          Jesse Glick added a comment - Since docker-workflow already defines steps like withDockerRegistry etc., perhaps we would not be losing much by just removing the isAdvanced override and encouraging people to use them directly in place of Docker.groovy . Other than the magic fingerprinting, it does not give you much that you would not get from running these steps plus sh 'docker …' directly. inside could be implemented as a step in Groovy so that the initial conditional docker pull can be durable. withRun could still be offered as a convenience using a step in Groovy like dockerWithRun ; the loss of a fluid syntax is IMO compensated by the much better Snippetizer support.

          Jesse Glick added a comment -

          This work has been stopped.

          Jesse Glick added a comment - This work has been stopped.

            kohsuke Kohsuke Kawaguchi
            abayer Andrew Bayer
            Votes:
            6 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: