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

Command line git tag collision behavior changed in git 2.20

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      Git client plugin 2.7.4 and earlier
    • Similar Issues:

      Description

      The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

      Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

      Git 2.20.0 release notes explain the change as:

      "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.

      The git client plugin seems to have been relying on the misguided fast forward rule.

      The man page for git 2.20 recommends strongly against moving (re-tagging) a tag on a shared repository. It says:

      However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.

      If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up.

      The test_fetch_with_updated_tag results report:

      hudson.plugins.git.GitException: 
      Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
      stdout: 
      stderr: 
       * branch            HEAD       -> FETCH_HEAD
       ! [rejected]        t          -> t  (would clobber existing tag)
      

      That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

      This affects git client plugin 2.7.4 and git client plugin 3.0.0. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            Fixed in git client plugin 2.7.5 released December 22, 2018

            Show
            markewaite Mark Waite added a comment - Fixed in git client plugin 2.7.5 released December 22, 2018
            Hide
            casey1911 Stanislav Jursky added a comment -

            Jenkins builds with Git client plugin 2.7.5 are still failing if there is tag update with same name.
            Still no --force parameter is used during tag fetch operation
             

            Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 1:
            ...
            ! [rejected]              same-tag     -> same-tag  (would clobber existing tag)

            And there is no "force tag" config in git plugin either.
             

            Show
            casey1911 Stanislav Jursky added a comment - Jenkins builds with Git client plugin 2.7.5 are still failing if there is tag update with same name. Still no  --force parameter is used during tag fetch operation   Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 1: ... ! [rejected] same-tag -> same-tag (would clobber existing tag) And there is no "force tag" config in git plugin either.  
            Hide
            henriklundahl Henrik Lundahl added a comment -

            Mark Waite, this is still a problem, as Stanislav Jursky wrote above. Can we re-open this?

            Show
            henriklundahl Henrik Lundahl added a comment - Mark Waite , this is still a problem, as Stanislav Jursky wrote above. Can we re-open this?
            Hide
            markewaite Mark Waite added a comment - - edited

            Shame on me! I fixed the unit test which discovered the problem but failed to test the problem in a real world use case. I've created a real world use case and confirmed that it fails in that use case.

            Sorry about the incomplete fix in git client plugin 2.7.5.

            Please be sure to review the git tag man page which explains why moving tags is strongly discouraged.

            Show
            markewaite Mark Waite added a comment - - edited Shame on me! I fixed the unit test which discovered the problem but failed to test the problem in a real world use case. I've created a real world use case and confirmed that it fails in that use case. Sorry about the incomplete fix in git client plugin 2.7.5. Please be sure to review the git tag man page which explains why moving tags is strongly discouraged.
            Hide
            markewaite Mark Waite added a comment -

            Henrik Lundahl and Stanislav Jursky could you test the build of the pull request I've submitted? I wrote a test that failed then made a code change to pass the test.

            Show
            markewaite Mark Waite added a comment - Henrik Lundahl and Stanislav Jursky could you test the build of the pull request I've submitted? I wrote a test that failed then made a code change to pass the test.
            Hide
            casey1911 Stanislav Jursky added a comment -

            Mark Waite, tested on Jenkins 2.157 . Build you refereed now works. Thanks.

            09:22:07  > git fetch --tags --force --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*
            

            Regarding moving tags. we want to move some of them intentionally. Yes there are tags for every build that we need to trust and not move. But some our special tags refers to actual deployed version in different environments. And there's a tooling around it. No user push/move them by their own. Kind of special repository. 

            Thanks for fix. 

            Going to test this one on old Jenkins 1.651.1   

            Show
            casey1911 Stanislav Jursky added a comment - Mark Waite , tested on Jenkins  2.157  . Build you refereed now works. Thanks. 09:22:07 > git fetch --tags --force --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/* Regarding moving tags. we want to move some of them intentionally. Yes there are tags for every build that we need to trust and not move. But some our special tags refers to actual deployed version in different environments. And there's a tooling around it. No user push/move them by their own. Kind of special repository.  Thanks for fix.  Going to test this one on old Jenkins  1.651.1    
            Hide
            markewaite Mark Waite added a comment - - edited

            Fixed (in both places this time) in git client plugin 2.7.6 released January 10, 2019.

            Show
            markewaite Mark Waite added a comment - - edited Fixed (in both places this time) in git client plugin 2.7.6 released January 10, 2019.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: