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

Environment variables get polluted from nodes

XMLWordPrintable

      When using git-parameter-plugin sometimes when opening "Build with Parameters" branch fetching fails with following error:

      The default value has been returned
An error occurred while download data
Command "git ls-remote -h <valid-git-repo-url>" returned status code 128:
stdout: 
stderr: /tmp/ssh5427760289448293929.sh: 6: /tmp/ssh5427760289448293929.sh: ssh: not found
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Please look at the Log
Please check the configuration

       

      After investigation this happens because environment variables are fetched from lastBuild.

      See net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition getEnvironment

      To be more precise jobWrapper.getSomeBuildEnvironments() is at fault.

      This is not valid, because if lastBuild node has incompatible PATH value to jenkins master node, then ssh will not be found and commands will fail.

      In our case lastBuild node was a windows machine and jenkins master is a linux machine.

          [JENKINS-56558] Environment variables get polluted from nodes

          Amos Hason added a comment - - edited

          Hello,

          We encountered the same issue.

          Jenkins version: 2.164.1
          Git plugin version: 3.9.1
          Git Parameter plugin version: 0.9.6
          Master OS: Ubuntu 16.04.2
          Master JVM version: 1.8.0_191
          Master remoting version: 3.29
          Slave OS: Windows 10 Pro 10.0.17763
          Slave JVM version: 1.8.0_201
          Slave remoting version: 3.29

          Running `println "git ls-remote -h <URL>".execute().text` in the script console of the slave works fine, while clicking on the job's "Build with Parameters" (which runs the exact same command) brings out the same output as that of the OP: "stderr: /tmp/ssh5441311447548085150.sh: 6: /tmp/ssh5441311447548085150.sh: ssh: not found".

          The "ls-remote" during "Build with Parameters" only works while the slave is offline. The last successful build executed "ls-remote" on the master. This confirms the OP's hypothesis.

          Partial workaround: setting "Force polling using workspace" under "Additional Behaviours" in "Source Code Management" with "Git", and then duplicating the job. This workaround only helps for the first build. After the first one, the issue reproduces.

          According to this, an update to the latest version of the Git Parameter plugin may solve this issue, but by looking at the OP's error reporting output, it's already the latest version there.

          Amos Hason added a comment - - edited Hello, We encountered the same issue. Jenkins version: 2.164.1 Git plugin version: 3.9.1 Git Parameter plugin version: 0.9.6 Master OS: Ubuntu 16.04.2 Master JVM version: 1.8.0_191 Master remoting version: 3.29 Slave OS: Windows 10 Pro 10.0.17763 Slave JVM version: 1.8.0_201 Slave remoting version: 3.29 Running `println "git ls-remote -h <URL>".execute().text` in the script console of the slave works fine, while clicking on the job's "Build with Parameters" (which runs the exact same command) brings out the same output as that of the OP: "stderr: /tmp/ssh5441311447548085150.sh: 6: /tmp/ssh5441311447548085150.sh: ssh: not found". The "ls-remote" during "Build with Parameters" only works while the slave is offline. The last successful build executed "ls-remote" on the master. This confirms the OP's hypothesis. Partial workaround: setting "Force polling using workspace" under "Additional Behaviours" in "Source Code Management" with "Git", and then duplicating the job. This workaround only helps for the first build. After the first one, the issue reproduces. According to this , an update to the latest version of the Git Parameter plugin may solve this issue, but by looking at the OP's error reporting output, it's already the latest version there.

          Amos Hason added a comment -

          Workaround: use HTTPS credentials.

          Amos Hason added a comment - Workaround: use HTTPS credentials.

          Boguslaw Klimas added a comment -

          Hi,

          enoyhs BIG KUDOS for you!!! you helped me a lot to resolve this and more the similar issues.

          I released plugin in version 0.9.11 where this issue was resolved, could you check that and confirm the issue is resolved

           
          Regards
          Boguslaw

          Boguslaw Klimas added a comment - Hi, enoyhs BIG KUDOS for you!!! you helped me a lot to resolve this and more the similar issues. I released plugin in version 0.9.11 where this issue was resolved, could you check that and confirm the issue is resolved   Regards Boguslaw

            klimas7 Boguslaw Klimas
            enoyhs Aigars Eglajs
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: