• Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Minor Minor
    • pipeline
    • None
    • Jenkins: 1.625.3
      Workflow plugin: 1.11

      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.

          [JENKINS-32400] Import shared Groovy code

          Taylor Jones added a comment -

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

          Taylor Jones added a comment - Any update on this? The current import method is still craaaazy annoying.

          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.

          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.

          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.

          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.

          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'
          }
          

          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' }

          Jesse Glick added a comment -

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

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

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

              Created:
              Updated:
              Resolved: