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

Slave environment variables are not used during Git Polling

    XMLWordPrintable

Details

    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 -
          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.

          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.
          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
          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
          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.

          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.
          abayer Andrew Bayer added a comment -

          Resolved in 1.1.

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

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

          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 ]

          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.

          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.

          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

          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

          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

          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
          markewaite Mark Waite added a comment -

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

          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 -
          Resolution Fixed [ 1 ]
          Status Reopened [ 4 ] Resolved [ 5 ]
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 137510 ] JNJira + In-Review [ 204519 ]

          People

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

            Dates

              Created:
              Updated:
              Resolved: