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

Git plugin cannot find revision to build on Windows

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • git-plugin
    • None
    • Windows 2008 Server 64 Bit
      NTFS

    Description

      After we upgraded the Git plugin from 1.1.14 to 1.1.16, all our builds on Windows build slaves started failing like this:

      Started by user anonymous
      Building remotely on win-slave1 in workspace d:\hudson\workspace\my-app
      Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.Channel@95ff886:win-slave1
      Using strategy: Default
      Last Built Revision: Revision e00e2c1328a011ca99980e0ffd90f33337534b34 (origin/master)
      Checkout:my-app / d:\hudson\workspace\my-app - hudson.remoting.LocalChannel@470a4b80
      Fetching changes from 1 remote Git repository
      Fetching upstream changes from d:\hudson\shared\repo.git
      ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

      The builds on our Linux slaves are not affected. Wiping the workspaces on the Windows slaves did not help. Both clones and checkouts/updates seem to fail with the same error. Downgrading back to 1.1.14 made the Windows builds work again.

      Attachments

        Issue Links

          Activity

            downgrading to 1.1.15 works also.

            anthonype anthony escalona added a comment - downgrading to 1.1.15 works also.
            jcmoore Curt Moore added a comment -

            I'm also using Windows 2008 R2 64 bit for my build nodes and can also confirm that downgrading to 1.1.15 resolves the issue. Can we bump this to a higher priority?

            jcmoore Curt Moore added a comment - I'm also using Windows 2008 R2 64 bit for my build nodes and can also confirm that downgrading to 1.1.15 resolves the issue. Can we bump this to a higher priority?
            mlbright Martin-Louis Bright added a comment - - edited

            This happens on Centos 6.2 (Jenkins master) and Windows 7 (Jenkins slave) too. And downgrading also fixes the issue on these platforms.

            mlbright Martin-Louis Bright added a comment - - edited This happens on Centos 6.2 (Jenkins master) and Windows 7 (Jenkins slave) too. And downgrading also fixes the issue on these platforms.
            karl Karl Larsaeus added a comment -

            I see this issue too while running a Jenkins slave on Windows XP.

            karl Karl Larsaeus added a comment - I see this issue too while running a Jenkins slave on Windows XP.

            I've looked into this issue, and I've found the following workaround :
            on windows, you have to use GIT_HOME\bin\git.exe instead of GIT_HOME\cmd\git.cmd

            The problem is that https://github.com/jenkinsci/git-plugin/commit/e4cbe704fc1740d1fc6e3e0887476b95db230c60 added ^

            {commit}

            option to git rev-parse to dereference tags. However when using the batch wrapper, it fails because ^ is an escape character in windows batches.

            vlatombe Vincent Latombe added a comment - I've looked into this issue, and I've found the following workaround : on windows, you have to use GIT_HOME\bin\git.exe instead of GIT_HOME\cmd\git.cmd The problem is that https://github.com/jenkinsci/git-plugin/commit/e4cbe704fc1740d1fc6e3e0887476b95db230c60 added ^ {commit} option to git rev-parse to dereference tags. However when using the batch wrapper, it fails because ^ is an escape character in windows batches.

            Thanks Vincent! You workaround works for me. I just needed to manually set the HOME environment variable so that the http login would continue to be read from ~/_netrc.

            rec Richard Eckart de Castilho added a comment - Thanks Vincent! You workaround works for me. I just needed to manually set the HOME environment variable so that the http login would continue to be read from ~/_netrc.
            ritzmann ritzmann added a comment -

            I can confirm that setting the executable to git.exe instead of git.cmd works for us.

            ritzmann ritzmann added a comment - I can confirm that setting the executable to git.exe instead of git.cmd works for us.
            dantliff David Antliff added a comment -

            Is this related to https://issues.jenkins-ci.org/browse/JENKINS-13051 ?

            Note that I see this problem with the Cygwin version of git - I am using git.exe not git.cmd (which doesn't exist), so not sure whether the workaround mentioned can be applied?

            dantliff David Antliff added a comment - Is this related to https://issues.jenkins-ci.org/browse/JENKINS-13051 ? Note that I see this problem with the Cygwin version of git - I am using git.exe not git.cmd (which doesn't exist), so not sure whether the workaround mentioned can be applied?

            I have faced this problem because I was trying to call a personal git wrapper shell script instead of git.exe.
            As a workaround I created a simple exe that is putting quotes around each parameters before calling the script.
            It works, used on windows & linux. Putting double quotes around the parameters that contains '^' could solve the problem.

            blatinville Bertrand Latinville added a comment - I have faced this problem because I was trying to call a personal git wrapper shell script instead of git.exe. As a workaround I created a simple exe that is putting quotes around each parameters before calling the script. It works, used on windows & linux. Putting double quotes around the parameters that contains '^' could solve the problem.

            A workaroung that works for me is to spacify two branches to build, first master and then the one I actually want to build. Interestingly, only one branch is built this way, the second one.

            mikij Milutin Jovanovic added a comment - A workaroung that works for me is to spacify two branches to build, first master and then the one I actually want to build. Interestingly, only one branch is built this way, the second one.
            jcmoore Curt Moore added a comment -

            The workaround suggested in JENKINS-13051 seems to resolve this issue as well, for me at least. Any chance we can bump the priority on this one to better handle the ^ character?

            jcmoore Curt Moore added a comment - The workaround suggested in JENKINS-13051 seems to resolve this issue as well, for me at least. Any chance we can bump the priority on this one to better handle the ^ character?
            ctron Jens Reimann added a comment -

            I got the same issue with the current 1.1.18 version and needed to downgrade to 1.1.12 (which was the last version for me).

            ctron Jens Reimann added a comment - I got the same issue with the current 1.1.18 version and needed to downgrade to 1.1.12 (which was the last version for me).
            chantivlad chanti vlad added a comment -

            Same here. Windows Server 2008 x64 slave, had to downgrade from 1.1.18 to 1.1.15 (plugin built from source for Jenkins 1.463)

            chantivlad chanti vlad added a comment - Same here. Windows Server 2008 x64 slave, had to downgrade from 1.1.18 to 1.1.15 (plugin built from source for Jenkins 1.463)
            ido_ran Ido Ran added a comment -

            I also have the same problem. After I upgrade from 1.1.15 to 1.1.18 I get this exact error

            ido_ran Ido Ran added a comment - I also have the same problem. After I upgrade from 1.1.15 to 1.1.18 I get this exact error
            ido_ran Ido Ran added a comment -

            I've work around the problem by installing previous version 1.1.15 of the plugin.
            You can download it from here http://updates.jenkins-ci.org/download/plugins/git/

            ido_ran Ido Ran added a comment - I've work around the problem by installing previous version 1.1.15 of the plugin. You can download it from here http://updates.jenkins-ci.org/download/plugins/git/

            I managed to use the latest and greatest version of the git plugin and have it work on Windows. I installed the latest git for Windows package from git-scm.com. I installed it without the installer modifying environment variables. I installed Git in c:\git. Then I manually added c:\git\bin to the system PATH variable.

            mlbright Martin-Louis Bright added a comment - I managed to use the latest and greatest version of the git plugin and have it work on Windows. I installed the latest git for Windows package from git-scm.com. I installed it without the installer modifying environment variables. I installed Git in c:\git. Then I manually added c:\git\bin to the system PATH variable.
            chantivlad chanti vlad added a comment -

            @Martin-Louis: yes git is working manually on windows. We are here concerned about letting jenkins check out automatically an existing tag, whcih results in the error described above.

            chantivlad chanti vlad added a comment - @Martin-Louis: yes git is working manually on windows. We are here concerned about letting jenkins check out automatically an existing tag, whcih results in the error described above.
            svengothel Sven Gothel added a comment -

            This bug hinders us from updating the git plugin for our JogAmp project. The mentioned workaround of using a wrapper and escaping all git arguments seems to be to invasive to our running slaves. Would be great if this could get fixed.

            svengothel Sven Gothel added a comment - This bug hinders us from updating the git plugin for our JogAmp project. The mentioned workaround of using a wrapper and escaping all git arguments seems to be to invasive to our running slaves. Would be great if this could get fixed.
            vjuranek vjuranek added a comment -

            Hi,
            I send a pull request [1] which could solve this issue. However, I'm not windows expert and I currently even don't have any win machine available to test it, so it would be nice if someone could test git plugin with this patch and comment under the pull request if it solves the problem or not.
            Thanks

            [1] https://github.com/jenkinsci/git-plugin/pull/71

            vjuranek vjuranek added a comment - Hi, I send a pull request [1] which could solve this issue. However, I'm not windows expert and I currently even don't have any win machine available to test it, so it would be nice if someone could test git plugin with this patch and comment under the pull request if it solves the problem or not. Thanks [1] https://github.com/jenkinsci/git-plugin/pull/71

            Code changed in jenkins
            User: Vojtech Juranek
            Path:
            src/main/java/hudson/plugins/git/GitAPI.java
            http://jenkins-ci.org/commit/git-plugin/938ca81a991b1175d58fbcbb96b5efe37ab2f9a6
            Log:
            [FIXED JENKINS-13007] Handle special meaning of some charactes on Windows

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Vojtech Juranek Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/938ca81a991b1175d58fbcbb96b5efe37ab2f9a6 Log: [FIXED JENKINS-13007] Handle special meaning of some charactes on Windows

            Code changed in jenkins
            User: Nicolas De loof
            Path:
            src/main/java/hudson/plugins/git/GitAPI.java
            http://jenkins-ci.org/commit/git-plugin/db53ccea4188e182336f5e5c579f6adce34f6ecb
            Log:
            Merge pull request #71 from vjuranek/JENKINS-13007

            [FIXED JENKINS-13007] Handle special meaning of some charactes on Window...

            Compare: https://github.com/jenkinsci/git-plugin/compare/cef9941...db53cce

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De loof Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/db53ccea4188e182336f5e5c579f6adce34f6ecb Log: Merge pull request #71 from vjuranek/ JENKINS-13007 [FIXED JENKINS-13007] Handle special meaning of some charactes on Window... Compare: https://github.com/jenkinsci/git-plugin/compare/cef9941...db53cce

            The fix does not work when using Git plugin with Gerrit Trigger. I've created a fix for this and verified that git plugin still works without Gerrit. Please see https://github.com/Kryil/git-plugin/commit/3de8e933225d7cc5369193866cde6d585621a0a3

            kryil Ilari Mäkimattila added a comment - The fix does not work when using Git plugin with Gerrit Trigger. I've created a fix for this and verified that git plugin still works without Gerrit. Please see https://github.com/Kryil/git-plugin/commit/3de8e933225d7cc5369193866cde6d585621a0a3
            caspian311 Matt Todd added a comment -

            A little late, but we found a work around as well...

            Set the branch name to **/master or whatever your branch name is. This will work unless your Jenkins box uses multiple remotes.

            caspian311 Matt Todd added a comment - A little late, but we found a work around as well... Set the branch name to **/master or whatever your branch name is. This will work unless your Jenkins box uses multiple remotes.
            zaytsev Yury Zaytsev added a comment -

            So when the fixed plugin will be released? I see fixing commit from 3 June, we are 20 June and my Windows builds are still failing with an old plug-in / Jenkins LTS

            zaytsev Yury Zaytsev added a comment - So when the fixed plugin will be released? I see fixing commit from 3 June, we are 20 June and my Windows builds are still failing with an old plug-in / Jenkins LTS

            Code changed in jenkins
            User: Ilari Mäkimattila
            Path:
            src/main/java/hudson/plugins/git/GitAPI.java
            http://jenkins-ci.org/commit/git-plugin/3de8e933225d7cc5369193866cde6d585621a0a3
            Log:
            Fixed a windows bug caused by unneeded escaping of curly brackets.

            This is related to a reported bug https://issues.jenkins-ci.org/browse/JENKINS-13007

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ilari Mäkimattila Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/3de8e933225d7cc5369193866cde6d585621a0a3 Log: Fixed a windows bug caused by unneeded escaping of curly brackets. This is related to a reported bug https://issues.jenkins-ci.org/browse/JENKINS-13007

            Maybe this is because I use this with Cygpath plugin, but for me, http://jenkins-ci.org/commit/git-plugin/3de8e933225d7cc5369193866cde6d585621a0a3 was actually broken.

            I needed to use

            ^\\{commit\\}
            kohsuke Kohsuke Kawaguchi added a comment - Maybe this is because I use this with Cygpath plugin, but for me, http://jenkins-ci.org/commit/git-plugin/3de8e933225d7cc5369193866cde6d585621a0a3 was actually broken. I needed to use ^\\{commit\\}

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            src/main/java/hudson/plugins/git/GitAPI.java
            http://jenkins-ci.org/commit/git-plugin/8810661600f42c0ee2ce2d0352a2f01542b2c2af
            Log:
            [FIXED JENKINS-13007]

            On Windows command prompt, '^' is an escape character (http://en.wikipedia.org/wiki/Escape_character#Windows_Command_Prompt)
            This isn't a problem if 'git' we are executing is git.exe, because '^' is a special character only for the command processor,
            but if 'git' we are executing is git.cmd (which is the case of msysgit), then the arguments we pass in here ends up getting
            processed by the command processor, and so 'xyz^

            {commit}' becomes 'xyz{commit}

            ' and fails.

            Since we can't really tell if we are calling into git.exe or git.cmd, the best we can do for Windows
            is not to use '^

            {commit}

            '. This reverts 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0
            and it will not dereference tags, but it's far better than having this method completely broken.

            See JENKINS-13007 where this blew up on Windows users.

            I filed https://github.com/msysgit/msysgit/issues/36 as a bug in msysgit.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/8810661600f42c0ee2ce2d0352a2f01542b2c2af Log: [FIXED JENKINS-13007] On Windows command prompt, '^' is an escape character ( http://en.wikipedia.org/wiki/Escape_character#Windows_Command_Prompt ) This isn't a problem if 'git' we are executing is git.exe, because '^' is a special character only for the command processor, but if 'git' we are executing is git.cmd (which is the case of msysgit), then the arguments we pass in here ends up getting processed by the command processor, and so 'xyz^ {commit}' becomes 'xyz{commit} ' and fails. Since we can't really tell if we are calling into git.exe or git.cmd, the best we can do for Windows is not to use '^ {commit} '. This reverts 13f6038acc4fa5b5a62413155da6fc8cfcad3fe0 and it will not dereference tags, but it's far better than having this method completely broken. See JENKINS-13007 where this blew up on Windows users. I filed https://github.com/msysgit/msysgit/issues/36 as a bug in msysgit.

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            src/main/java/hudson/plugins/git/GitAPI.java
            http://jenkins-ci.org/commit/git-plugin/85afc7b0e64dd18c2807373880d1a8e2824fffbc
            Log:
            JENKINS-13007

            Based on the discussion in msysgit issue #36, tweaking the fix a bit more to bring back the capability to peal tags on Windows without getting affected by git.cmd/git.exe mess.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/git/GitAPI.java http://jenkins-ci.org/commit/git-plugin/85afc7b0e64dd18c2807373880d1a8e2824fffbc Log: JENKINS-13007 Based on the discussion in msysgit issue #36, tweaking the fix a bit more to bring back the capability to peal tags on Windows without getting affected by git.cmd/git.exe mess.
            jhansche Joe Hansche added a comment -

            I also saw the plugin break with the same error message as of upgrading from 1.1.19 to 1.1.21 (https://github.com/jenkinsci/git-plugin/compare/git-1.1.19...git-1.1.21). This is on a Linux server, however. I have downgraded back to 1.1.19, and that has fixed the problem.

            jhansche Joe Hansche added a comment - I also saw the plugin break with the same error message as of upgrading from 1.1.19 to 1.1.21 ( https://github.com/jenkinsci/git-plugin/compare/git-1.1.19...git-1.1.21 ). This is on a Linux server, however. I have downgraded back to 1.1.19, and that has fixed the problem.

            People

              ndeloof Nicolas De Loof
              ritzmann ritzmann
              Votes:
              37 Vote for this issue
              Watchers:
              40 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: