Our RHEL server did not come with a supported version of git, so we had to compile from source. With the way our organization does access-control (we are rootless on our testing and production systems), we wanted to compile git from source on one machine in a directory where we have access, and then copy the compiled binaries to the same directory on other machines (including our Jenkins server).

      I have the new git binary located at /opt/mount1/opt/git-2.6.0/bin/git. I added the two properties and values into the Global Properties:

      GIT_HOME /opt/mount1/opt/git-2.6.0
      PATH $GIT_HOME/bin:$PATH
      

      , but it looks like Jenkins is still using the old GIT version. This is just speculative right now, it's throwing the same error (no remote helpers for HTTPS) as it was before I added GIT_HOME. I ssh'd into the computer and ran that same git clone command myself with the same (new) binary... it cloned the repo fine. Unless there's a way to debug the GIT plugin and find out explicitly what binary it's using, I can only go off of this evidence.

      I added a 'pre-build' step and ran echo $(which git) and it pointed to the correct binary - /opt/mount1/opt/git/bin/git, would GIT Plugin then be using this binary?

      Summary: We needed a newer version than what was available in the RHEL repos, so we compiled our own and can't get GIT Plugin to use this new binary.

      Thanks,
      Derek

          [JENKINS-30755] GIT Plugin doesn't respect GIT_HOME or PATH

          Mark Waite added a comment -

          The git environment manual page doesn't mention anything about a variable named GIT_HOME. Maybe you mean GIT_EXEC_PATH like in JENKINS-29243 ?

          If the PATH setting that places your custom git in the PATH prior to the system git is working, then the git executable should be found at your custom path. However, the supporting programs (which programs are supporting likely depends on your git version) will probably not be found. On my git 2.6.0 installation on Ubuntu, the supporting program git-commit (and others) are placed in /usr/lib, so they probably won't be found by the git program. That would likely then cause the git program to report its version as your custom built version, but then it might execute the supporting programs from the system installation.

          Mark Waite added a comment - The git environment manual page doesn't mention anything about a variable named GIT_HOME. Maybe you mean GIT_EXEC_PATH like in JENKINS-29243 ? If the PATH setting that places your custom git in the PATH prior to the system git is working, then the git executable should be found at your custom path. However, the supporting programs (which programs are supporting likely depends on your git version) will probably not be found. On my git 2.6.0 installation on Ubuntu, the supporting program git-commit (and others) are placed in /usr/lib, so they probably won't be found by the git program. That would likely then cause the git program to report its version as your custom built version, but then it might execute the supporting programs from the system installation.

          From the Git Plugin Wiki https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin:

          Setup your environment variables
          General hint: Avoid spaces in environment paths

          Mainly, you will need:

          GIT_HOME => Folder where your git.exe is located

          This is under the Windows section, but I assumed it may be usable by Linux versions as well.

          Do you know if these supporting programs are found in the normal git distro? I'd imagine they'd be included in the source I compiled. I compiled the source with a --prefix option, and made sure I placed the compiled git-2.6.0 in the same location on the Jenkins server.

          Derek Overlock added a comment - From the Git Plugin Wiki https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin : Setup your environment variables General hint: Avoid spaces in environment paths Mainly, you will need: GIT_HOME => Folder where your git.exe is located This is under the Windows section, but I assumed it may be usable by Linux versions as well. Do you know if these supporting programs are found in the normal git distro? I'd imagine they'd be included in the source I compiled. I compiled the source with a --prefix option, and made sure I placed the compiled git-2.6.0 in the same location on the Jenkins server.

          Mark Waite added a comment -

          As you noted, that is in the Windows section of the wiki page and specifically in a subsection describing the use of plink.exe, a replacement for ssh.exe. The plink.exe program is not relevant on Linux.

          I'm not sure who put the reference to GIT_HOME there or why they put it there, since GIT_HOME is not read by either the git plugin or the git client plugin, and GIT_HOME is not mentioned in the git plugin, git client plugin, command line git, or JGit source code.

          Since you compiled git on the same machine and in the same location as you installed it, then the EXEC_PATH setting should be correct. The problem described in JENKINS_29243 is for those cases where git is compiled in one location, then copied and executed from a different location.

          Mark Waite added a comment - As you noted, that is in the Windows section of the wiki page and specifically in a subsection describing the use of plink.exe, a replacement for ssh.exe. The plink.exe program is not relevant on Linux. I'm not sure who put the reference to GIT_HOME there or why they put it there, since GIT_HOME is not read by either the git plugin or the git client plugin, and GIT_HOME is not mentioned in the git plugin, git client plugin, command line git, or JGit source code. Since you compiled git on the same machine and in the same location as you installed it, then the EXEC_PATH setting should be correct. The problem described in JENKINS_29243 is for those cases where git is compiled in one location, then copied and executed from a different location.

          Thanks for the clarification. The mention in the Wiki indeed is misleading. I also agree that JENKINS_29243 is not the same issue, but this is still marked as a duplicate for that issue, can that be removed?

          From your first comment, it sounds like the Git plugin just uses whatever git is picked up first from the PATH env variable, is that correct?

          Derek Overlock added a comment - Thanks for the clarification. The mention in the Wiki indeed is misleading. I also agree that JENKINS_29243 is not the same issue, but this is still marked as a duplicate for that issue, can that be removed? From your first comment, it sounds like the Git plugin just uses whatever git is picked up first from the PATH env variable, is that correct?

          Mark Waite added a comment - - edited

          I compiled and installed git 2.6.0 on my Debian 6 machine (with --prefix=/usr/local) and on my CentOS 6 machine (with --prefix=/opt/git-2.6.0) and then inserted those git locations into the "Tool Locations" for each of those nodes. Then I ran tests which required at least git 1.7.10. The tests passed and the console log showed that the git executable I had declared was being used in the job.

          Screen shots of my configuration of the two machines are attached in case they help you see where I configured the git location.

          I think the way I've configured it is closer to the way the original support for non-standard locations was intended to be used. Can you try that configuration method instead of attempting to adjust the PATH environment variable?

          Mark Waite added a comment - - edited I compiled and installed git 2.6.0 on my Debian 6 machine (with --prefix=/usr/local) and on my CentOS 6 machine (with --prefix=/opt/git-2.6.0) and then inserted those git locations into the "Tool Locations" for each of those nodes. Then I ran tests which required at least git 1.7.10. The tests passed and the console log showed that the git executable I had declared was being used in the job. Screen shots of my configuration of the two machines are attached in case they help you see where I configured the git location. I think the way I've configured it is closer to the way the original support for non-standard locations was intended to be used. Can you try that configuration method instead of attempting to adjust the PATH environment variable?

          Mark Waite added a comment -

          No change planned, since there is a path which allows arbitrary installations of git to be used.

          Mark Waite added a comment - No change planned, since there is a path which allows arbitrary installations of git to be used.

            ndeloof Nicolas De Loof
            doverlock Derek Overlock
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: