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

global variable not updated

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Update to global variable aren't applied to jobs when envinject plugin is installed

      how to reproduce :
      running fresh 1.494, with a single Job to echo $FOO
      FOO global variable set to "foo"

      build #1 :
      echo foo

      change FOO to set value = "bar"

      build #2 :
      echo bar

      Right, then install envinject (1.78), restart

      build #3 :
      echo bar

      change FOO to set value = "qix"

      build #2 :
      echo bar

      wtf ?

        Attachments

          Issue Links

            Activity

            ndeloof Nicolas De Loof created issue -
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Gregory Boissinot
            Path:
            src/main/java/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty.java
            src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectGlobalPasswordRetriever.java
            http://jenkins-ci.org/commit/envinject-plugin/95428b2fb1a750c2a1d3e7898f14c3d95b77e481
            Log:
            Fix JENKINS-16316

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty.java src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectGlobalPasswordRetriever.java http://jenkins-ci.org/commit/envinject-plugin/95428b2fb1a750c2a1d3e7898f14c3d95b77e481 Log: Fix JENKINS-16316
            ndeloof Nicolas De Loof made changes -
            Field Original Value New Value
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            ndeloof Nicolas De Loof added a comment -

            still failing

            Show
            ndeloof Nicolas De Loof added a comment - still failing
            ndeloof Nicolas De Loof made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            gbois Gregory Boissinot added a comment -

            Can't reproduce

            Show
            gbois Gregory Boissinot added a comment - Can't reproduce
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Gregory Boissinot
            Path:
            src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
            src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectEnvVars.java
            http://jenkins-ci.org/commit/envinject-plugin/9e27cf40040a15cf67c1fc64bab90d28f2bc43e4
            Log:
            Fix reopen JENKINS-16316


            You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
            For more options, visit https://groups.google.com/groups/opt_out.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectEnvVars.java http://jenkins-ci.org/commit/envinject-plugin/9e27cf40040a15cf67c1fc64bab90d28f2bc43e4 Log: Fix reopen JENKINS-16316 – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .
            gbois Gregory Boissinot made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            mcklaus Klaus Azesberger added a comment -

            I've encountered this to still be an issue in specific cases on slave node execution (maybe some of this behaviour is intended?):

            how to reproduce:

            • hpi:run on current head with jenkins-version set to "1.480.3" (current LTS verison)
            • configure a global property on master K/V: TESTVAR/value1
            • configure a slave and start it
            • configure a job restricted to run on that slave and to echo $TESTVAR.
            • run the job (it will echo "value1")
            • configure the global property on master to be: TESTVAR/value2
            • dont restart anything
            • rerun the job (it will still echo "value1")

            however a job on master will recognize the changed value.

            there are 2 pieces of code that lead to this behaviour. I'm pretty uncertain about the fix i made, but it resolves at least our problem with the plugin as i described it above, although i'm pretty sure it breaks some other intended feature.

            https://github.com/kazesberger/envinject-plugin.git
            https://github.com/kazesberger/envinject-plugin/commits/master

            maybe someone can have a look at it and/or tell me what's the story behind this (Core)EnvironmentContributor thing.

            Show
            mcklaus Klaus Azesberger added a comment - I've encountered this to still be an issue in specific cases on slave node execution (maybe some of this behaviour is intended?): how to reproduce: hpi:run on current head with jenkins-version set to "1.480.3" (current LTS verison) configure a global property on master K/V: TESTVAR/value1 configure a slave and start it configure a job restricted to run on that slave and to echo $TESTVAR. run the job (it will echo "value1") configure the global property on master to be: TESTVAR/value2 dont restart anything rerun the job (it will still echo "value1") however a job on master will recognize the changed value. there are 2 pieces of code that lead to this behaviour. I'm pretty uncertain about the fix i made, but it resolves at least our problem with the plugin as i described it above, although i'm pretty sure it breaks some other intended feature. https://github.com/kazesberger/envinject-plugin.git https://github.com/kazesberger/envinject-plugin/commits/master maybe someone can have a look at it and/or tell me what's the story behind this (Core)EnvironmentContributor thing.
            mcklaus Klaus Azesberger made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Assignee Gregory Boissinot [ gbois ]
            Hide
            mcklaus Klaus Azesberger added a comment -

            i updated my pull request 12 days ago - providing:

            • tests to reproduce/cover the issue/fix
            • a better fix (my first attempt was as "wrong" as the original version)

            i hope this gets reviewed/pulled.

            Show
            mcklaus Klaus Azesberger added a comment - i updated my pull request 12 days ago - providing: tests to reproduce/cover the issue/fix a better fix (my first attempt was as "wrong" as the original version) i hope this gets reviewed/pulled.
            Hide
            walterk82 Walter Kacynski added a comment -

            What is the status of this issue? I'm not sure what version of EnvInject that this problem was introduced but it very cumbersome that these values are not dynamic. I also noticed that when clicking "System Information" for each slave that these global variables are registered in this list and this does not occur if the EnvInject plugin is not installed.

            Show
            walterk82 Walter Kacynski added a comment - What is the status of this issue? I'm not sure what version of EnvInject that this problem was introduced but it very cumbersome that these values are not dynamic. I also noticed that when clicking "System Information" for each slave that these global variables are registered in this list and this does not occur if the EnvInject plugin is not installed.
            walterk82 Walter Kacynski made changes -
            Assignee Gregory Boissinot [ gbois ]
            Hide
            walterk82 Walter Kacynski added a comment -

            Could this in any way be related to change in JENKINS-16380 ?

            Show
            walterk82 Walter Kacynski added a comment - Could this in any way be related to change in JENKINS-16380 ?
            Hide
            gcummings Geoff Cummings added a comment -

            The following workaround fixed it for me:

            On main jenkins config page, turn on the option "Prepare jobs environment" and unselect "Unset System Environment Variables"
            Save Config and restart the slave.

            Show
            gcummings Geoff Cummings added a comment - The following workaround fixed it for me: On main jenkins config page, turn on the option "Prepare jobs environment" and unselect "Unset System Environment Variables" Save Config and restart the slave.
            Hide
            gcummings Geoff Cummings added a comment -

            I think it is related to the following code in EnvironmentVariablesNodeLoader:

            for (NodeProperty<?> nodeProperty : Hudson.getInstance().getGlobalNodeProperties()) {
                if (nodeProperty instanceof EnvironmentVariablesNodeProperty) {
                    EnvironmentVariablesNodeProperty variablesNodeProperty = (EnvironmentVariablesNodeProperty) nodeProperty;
                    EnvVars envVars = variablesNodeProperty.getEnvVars();
                    EnvInjectEnvVars envInjectEnvVars = new EnvInjectEnvVars(logger);
                    configNodeEnvVars.putAll(envVars);
                    envInjectEnvVars.resolveVars(configNodeEnvVars, nodeEnvVars);
                }
            }
            

            Without the "Prepare jobs environment" checked, the if statement above resolves to false so env vars are not updated.... i think.

            Show
            gcummings Geoff Cummings added a comment - I think it is related to the following code in EnvironmentVariablesNodeLoader: for (NodeProperty<?> nodeProperty : Hudson.getInstance().getGlobalNodeProperties()) { if (nodeProperty instanceof EnvironmentVariablesNodeProperty) { EnvironmentVariablesNodeProperty variablesNodeProperty = (EnvironmentVariablesNodeProperty) nodeProperty; EnvVars envVars = variablesNodeProperty.getEnvVars(); EnvInjectEnvVars envInjectEnvVars = new EnvInjectEnvVars(logger); configNodeEnvVars.putAll(envVars); envInjectEnvVars.resolveVars(configNodeEnvVars, nodeEnvVars); } } Without the "Prepare jobs environment" checked, the if statement above resolves to false so env vars are not updated.... i think.
            Hide
            walterk82 Walter Kacynski added a comment -

            That workaround doesn't seem to work for me however.

            Show
            walterk82 Walter Kacynski added a comment - That workaround doesn't seem to work for me however.
            Hide
            jglick Jesse Glick added a comment -

            I filed a new pull request to fix this.

            Upgrading priority since this bug breaks basic Jenkins functionality merely by installing a plugin, so it is far from obvious to a user where to start diagnosis.

            Show
            jglick Jesse Glick added a comment - I filed a new pull request to fix this. Upgrading priority since this bug breaks basic Jenkins functionality merely by installing a plugin, so it is far from obvious to a user where to start diagnosis.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
            http://jenkins-ci.org/commit/envinject-plugin/dedee1978345fa23e7d3773f64572c4a6f027882
            Log:
            [FIXED JENKINS-16316] Do not inject master node property variables into EnvVars.masterEnvVars on slaves.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java http://jenkins-ci.org/commit/envinject-plugin/dedee1978345fa23e7d3773f64572c4a6f027882 Log: [FIXED JENKINS-16316] Do not inject master node property variables into EnvVars.masterEnvVars on slaves.
            scm_issue_link SCM/JIRA link daemon made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Gregory Boissinot
            Path:
            src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
            http://jenkins-ci.org/commit/envinject-plugin/3371ed7601431b57780a30ddea4b84dd27e38b6e
            Log:
            Merge pull request #20 from jglick/sticky-var-JENKINS-16316

            JENKINS-16316 Changes to global variables not honored.

            Compare: https://github.com/jenkinsci/envinject-plugin/compare/b5cc29fc9695...3371ed760143

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java http://jenkins-ci.org/commit/envinject-plugin/3371ed7601431b57780a30ddea4b84dd27e38b6e Log: Merge pull request #20 from jglick/sticky-var- JENKINS-16316 JENKINS-16316 Changes to global variables not honored. Compare: https://github.com/jenkinsci/envinject-plugin/compare/b5cc29fc9695...3371ed760143
            Hide
            walterk82 Walter Kacynski added a comment -

            Upgrading to 1.88 has fixed the problem for me as well.

            Show
            walterk82 Walter Kacynski added a comment - Upgrading to 1.88 has fixed the problem for me as well.
            walterk82 Walter Kacynski made changes -
            Assignee Gregory Boissinot [ gbois ] Nicolas De Loof [ ndeloof ]
            jglick Jesse Glick made changes -
            Assignee Nicolas De Loof [ ndeloof ] Jesse Glick [ jglick ]
            walterk82 Walter Kacynski made changes -
            Assignee Jesse Glick [ jglick ] Nicolas De Loof [ ndeloof ]
            walterk82 Walter Kacynski made changes -
            Link This issue is related to JENKINS-5312 [ JENKINS-5312 ]
            Hide
            guyshaanan Guy Shaanan added a comment -

            Not sure if it is the same bug or a new one:
            When you have a build parameter, and you try to inject a value to it, the value is not injected.

            Ways to reproduce:
            JOB #1
            ----------
            1. Add build parameter called BRANCH (or whatever name you like)
            2. Add shell script with echo "BRANCH=test" > build.prop
            3. Inject build.prop using the envinject plugin
            4. echo ${BRANCH}
            >> this echos blank value (or the default value set to parameter) instead of "test"

            JOB #2
            -----------
            1. remove the parameter named BRANCH.
            Rest of the steps (2-4) remain the same:
            2. Add shell script with echo "BRANCH=test" > build.prop
            3. Inject build.prop using the envinject plugin
            4. echo ${BRANCH}
            >> this echos "test"

            We've upgraded Jenkins to 1.584 and envinject plugin to 1.90 and this behavior happens.

            Job #1 and Job #2 should both echo "test" to the screen.

            This was working before the upgrade we did (I don't remember which plugin version we had previously).

            Thanks.

            Show
            guyshaanan Guy Shaanan added a comment - Not sure if it is the same bug or a new one: When you have a build parameter, and you try to inject a value to it, the value is not injected. Ways to reproduce: JOB #1 ---------- 1. Add build parameter called BRANCH (or whatever name you like) 2. Add shell script with echo "BRANCH=test" > build.prop 3. Inject build.prop using the envinject plugin 4. echo ${BRANCH} >> this echos blank value (or the default value set to parameter) instead of "test" JOB #2 ----------- 1. remove the parameter named BRANCH. Rest of the steps (2-4) remain the same: 2. Add shell script with echo "BRANCH=test" > build.prop 3. Inject build.prop using the envinject plugin 4. echo ${BRANCH} >> this echos "test" We've upgraded Jenkins to 1.584 and envinject plugin to 1.90 and this behavior happens. Job #1 and Job #2 should both echo "test" to the screen. This was working before the upgrade we did (I don't remember which plugin version we had previously). Thanks.
            guyshaanan Guy Shaanan made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            jglick Jesse Glick added a comment -

            Guy Shaanan:

            Not sure if it is the same bug or a new one

            Then file a new bug report, and link it to this one as possibly related.

            Show
            jglick Jesse Glick added a comment - Guy Shaanan : Not sure if it is the same bug or a new one Then file a new bug report, and link it to this one as possibly related.
            jglick Jesse Glick made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            guyshaanan Guy Shaanan made changes -
            Link This issue is related to JENKINS-25141 [ JENKINS-25141 ]
            Hide
            bikrambora Bikram Bora added a comment -

            Issue still occuring on 1.92.1

            Had to revert to 1.88 to get it working

            Seems like there is a toss up between ->
            1. people using it on master (like me to inject variables during a build)
            2. people using it on nodes to set up the environment at the beginning.

            When one feature works the other seems to fail

            for usage 1 -> 1.88 works perfectly
            for usage 2 -> 1.92.1 seems to work

            Maybe fork the plugin into two separate plugins

            Show
            bikrambora Bikram Bora added a comment - Issue still occuring on 1.92.1 Had to revert to 1.88 to get it working Seems like there is a toss up between -> 1. people using it on master (like me to inject variables during a build) 2. people using it on nodes to set up the environment at the beginning. When one feature works the other seems to fail for usage 1 -> 1.88 works perfectly for usage 2 -> 1.92.1 seems to work Maybe fork the plugin into two separate plugins
            bikrambora Bikram Bora made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 147130 ] JNJira + In-Review [ 186105 ]
            ndeloof Nicolas De Loof made changes -
            Assignee Nicolas De Loof [ ndeloof ]

              People

              • Assignee:
                Unassigned
                Reporter:
                ndeloof Nicolas De Loof
              • Votes:
                4 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated: