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

ssh not found by git because PATH has been unexpectedly changed

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 1.565.1
      GIT client plugin 1.10.1
      GIT plugin 2.2.5
      GitHub API Plugin 1.56
      GitHub plugin 1.9.1
    • Similar Issues:

      Description

      Looks like an identical issue to JENKINS-14321, our setup is similar with a debian master and a windows 8 slave. GitHub Hook log is as follows:

      Started on 27-Aug-2014 16:48:45
      Polling SCM changes on XXX
      Using strategy: Default
      [poll] Last Built Revision: Revision a9212bd3ddab1e9f9303be8d7db06cf8b4087b8b (origin/master)
       > git ls-remote -h git@XXX:XXX/XXX.git master # timeout=10
      FATAL: hudson.plugins.git.GitException: Command "git ls-remote -h git@XXX:XXX/XXX.git master" returned status code 128:
      stdout: 
      stderr: error: cannot run ssh: No such file or directory
      fatal: unable to fork
      
      hudson.util.IOException2: hudson.plugins.git.GitException: Command "git ls-remote -h git@XXX:XXX/XXX.git master" returned status code 128:
      stdout: 
      stderr: error: cannot run ssh: No such file or directory
      fatal: unable to fork
      
      	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:462)
      	at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357)
      	at hudson.scm.SCM.poll(SCM.java:374)
      	at org.jenkinsci.plugins.multiplescms.MultiSCM.compareRemoteRevisionWith(MultiSCM.java:92)
      	at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357)
      	at hudson.scm.SCM.poll(SCM.java:374)
      	at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1449)
      	at hudson.model.AbstractProject._poll(AbstractProject.java:1420)
      	at hudson.model.AbstractProject.poll(AbstractProject.java:1331)
      	at com.cloudbees.jenkins.GitHubPushTrigger$1.runPolling(GitHubPushTrigger.java:73)
      	at com.cloudbees.jenkins.GitHubPushTrigger$1.run(GitHubPushTrigger.java:98)
      	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
      	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:724)
      Caused by: hudson.plugins.git.GitException: Command "git ls-remote -h git@XXX:XXX/XXX.git master" returned status code 128:
      stdout: 
      stderr: error: cannot run ssh: No such file or directory
      fatal: unable to fork
      
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1407)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1195)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1119)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1110)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2004)
      	at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:495)
      	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:460)
      	... 18 more
      Done. Took 20 ms
      No changes
      

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          If envinject plugin is installed, make sure the issue also occurs when that plugin is disabled (requires Jenkins restart).

          Show
          danielbeck Daniel Beck added a comment - If envinject plugin is installed, make sure the issue also occurs when that plugin is disabled (requires Jenkins restart).
          Show
          langers2k Rob Langley added a comment - Looks like https://github.com/jenkinsci/git-plugin/commit/897426d8004155c25f272189052b695c3aaadceb may have removed part of the original fix https://github.com/jenkinsci/git-plugin/commit/df304f7fe1d85798410ad7c3165a7d3cadcb4d05
          Hide
          langers2k Rob Langley added a comment -

          Envinject is installed (1.89) but it was working before I updated Jenkins (1.554.2) and the git plugins (Envinject didn't change).

          Previous versions of the git plugins were:
          GIT client plugin 1.9.1
          GIT plugin 2.2.1
          GitHub API Plugin 1.54
          GitHub plugin 1.8

          I'll look to see if we can disable Envinject temporarily tomorrow.

          Show
          langers2k Rob Langley added a comment - Envinject is installed (1.89) but it was working before I updated Jenkins (1.554.2) and the git plugins (Envinject didn't change). Previous versions of the git plugins were: GIT client plugin 1.9.1 GIT plugin 2.2.1 GitHub API Plugin 1.54 GitHub plugin 1.8 I'll look to see if we can disable Envinject temporarily tomorrow.
          Hide
          markewaite Mark Waite added a comment - - edited

          I don't understand why you think the polling change may have removed part of the earlier fix.

          If you are using Windows, then isn't it more likely that the new guessing logic trying to find the ssh.exe program is somehow wrong in your environment?

          Show
          markewaite Mark Waite added a comment - - edited I don't understand why you think the polling change may have removed part of the earlier fix . If you are using Windows, then isn't it more likely that the new guessing logic trying to find the ssh.exe program is somehow wrong in your environment?
          Hide
          markewaite Mark Waite added a comment -

          As yet another guess, based on comparing the source code of the git-client-plugin and your log, it seems that the command "git ls-remote" is attempting to fork the "ssh" command from inside "git ls-remote" but is unable to find the "ssh" command on the host where it is attempting to execute. The call to "ssh" seems to hint that this is executing on your Linux machine. Also, since the call to ssh is from inside "git ls-remote", it seems to be beyond the control of the git plugin or the git client plugin to make the ssh program available on the PATH when executing "git ls-remote".

          Are you confident that ssh is in the PATH on that machine in the context where the "git ls-remote" command is being executed?

          Show
          markewaite Mark Waite added a comment - As yet another guess, based on comparing the source code of the git-client-plugin and your log, it seems that the command "git ls-remote" is attempting to fork the "ssh" command from inside "git ls-remote" but is unable to find the "ssh" command on the host where it is attempting to execute. The call to "ssh" seems to hint that this is executing on your Linux machine. Also, since the call to ssh is from inside "git ls-remote", it seems to be beyond the control of the git plugin or the git client plugin to make the ssh program available on the PATH when executing "git ls-remote". Are you confident that ssh is in the PATH on that machine in the context where the "git ls-remote" command is being executed?
          Hide
          langers2k Rob Langley added a comment -

          So I've done a little more investigation, it would appear the git ls-remote command is being run on the Debian master rather than the windows slave. To ascertain this I renamed every git.exe on the windows machine which made no difference, after reverting them I did the same to /usr/bin/git which resulted in the following error:

          Started on 28-Aug-2014 10:17:24
          Polling SCM changes on XXX
          Using strategy: Default
          [poll] Last Built Revision: Revision 131f327074161ac81f7dc523363ec08841739669 (origin/master)
           > git ls-remote -h git@XXX:XXX/XXX.git master # timeout=10
          FATAL: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@XXX:XXX/XXX.git master
          hudson.util.IOException2: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@github.bromium.net:rob-langley/glowing-octo-dangerzone.git master
          	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:462)
          	at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357)
          	at hudson.scm.SCM.poll(SCM.java:374)
          	at org.jenkinsci.plugins.multiplescms.MultiSCM.compareRemoteRevisionWith(MultiSCM.java:92)
          	at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357)
          	at hudson.scm.SCM.poll(SCM.java:374)
          	at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1449)
          	at hudson.model.AbstractProject._poll(AbstractProject.java:1420)
          	at hudson.model.AbstractProject.poll(AbstractProject.java:1331)
          	at com.cloudbees.jenkins.GitHubPushTrigger$1.runPolling(GitHubPushTrigger.java:73)
          	at com.cloudbees.jenkins.GitHubPushTrigger$1.run(GitHubPushTrigger.java:98)
          	at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
          	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          	at java.lang.Thread.run(Thread.java:724)
          Caused by: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@XXX:XXX/XXX.git master
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1414)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1195)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1119)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1110)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2004)
          	at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:495)
          	at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:460)
          	... 18 more
          Caused by: java.io.IOException: Cannot run program "git": error=2, No such file or directory
          	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
          	at hudson.Proc$LocalProc.<init>(Proc.java:244)
          	at hudson.Proc$LocalProc.<init>(Proc.java:216)
          	at hudson.Launcher$LocalLauncher.launch(Launcher.java:780)
          	at hudson.Launcher$ProcStarter.start(Launcher.java:360)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1403)
          	... 24 more
          Caused by: java.io.IOException: error=2, No such file or directory
          	at java.lang.UNIXProcess.forkAndExec(Native Method)
          	at java.lang.UNIXProcess.<init>(UNIXProcess.java:135)
          	at java.lang.ProcessImpl.start(ProcessImpl.java:130)
          	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
          	... 29 more
          Done. Took 16 ms
          No changes
          

          Following up from this I swapped /usr/bin/git for a shell script that echo'ed the path and got:

          C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell1.0\;C:\Program Files (x86)\Gitin;C:\Program Files (x86)\Java\jre7in
          

          Which is completely wrong for a Debian box, I think the polling is picking up the path from the last build job then either incorrectly trying to use it on the Debian box or incorrectly running the polling on the Debian box. I imagine it's probably the former.

          Show
          langers2k Rob Langley added a comment - So I've done a little more investigation, it would appear the git ls-remote command is being run on the Debian master rather than the windows slave. To ascertain this I renamed every git.exe on the windows machine which made no difference, after reverting them I did the same to /usr/bin/git which resulted in the following error: Started on 28-Aug-2014 10:17:24 Polling SCM changes on XXX Using strategy: Default [poll] Last Built Revision: Revision 131f327074161ac81f7dc523363ec08841739669 (origin/master) > git ls-remote -h git@XXX:XXX/XXX.git master # timeout=10 FATAL: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@XXX:XXX/XXX.git master hudson.util.IOException2: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@github.bromium.net:rob-langley/glowing-octo-dangerzone.git master at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:462) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357) at hudson.scm.SCM.poll(SCM.java:374) at org.jenkinsci.plugins.multiplescms.MultiSCM.compareRemoteRevisionWith(MultiSCM.java:92) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:357) at hudson.scm.SCM.poll(SCM.java:374) at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1449) at hudson.model.AbstractProject._poll(AbstractProject.java:1420) at hudson.model.AbstractProject.poll(AbstractProject.java:1331) at com.cloudbees.jenkins.GitHubPushTrigger$1.runPolling(GitHubPushTrigger.java:73) at com.cloudbees.jenkins.GitHubPushTrigger$1.run(GitHubPushTrigger.java:98) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: hudson.plugins.git.GitException: Error performing command: git ls-remote -h git@XXX:XXX/XXX.git master at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1414) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1195) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1119) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1110) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2004) at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:495) at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:460) ... 18 more Caused by: java.io.IOException: Cannot run program "git": error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041) at hudson.Proc$LocalProc.<init>(Proc.java:244) at hudson.Proc$LocalProc.<init>(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:780) at hudson.Launcher$ProcStarter.start(Launcher.java:360) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1403) ... 24 more Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.<init>(UNIXProcess.java:135) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022) ... 29 more Done. Took 16 ms No changes Following up from this I swapped /usr/bin/git for a shell script that echo'ed the path and got: C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell 1.0\;C:\Program Files (x86)\Gitin;C:\Program Files (x86)\Java\jre7in Which is completely wrong for a Debian box, I think the polling is picking up the path from the last build job then either incorrectly trying to use it on the Debian box or incorrectly running the polling on the Debian box. I imagine it's probably the former.
          Hide
          markewaite Mark Waite added a comment -

          If it were me, I'd first go looking for other places which may have introduced that incorrect setting of the PATH environment variable. For example, check that the Jenkins system settings did not somehow get a PATH setting with those flawed values. A "grep" for that path string in the Jenkins home directory may quickly show you where that value has been incorrectly placed.

          I propose to close this as "not a bug", since there is no indication that the root of the problem is due to a git plugin or git client plugin bug.

          Show
          markewaite Mark Waite added a comment - If it were me, I'd first go looking for other places which may have introduced that incorrect setting of the PATH environment variable. For example, check that the Jenkins system settings did not somehow get a PATH setting with those flawed values. A "grep" for that path string in the Jenkins home directory may quickly show you where that value has been incorrectly placed. I propose to close this as "not a bug", since there is no indication that the root of the problem is due to a git plugin or git client plugin bug.
          Hide
          danielbeck Daniel Beck added a comment -

          Seriously Rob, things like this need to be reproducible with envinject disabled to be valid. It's been the real culprit too often...

          Show
          danielbeck Daniel Beck added a comment - Seriously Rob, things like this need to be reproducible with envinject disabled to be valid. It's been the real culprit too often...
          Hide
          langers2k Rob Langley added a comment -

          Before we close this I'd like to add some more info and understand what the correct resolution is.

          Removing envinject does solve the issue, as does rolling back the git plugin to 2.2.4 rather then 2.2.5. This testing was done on two separate machines from the original report, a OSX master and win7 slave. Can we reopen this as reverting the git plugin also fixes this issue which suggests it may be at least partially to blame.

          Thanks,

          Show
          langers2k Rob Langley added a comment - Before we close this I'd like to add some more info and understand what the correct resolution is. Removing envinject does solve the issue, as does rolling back the git plugin to 2.2.4 rather then 2.2.5. This testing was done on two separate machines from the original report, a OSX master and win7 slave. Can we reopen this as reverting the git plugin also fixes this issue which suggests it may be at least partially to blame. Thanks,
          Hide
          markewaite Mark Waite added a comment -

          I'm not persuaded that the change of the plugin from 2.2.5 back to 2.2.4 actually had anything to do with the "fix". I'm not aware of anything in the git plugin changes from 2.2.4 to 2.2.5 which would alter the value of a PATH environment variable and its impact on the PATH passed to a command line git invocation.

          I don't intend to investigate this any further, and I think at the moment I'm the primary person tracking git and git client plugin bug reports.

          Whether you choose to reopen it or not, my behavior will be the same, I'll ignore this bug report. I assume that eventually I'll return to it and close it completely as either "not a bug" or "cannot reproduce".

          Show
          markewaite Mark Waite added a comment - I'm not persuaded that the change of the plugin from 2.2.5 back to 2.2.4 actually had anything to do with the "fix". I'm not aware of anything in the git plugin changes from 2.2.4 to 2.2.5 which would alter the value of a PATH environment variable and its impact on the PATH passed to a command line git invocation. I don't intend to investigate this any further, and I think at the moment I'm the primary person tracking git and git client plugin bug reports. Whether you choose to reopen it or not, my behavior will be the same, I'll ignore this bug report. I assume that eventually I'll return to it and close it completely as either "not a bug" or "cannot reproduce".
          Hide
          langers2k Rob Langley added a comment -

          I have rebuilt the plugin on the 2.2.5 base with 897426d8004155c25f272189052b695c3aaadceb reverted and that looks to fix it for me.

          As to why I'm not sure yet but there is something in that commit that is either changing the behaviour or breaking an assumption elsewhere in the code.

          Show
          langers2k Rob Langley added a comment - I have rebuilt the plugin on the 2.2.5 base with 897426d8004155c25f272189052b695c3aaadceb reverted and that looks to fix it for me. As to why I'm not sure yet but there is something in that commit that is either changing the behaviour or breaking an assumption elsewhere in the code.
          Hide
          markewaite Mark Waite added a comment -

          I'd guess then that the portion which exposes the misconfiguration in your Jenkins job or Jenkins environment to the git plugin is at line 255 and 256 where the comment says:

          // add env contributing actions & values from last build to environment - fixes JENKINS-22009

          That's the key change which was in that commit. As far as I can tell, it is doing "the right thing" by making the environment variables available inside the plugin.

          I think that its discovery of your EnvInject related configuration issue is a happy side effect, not a bug which the git plugin can fix.

          Show
          markewaite Mark Waite added a comment - I'd guess then that the portion which exposes the misconfiguration in your Jenkins job or Jenkins environment to the git plugin is at line 255 and 256 where the comment says: // add env contributing actions & values from last build to environment - fixes JENKINS-22009 That's the key change which was in that commit. As far as I can tell, it is doing "the right thing" by making the environment variables available inside the plugin. I think that its discovery of your EnvInject related configuration issue is a happy side effect, not a bug which the git plugin can fix.
          Hide
          langers2k Rob Langley added a comment -

          Following the code, it looks like ln:486 in GitSCM.java deicides that it's possible to use fast remote poll.

                  // fast remote polling needs a single branch and an existing last build
                  if (!requiresWorkspaceForPolling() && buildData.lastBuild != null && buildData.lastBuild.getMarked() != null) {
          
                      // FIXME this should not be a specific case, but have BuildChooser tell us if it can poll without workspace.
          
                      final EnvVars environment = GitUtils.getPollEnvironment(project, workspace, launcher, listener, false);
          
                      GitClient git = createClient(listener, environment, project, Jenkins.getInstance(), null);
          

          This then uses getPollEnvironment (and in turn addEnvironmentContributingActionsValues) to get the last build env. This is working correctly as we saw in my previous comments, but it then uses this env on the Jenkins master to do the poll which is why I'm hitting the issue.

          This as least gives a workaround of forcing the polling to use a workspace. I guess EnvInject could be messing with this code but I don't know much about it.

          Show
          langers2k Rob Langley added a comment - Following the code, it looks like ln:486 in GitSCM.java deicides that it's possible to use fast remote poll. // fast remote polling needs a single branch and an existing last build if (!requiresWorkspaceForPolling() && buildData.lastBuild != null && buildData.lastBuild.getMarked() != null) { // FIXME this should not be a specific case, but have BuildChooser tell us if it can poll without workspace. final EnvVars environment = GitUtils.getPollEnvironment(project, workspace, launcher, listener, false); GitClient git = createClient(listener, environment, project, Jenkins.getInstance(), null); This then uses getPollEnvironment (and in turn addEnvironmentContributingActionsValues) to get the last build env. This is working correctly as we saw in my previous comments, but it then uses this env on the Jenkins master to do the poll which is why I'm hitting the issue. This as least gives a workaround of forcing the polling to use a workspace. I guess EnvInject could be messing with this code but I don't know much about it.
          Hide
          danielbeck Daniel Beck added a comment -

          values from last build to environment

          In the case of node specific environment variables (can you tell the difference?), this is just wrong.

          Show
          danielbeck Daniel Beck added a comment - values from last build to environment In the case of node specific environment variables (can you tell the difference?), this is just wrong.
          Hide
          langers2k Rob Langley added a comment -

          Should addEnvironmentContributingActionsValues respect the reuseLastBuildEnv boolean that's passed in to getPollEnvironment:

          diff --git a/src/main/java/hudson/plugins/git/util/GitUtils.java b/src/main/java/hudson/plugins/git/util/GitUtils.java
          index 3d41ad3..68669bb 100644
          --- a/src/main/java/hudson/plugins/git/util/GitUtils.java
          +++ b/src/main/java/hudson/plugins/git/util/GitUtils.java
          @@ -254,7 +254,8 @@ public class GitUtils implements Serializable {
                   }
           
                   // add env contributing actions' values from last build to environment - fixes JENKINS-22009
          -        addEnvironmentContributingActionsValues(env, b);
          +        if (reuseLastBuildEnv)
          +            addEnvironmentContributingActionsValues(env, b);
           
                   EnvVars.resolve(env);
          
          Show
          langers2k Rob Langley added a comment - Should addEnvironmentContributingActionsValues respect the reuseLastBuildEnv boolean that's passed in to getPollEnvironment: diff --git a/src/main/java/hudson/plugins/git/util/GitUtils.java b/src/main/java/hudson/plugins/git/util/GitUtils.java index 3d41ad3..68669bb 100644 --- a/src/main/java/hudson/plugins/git/util/GitUtils.java +++ b/src/main/java/hudson/plugins/git/util/GitUtils.java @@ -254,7 +254,8 @@ public class GitUtils implements Serializable { } // add env contributing actions' values from last build to environment - fixes JENKINS-22009 - addEnvironmentContributingActionsValues(env, b); + if (reuseLastBuildEnv) + addEnvironmentContributingActionsValues(env, b); EnvVars.resolve(env);
          Hide
          markewaite Mark Waite added a comment - - edited

          I'm reopening this because Rob's question seems very reasonable, and there is a hint that JENKINS-24516 may be the same issue, manifest in a different manner.

          If it is the same issue, then the challenge becomes writing an automated test which will show the failure. Pull requests of an automated test to show the failure are certainly welcomed...

          Show
          markewaite Mark Waite added a comment - - edited I'm reopening this because Rob's question seems very reasonable, and there is a hint that JENKINS-24516 may be the same issue, manifest in a different manner. If it is the same issue, then the challenge becomes writing an automated test which will show the failure. Pull requests of an automated test to show the failure are certainly welcomed...
          Hide
          langers2k Rob Langley added a comment -

          Having spent a little more time looking at this, the above will cause JENKINS-22009 to reoccur, I think a better solution would be the following:

          diff --git a/src/main/java/hudson/plugins/git/util/GitUtils.java b/src/main/java/hudson/plugins/git/util/GitUtils.java
          index 3d41ad3..d770209 100644
          --- a/src/main/java/hudson/plugins/git/util/GitUtils.java
          +++ b/src/main/java/hudson/plugins/git/util/GitUtils.java
          @@ -266,8 +266,8 @@ public class GitUtils implements Serializable {
                   if (buildActions != null) {
                       for (Action action : buildActions) {
                           // most importantly, ParametersAction will be processed here (for parameterized builds)
          -                if (action instanceof EnvironmentContributingAction) {
          -                    EnvironmentContributingAction envAction = (EnvironmentContributingAction) action;
          +                if (action instanceof ParametersAction) {
          +                    ParametersAction envAction = (ParametersAction) action;
                               envAction.buildEnvVars(b, env);
                           }
                       }
          

          EnvironmentContributingAction is too wider net where are I believe ParametersAction will be much better. At least with my testing it looks to do the right thing with or without EnvInject installe. @danielbeck - it should only add parameters rather then environment variables which should avoid any instance of copying of node specific environments. It also passes the test case added for JENKINS-22009.

          As for a test case, I'm not sure. EnvInject hit this as EnvInjectPluginAction implements EnvironmentContributingAction, is it possible to set something in a test to create some thing similar?

          Show
          langers2k Rob Langley added a comment - Having spent a little more time looking at this, the above will cause JENKINS-22009 to reoccur, I think a better solution would be the following: diff --git a/src/main/java/hudson/plugins/git/util/GitUtils.java b/src/main/java/hudson/plugins/git/util/GitUtils.java index 3d41ad3..d770209 100644 --- a/src/main/java/hudson/plugins/git/util/GitUtils.java +++ b/src/main/java/hudson/plugins/git/util/GitUtils.java @@ -266,8 +266,8 @@ public class GitUtils implements Serializable { if (buildActions != null) { for (Action action : buildActions) { // most importantly, ParametersAction will be processed here (for parameterized builds) - if (action instanceof EnvironmentContributingAction) { - EnvironmentContributingAction envAction = (EnvironmentContributingAction) action; + if (action instanceof ParametersAction) { + ParametersAction envAction = (ParametersAction) action; envAction.buildEnvVars(b, env); } } EnvironmentContributingAction is too wider net where are I believe ParametersAction will be much better. At least with my testing it looks to do the right thing with or without EnvInject installe. @danielbeck - it should only add parameters rather then environment variables which should avoid any instance of copying of node specific environments. It also passes the test case added for JENKINS-22009 . As for a test case, I'm not sure. EnvInject hit this as EnvInjectPluginAction implements EnvironmentContributingAction, is it possible to set something in a test to create some thing similar?
          Hide
          langers2k Rob Langley added a comment -

          Mark, I just created a PR for this complete with a test case that should catch future regressions: https://github.com/jenkinsci/git-plugin/pull/253

          Thanks,

          Show
          langers2k Rob Langley added a comment - Mark, I just created a PR for this complete with a test case that should catch future regressions: https://github.com/jenkinsci/git-plugin/pull/253 Thanks,
          Hide
          markewaite Mark Waite added a comment -

          The fix has been merged to the 2.2.x branch and the master branch. It should be first available in the git plugin 2.2.6 release.

          Show
          markewaite Mark Waite added a comment - The fix has been merged to the 2.2.x branch and the master branch. It should be first available in the git plugin 2.2.6 release.
          Hide
          markewaite Mark Waite added a comment -

          Fixed in git plugin 2.2.6, released 20 Sep 2014

          Show
          markewaite Mark Waite added a comment - Fixed in git plugin 2.2.6, released 20 Sep 2014
          Hide
          markewaite Mark Waite added a comment -

          Refer to JENKINS-24786 for a possible unintended side effect of fixing this problem.

          Show
          markewaite Mark Waite added a comment - Refer to JENKINS-24786 for a possible unintended side effect of fixing this problem.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              langers2k Rob Langley
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: