Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Component/s: pipeline
    • Labels:
      None
    • Environment:
      Jenkins: 1.625.3
      Workflow plugin: 1.11
    • Similar Issues:

      Description

      It should be possible to import shared Groovy code from the SCM source in a Workflow job. For instance, if my workflow script (flow.groovy) needs to access variables from another script (constants.groovy) and they are both in the SCM repo that the Workflow job checked out, it should be simple to do. It's not and currently the unabashedly terrible workaround is to do this:

      def constants
      
      stage('Import dependencies')
      node{  
        git(url: 'ssh://git@mygitserver.com:7999/ex/workflow.git', credentialsId: '60cda0cc-f13d-448c-9947-28b926a20628')
        constants = load('constants.groovy')
      }
      

      This works, but the fact that another node has to be spun up and another git checkout command is required is awful. It should be pretty straightfoward to have Jenkins simply load one of these files. Something like this:

      constants = import("constants.groovy")
      

      I'm pretty sure Groovy won't let you use "import" since it's a resered keyword, but I don't have any particularly strong feelings about the semantics of this command. I just want a way to load these files easily.

        Attachments

          Issue Links

            Activity

            Hide
            monitorjbl Taylor Jones added a comment -

            Any update on this? The current import method is still craaaazy annoying.

            Show
            monitorjbl Taylor Jones added a comment - Any update on this? The current import method is still craaaazy annoying.
            Hide
            waynr Wayne Warren added a comment -

            I should probably just RTFM, but is there a way to mark a particular stage as a flyweight task? It seems like the example shown in the description on this ticket could be done without consuming a full executor slot.

            Show
            waynr Wayne Warren added a comment - I should probably just RTFM, but is there a way to mark a particular stage as a flyweight task? It seems like the example shown in the description on this ticket could be done without consuming a full executor slot.
            Hide
            jglick Jesse Glick added a comment -

            It seems like the example shown in the description on this ticket could be done without consuming a full executor slot.

            No, you cannot.

            Possibly subsumed by JENKINS-31155, TBD.

            Show
            jglick Jesse Glick added a comment - It seems like the example shown in the description on this ticket could be done without consuming a full executor slot. No, you cannot. Possibly subsumed by JENKINS-31155 , TBD.
            Hide
            jglick Jesse Glick added a comment -

            If you are using either a multibranch project with Jenkinsfile, or Pipeline script from SCM, you can already do this:

            def constants = evaluate readTrusted('constants.groovy')
            

            For other cases, including accessing class definitions (rather than load/evaluate which can only load a Groovy file without an enclosing namespace), I think JENKINS-31155 would work. A typical scenario as I understand it is that there is one repository which contains a set of common libraries, as well as multiple top-level scripts loaded from a set of jobs. In such a case you could use whatever mechanism is defined JENKINS-31155 for making this repository accessible to the jobs; each job could then have a trivial inline script such as (exact syntax TBD):

            @Library('stuff') // optionally specify @master, @1.3, etc.
            import stuff.ThisJob
            ThisJob()
            

            where stuff/ThisJob.groovy might look something like

            package stuff
            import stuff.libs.Constants
            node {
              sh "make ${Constants.TARGET}"
            }
            

            assuming there were a stuff/libs/Constants.groovy

            package stuff.libs
            class Constants {
              static TARGET = 'world'
            }
            
            Show
            jglick Jesse Glick added a comment - If you are using either a multibranch project with Jenkinsfile , or Pipeline script from SCM , you can already do this: def constants = evaluate readTrusted( 'constants.groovy' ) For other cases, including accessing class definitions (rather than load / evaluate which can only load a Groovy file without an enclosing namespace), I think JENKINS-31155 would work. A typical scenario as I understand it is that there is one repository which contains a set of common libraries, as well as multiple top-level scripts loaded from a set of jobs. In such a case you could use whatever mechanism is defined JENKINS-31155 for making this repository accessible to the jobs; each job could then have a trivial inline script such as (exact syntax TBD): @Library( 'stuff' ) // optionally specify @master, @1.3, etc. import stuff.ThisJob ThisJob() where stuff/ThisJob.groovy might look something like package stuff import stuff.libs.Constants node { sh "make ${Constants.TARGET}" } assuming there were a stuff/libs/Constants.groovy package stuff.libs class Constants { static TARGET = 'world' }
            Hide
            jglick Jesse Glick added a comment -

            Confirmed that the more complex case can be handled using JENKINS-31155. For simple cases, use evaluate readTrusted(…).

            Show
            jglick Jesse Glick added a comment - Confirmed that the more complex case can be handled using JENKINS-31155 . For simple cases, use evaluate readTrusted(…) .

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                monitorjbl Taylor Jones
              • Votes:
                6 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: