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

Allow plugins to contribute to Pipeline global library

    Details

    • Similar Issues:

      Description

      I'd like to be able to write a plugin that provides an opinionated DSL for Pipeline, behaving like it had been added to the global library, i.e., something like https://github.com/jenkinsci/workflow-examples/tree/master/global-library-examples/global-function but more so. I like the idea of delivering it via a plugin so that it can be tested, versioned, released, etc like any other plugin, but I don't see any way to do this currently. I'd imagine the logical way to do this would be to add the capacity to do this to Pipeline proper, but I could be wrong.

        Attachments

          Issue Links

            Activity

            abayer Andrew Bayer created issue -
            Hide
            michaelneale Michael Neale added a comment -

            The only real problem I can forsee is that the names of DSL files in the global lib are, well, global.

            eg:

            builg.groovy is used as

            build

            { .. }

            In the script. If you install 2 plugins that each want to have a build.groovy - how is the conflict resolved? will the second one they install fail?
            (I fear to suggest qualified imports.... as that kind of harshes the vibe, but some way to resolve this may be warranted).

            Show
            michaelneale Michael Neale added a comment - The only real problem I can forsee is that the names of DSL files in the global lib are, well, global. eg: builg.groovy is used as build { .. } In the script. If you install 2 plugins that each want to have a build.groovy - how is the conflict resolved? will the second one they install fail? (I fear to suggest qualified imports.... as that kind of harshes the vibe, but some way to resolve this may be warranted).
            Hide
            abayer Andrew Bayer added a comment -

            Good point. I'd probably lean towards qualified imports - we've already got a de facto requirement for uniqueness on plugin IDs, package/class names, etc, so there should be something we can reuse from that, first instinct being plugin IDs, so something like plugin "pipeline-my-dsl" providing the equivalent of "src/build.groovy" in the global library would be used as:

            pipeline-my-dsl.build { ... }
            

            Less elegant, but also safer, obviously. =)

            Show
            abayer Andrew Bayer added a comment - Good point. I'd probably lean towards qualified imports - we've already got a de facto requirement for uniqueness on plugin IDs, package/class names, etc, so there should be something we can reuse from that, first instinct being plugin IDs, so something like plugin "pipeline-my-dsl" providing the equivalent of "src/build.groovy" in the global library would be used as: pipeline-my-dsl.build { ... } Less elegant, but also safer, obviously. =)
            Hide
            jglick Jesse Glick added a comment -

            Currently this is your option. Likely we will need a stronger API to support inclusion in DSLD/GDSL in the future.

            Show
            jglick Jesse Glick added a comment - Currently this is your option. Likely we will need a stronger API to support inclusion in DSLD/GDSL in the future.
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Labels api groovy
            Hide
            jglick Jesse Glick added a comment -
            Show
            jglick Jesse Glick added a comment - Close try
            Hide
            michaelneale Michael Neale added a comment -

            Based on what I have seen, I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension. Some intelligence needs to be applied around naming and state, but overall, it works just fine (or can be sugared up). There is no need for plugins to "commit" to the workflowLibs repo - I think that would be not right.

            So I vote we close this in favour of an example/wiki page as "done".

            Show
            michaelneale Michael Neale added a comment - Based on what I have seen, I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension. Some intelligence needs to be applied around naming and state, but overall, it works just fine (or can be sugared up). There is no need for plugins to "commit" to the workflowLibs repo - I think that would be not right. So I vote we close this in favour of an example/wiki page as "done".
            Hide
            jglick Jesse Glick added a comment -

            I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension

            …but we still need an API to allow DSLD/GDSL generators to know that a given variable has a type given by a specific Groovy resource, so they could have a chance at offering strong typing. For example, if docker-workflow is installed, you would ideally like IDEA to be able to complete docker.image('maven').ins to inside.

            Show
            jglick Jesse Glick added a comment - I think there is sufficient ability for plugins to add to a global library already - by providing a GlobalVariable extension …but we still need an API to allow DSLD/GDSL generators to know that a given variable has a type given by a specific Groovy resource, so they could have a chance at offering strong typing. For example, if docker-workflow is installed, you would ideally like IDEA to be able to complete docker.image('maven').ins to inside .
            Hide
            abayer Andrew Bayer added a comment -

            +1 - I wonder if we might want to end up doing something with annotations here...

            Show
            abayer Andrew Bayer added a comment - +1 - I wonder if we might want to end up doing something with annotations here...
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-35395 [ JENKINS-35395 ]
            Hide
            jglick Jesse Glick added a comment -

            Prefer to avoid annotations unless there is something that cannot be done without them.

            GroovyFileGlobalVariable is a prototype but does not suffice for code completion.

            Show
            jglick Jesse Glick added a comment - Prefer to avoid annotations unless there is something that cannot be done without them. GroovyFileGlobalVariable is a prototype but does not suffice for code completion.
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-26126 [ JENKINS-26126 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 168395 ] JNJira + In-Review [ 183107 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-37011 [ JENKINS-37011 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            jglick Jesse Glick made changes -
            Component/s workflow-cps-plugin [ 21713 ]
            Component/s pipeline [ 21692 ]
            Hide
            jglick Jesse Glick added a comment - - edited

            Also need to allow the library code to be loaded in trusted mode, which the GlobalVariable API does not currently make straightforward. That would simplify some things; for example DockerDSL.MiscWhitelist could be deleted, and @Whitelisted removed from ImageNameTokens.

            Show
            jglick Jesse Glick added a comment - - edited Also need to allow the library code to be loaded in trusted mode, which the GlobalVariable API does not currently make straightforward. That would simplify some things; for example DockerDSL.MiscWhitelist could be deleted, and @Whitelisted removed from ImageNameTokens .
            jglick Jesse Glick made changes -
            Link This issue depends on JENKINS-34650 [ JENKINS-34650 ]
            Hide
            jglick Jesse Glick added a comment -

            allow the library code to be loaded in trusted mode

            Turns out this already works, as of JENKINS-34650.

            Show
            jglick Jesse Glick added a comment - allow the library code to be loaded in trusted mode Turns out this already works, as of JENKINS-34650 .
            jglick Jesse Glick made changes -
            Remote Link This issue links to "docker-workflow PR 75 (Web Link)" [ 14956 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            pom.xml
            src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java
            src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java
            http://jenkins-ci.org/commit/docker-workflow-plugin/abe4066b6b4eb1af3e922897add192df4e0294ef
            Log:
            JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java http://jenkins-ci.org/commit/docker-workflow-plugin/abe4066b6b4eb1af3e922897add192df4e0294ef Log: JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            pom.xml
            src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java
            src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java
            src/main/resources/org/jenkinsci/plugins/docker/workflow/Docker.groovy
            http://jenkins-ci.org/commit/docker-workflow-plugin/223612bc8378cc3e02cc6fecee1416c5bd533af9
            Log:
            Merge pull request #75 from jglick/GlobalVariable-JENKINS-32731

            JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted

            Compare: https://github.com/jenkinsci/docker-workflow-plugin/compare/1f5f9d0147c4...223612bc8378

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml src/main/java/org/jenkinsci/plugins/docker/workflow/DockerDSL.java src/main/java/org/jenkinsci/plugins/docker/workflow/ImageNameTokens.java src/main/resources/org/jenkinsci/plugins/docker/workflow/Docker.groovy http://jenkins-ci.org/commit/docker-workflow-plugin/223612bc8378cc3e02cc6fecee1416c5bd533af9 Log: Merge pull request #75 from jglick/GlobalVariable- JENKINS-32731 JENKINS-32731 JENKINS-34650 Docker.groovy is already trusted Compare: https://github.com/jenkinsci/docker-workflow-plugin/compare/1f5f9d0147c4...223612bc8378
            Hide
            abayer Andrew Bayer added a comment -

            The current situation is sufficient, so I'm closing this.

            Show
            abayer Andrew Bayer added a comment - The current situation is sufficient, so I'm closing this.
            abayer Andrew Bayer made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Won't Fix [ 2 ]

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                abayer Andrew Bayer
              • Votes:
                3 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: