-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Git client plugin 2.7.4 and earlier
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.
- links to
[JENKINS-55284] Command line git tag collision behavior changed in git 2.20
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.
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.
Henrik Lundahl
added a comment - markewaite, this is still a problem, as casey1911 wrote above. Can we re-open this?
Henrik Lundahl
added a comment - markewaite , this is still a problem, as casey1911 wrote above. Can we re-open this? 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.
henriklundahl and casey1911 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.
Stanislav Jursky
added a comment - markewaite, 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 
Stanislav Jursky
added a comment - markewaite , 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 Fixed (in both places this time) in git client plugin 2.7.6 released January 10, 2019.
Jenkins no longer supports any operating system that provides a command line git version older than 2.20. Red Hat Enterprise Linux 7 support (and its derivatives) ended in Nov 2023 with its command line git 1.8. Debian 10 support ended June 30, 2024 with its command line git 2.20.
Fixed in git client plugin 2.7.5 released December 22, 2018