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

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

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Environment:
    • Similar Issues:

      Description

      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.

       

        Attachments

          Issue Links

            Activity

            Hide
            abayer 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.

            Show
            abayer 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.
            Hide
            kroutley Kurt Routley added a comment - - edited

            Thanks for the information Andrew Bayer . 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.

            Show
            kroutley Kurt Routley added a comment - - edited Thanks for the information Andrew Bayer . 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.
            Hide
            kroutley Kurt Routley added a comment -

            Andrew Bayer 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

            Show
            kroutley Kurt Routley added a comment - Andrew Bayer  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
            Hide
            bparker 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.

            Show
            bparker 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.
            Hide
            abayer Andrew Bayer added a comment -

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

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

              People

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

                Dates

                • Created:
                  Updated: