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

Slave environment variables are not used during Git Polling

    Details

    • Similar Issues:

      Description

      Background;
      My windows %HOME% directory is on a network share. git is using an ssh key from this folder to locate the server. Running a hudson slave logged in as the same user doesn't have access this directory so requires a custom environment variable to specify a different folder.
      Setting a slave specific HOME environment variable works fine for running the build, but this variable is not used when polling for changes.

        Attachments

          Activity

          complete_looney complete_looney created issue -
          Hide
          abayer Andrew Bayer added a comment -

          I see the problem - we rely on AbstractBuild.getEnvironment when checking out, but in polling, we don't have an AbstractBuild available. Looking at the polling logic in other SCM plugins, it seems the standard approach here would be to use the previous build's environment - if there is no previous build, we're going to be building regardless, and the previous build will have run on the same node as the current polling, so the slave environment variables would still apply, etc. I'm testing this now and will push to Github once it's passed.

          Show
          abayer Andrew Bayer added a comment - I see the problem - we rely on AbstractBuild.getEnvironment when checking out, but in polling, we don't have an AbstractBuild available. Looking at the polling logic in other SCM plugins, it seems the standard approach here would be to use the previous build's environment - if there is no previous build, we're going to be building regardless, and the previous build will have run on the same node as the current polling, so the slave environment variables would still apply, etc. I'm testing this now and will push to Github once it's passed.
          Hide
          dogfood dogfood added a comment -

          Integrated in plugins_hudson-git-plugin #23
          JENKINS-7411 When polling, System.getEnv() was being used rather than the previous build's environment, as is done in other plugins - that's been fixed. Also made sure we force a build when there's never been a previous one - I'm pretty sure that was already happening, but I'd reallyr ather be sure.

          Andrew Bayer :
          Files :

          • src/main/java/hudson/plugins/git/GitSCM.java
          Show
          dogfood dogfood added a comment - Integrated in plugins_hudson-git-plugin #23 JENKINS-7411 When polling, System.getEnv() was being used rather than the previous build's environment, as is done in other plugins - that's been fixed. Also made sure we force a build when there's never been a previous one - I'm pretty sure that was already happening, but I'd reallyr ather be sure. Andrew Bayer : Files : src/main/java/hudson/plugins/git/GitSCM.java
          Hide
          complete_looney complete_looney added a comment - - edited

          I've upgraded the git plugin to 1.1 (hudson 1.380), now I'm seeing the %HOME% environment variable from the master server's system value "C:\User\Hudson" being used for executing git polling on the slave machine. Neither the slave machines system value for this variable "c:\work\hudson", nor the hudson configuration for this node "C:\Work\hudson" is being used.
          Note that the build is still using "C:\Work\hudson" correctly.

          Show
          complete_looney complete_looney added a comment - - edited I've upgraded the git plugin to 1.1 (hudson 1.380), now I'm seeing the %HOME% environment variable from the master server's system value "C:\User\Hudson" being used for executing git polling on the slave machine. Neither the slave machines system value for this variable "c:\work\hudson", nor the hudson configuration for this node "C:\Work\hudson" is being used. Note that the build is still using "C:\Work\hudson" correctly.
          Hide
          abayer Andrew Bayer added a comment -

          Resolved in 1.1.

          Show
          abayer Andrew Bayer added a comment - Resolved in 1.1.
          abayer Andrew Bayer made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          complete_looney complete_looney added a comment -

          No, it's not resolved in 1.1. The behaviour has changed, but is not correct.

          Show
          complete_looney complete_looney added a comment - No, it's not resolved in 1.1. The behaviour has changed, but is not correct.
          complete_looney complete_looney made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          mitchellh Mitchell Hashimoto added a comment -

          Just want to note that this is not fixed currently with 1.1 and around 8 months later.

          This is also important if you're specifying environmental variables such as GIT_SSH to point to a special SSH wrapper. The clone works fine but polling doesn't pick up this environmental variable so it can never tell if the repository changed.

          Show
          mitchellh Mitchell Hashimoto added a comment - Just want to note that this is not fixed currently with 1.1 and around 8 months later. This is also important if you're specifying environmental variables such as GIT_SSH to point to a special SSH wrapper. The clone works fine but polling doesn't pick up this environmental variable so it can never tell if the repository changed.
          Hide
          christophlinder Christoph Linder added a comment -

          Also: setting the tool location on the slave via environment variables is not considered during polling.

          Steps to reproduce using Jenking Git Plugin 1.3.0 on Jenkins 1.510:
          Set environment variable on master:
          PATH_TO_TOOLS=c:\somewhere\tools

          On the Slave:
          PATH_TO_TOOLS=d:\elsewhere\tools
          Tool-Location for default git installation: ${PATH_TO_TOOLS}/git/git.exe

          During polling, jenkins always tries to execute git.exe in c:\somewhere\tools, although it is run on the slave

          Show
          christophlinder Christoph Linder added a comment - Also: setting the tool location on the slave via environment variables is not considered during polling. Steps to reproduce using Jenking Git Plugin 1.3.0 on Jenkins 1.510: Set environment variable on master: PATH_TO_TOOLS=c:\somewhere\tools On the Slave: PATH_TO_TOOLS=d:\elsewhere\tools Tool-Location for default git installation: ${PATH_TO_TOOLS}/git/git.exe During polling, jenkins always tries to execute git.exe in c:\somewhere\tools, although it is run on the slave
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          src/test/java/hudson/plugins/git/GitSCMTest.java
          http://jenkins-ci.org/commit/git-plugin/c5b127f98ebc652eead68b39aa7f1c93094cbcc4
          Log:
          [FIXED JENKINS-7411]

          Environment variables are in fact not used at all during expansions.
          This commit fixes that. As discussed in the ticket, and as done
          elsewhere, the standard convention is to use previous build's
          environment to expand polling.

          Also see JENKINS-19042

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/git/GitSCM.java src/test/java/hudson/plugins/git/GitSCMTest.java http://jenkins-ci.org/commit/git-plugin/c5b127f98ebc652eead68b39aa7f1c93094cbcc4 Log: [FIXED JENKINS-7411] Environment variables are in fact not used at all during expansions. This commit fixes that. As discussed in the ticket, and as done elsewhere, the standard convention is to use previous build's environment to expand polling. Also see JENKINS-19042
          Hide
          markewaite Mark Waite added a comment -

          Closing the issue since the commit which fixed it was submitted over 6 months ago.

          Show
          markewaite Mark Waite added a comment - Closing the issue since the commit which fixed it was submitted over 6 months ago.
          markewaite Mark Waite made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 137510 ] JNJira + In-Review [ 204519 ]

            People

            • Assignee:
              abayer Andrew Bayer
              Reporter:
              complete_looney complete_looney
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: