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

${env.GLOBALSETTINGSNAME} invalid out of node context

      Configuring a global variable via
      Manage Jenkins->Configure System->[Global properties]Name=TEST, Value=test

      and trying to use it inside a pipeline script like that:

      echo( "[ ${env.TEST} ]")
      stage("test") {
      echo( "[ ${env.TEST}} ]")
          node("master") {
      echo( "[ ${env.TEST}} ]")
      ...
      

      Will output:

      [Pipeline] echo
      [ null ]
      [Pipeline] stage
      [Pipeline] { (test)
      [Pipeline] echo
      [ null ]
      [Pipeline] node
      Running on master in /var/lib/jenkins/workspace/test
      [Pipeline] {
      [Pipeline] echo
      [ test ]
      

      The expectation would be that its either available in the global context too or error out to fail visually.

      Since one may want to use Global properties to build parameters for sub-build jobs having to wrap them in a node(){} will waste worker resources, right? Thus I would like to get global properties to become available outside of nodes too.

          [JENKINS-40070] ${env.GLOBALSETTINGSNAME} invalid out of node context

          Jesse Glick added a comment -

          Environment variables are only bound insofar as there is an EnvironmentContributor for them, and/or a Computer defining them. Computer.buildEnvironment does consult Jenkins.getGlobalNodeProperties. Currently WorkflowRun.getEnvironment does not, nor does WorkflowJob.getEnvironment. Arguably this is a core bug insofar as you might expect Job.getEnvironment to call it, or for there to be an EnvironmentContributor which does so; TBD whether that should be solved in core, or if workflow-job should work around it.

          Jesse Glick added a comment - Environment variables are only bound insofar as there is an EnvironmentContributor for them, and/or a Computer defining them. Computer.buildEnvironment does consult Jenkins.getGlobalNodeProperties . Currently WorkflowRun.getEnvironment does not, nor does WorkflowJob.getEnvironment . Arguably this is a core bug insofar as you might expect Job.getEnvironment to call it, or for there to be an EnvironmentContributor which does so; TBD whether that should be solved in core, or if workflow-job should work around it.

            Unassigned Unassigned
            dothebart Wilfried Goesgens
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: