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