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

Environment and Options blocks do not take effect from within groovy shared variable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major

      We create a Declarative Pipeline script from within a groovy shared variable. The problem is the environment block and options block (specifically the disableConcurrentBuilds option) do not take effect from inside the groovy shared variable.

      Top-level jenkinsfile:

       

      #!groovy
      @Library("OurGroovyLibrary") _
      
      ourGroovySharedFunction([Arg: "SomeValue"])

       

      Groovy shared variable (ourGroovySharedFunction.groovy) :

       

      #!groovy
      
      def call(Map templateParams) {
        pipeline {
          agent {
            node {
              label 'ImportantLabel'
            }
          }
          environment {
            ImportantPath = 'C:/Some/Important/Path'
          }
          options {
            disableConcurrentBuilds() //BUG: This does not take effect, build still runs concurrently on slaves with more than 1 executor
          }
          stages {
            stage('Checking environment') {
              steps {
                echo "${env.getEnvironment()}" //BUG: ImportantPath is not present in env
              }
            }
          }
        }
      }

      Verified that the expected behavior occurs correctly when the declarative pipeline script is in the Jenkinsfile, but would prefer to have it in the groovy shared variable for scalability reasons.

       

          [JENKINS-46476] Environment and Options blocks do not take effect from within groovy shared variable

          Andrew Bayer added a comment -

          We don't support Declarative Pipelines being defined anywhere but in the Jenkinsfile itself - it may work, but there's no guarantee. It's something we're not ruling out for the future, though, so I'll leave this open.

          Andrew Bayer added a comment - We don't support Declarative Pipelines being defined anywhere but in the Jenkinsfile itself - it may work, but there's no guarantee. It's something we're not ruling out for the future, though, so I'll leave this open.

          Kurt Routley added a comment - - edited

          Thanks for the information abayer . We like the idea of having our Declarative Pipelines generated in the groovy shared variable, as it allows us to have re-usable pipelines, and then we can treat our Jenkinsfiles more like properties of each project that uses the shared Declarative Pipeline. Is there any recommended practice or pattern for re-usable Declarative Pipeline scripts?

          Should also mention our current workarounds for the issues:
          For the environment, we just and env.<variable_name> = <variable_value> in the node block to update the env map.
          For the concurrent builds issue, we have reduced our slaves to single executors.

          Kurt Routley added a comment - - edited Thanks for the information abayer . We like the idea of having our Declarative Pipelines generated in the groovy shared variable, as it allows us to have re-usable pipelines, and then we can treat our Jenkinsfiles more like properties of each project that uses the shared Declarative Pipeline. Is there any recommended practice or pattern for re-usable Declarative Pipeline scripts? Should also mention our current workarounds for the issues: For the environment, we just and env.<variable_name> = <variable_value> in the node block to update the env map. For the concurrent builds issue, we have reduced our slaves to single executors.

          Kurt Routley added a comment -

          abayer FYI we managed to get around the re-usable Pipeline issue by switching to Scripted Pipeline, and then we use static classes in the groovy shared library to generate a closure of a Pipeline script

          Kurt Routley added a comment - abayer  FYI we managed to get around the re-usable Pipeline issue by switching to Scripted Pipeline, and then we use static classes in the groovy shared library to generate a closure of a Pipeline script

          Since this is actually supported in Jenkins, this is a serious issue that should be addressed.

          https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines

          So I'd really like to see some movement on getting this solved.

          Brandon Parker added a comment - Since this is actually supported in Jenkins, this is a serious issue that should be addressed. https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines So I'd really like to see some movement on getting this solved.

          Andrew Bayer added a comment -

          Have you reproduced this with Declarative 1.2.x or later?

          Andrew Bayer added a comment - Have you reproduced this with Declarative 1.2.x or later?

            Unassigned Unassigned
            kroutley Kurt Routley
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: