FYI: This should fix this: https://github.com/jenkinsci/git-client-plugin/pull/135 It hasn't been merged yet, but that PR does remove the "-h".

This is still repeatable, even with the change which removes the "-h" from the git ls-remote command line.

In my example, I created a job to build the git-client-plugin with the tag "refs/tags/git-client-1.10.0".

The first poll correctly detected that no build had been done, and the git ls-remote command reported the SHA1 of the tag, "2b8dd77821fc95a73b309b440e745b3e146c1e74".

The second and later polls continue to report the SHA1 of the tag, even though the repository had checked out the SHA1 of the commit to which the tag is pointing. That commit is "1fb23708d6b639c22383c8073d6e75051b2a63aa". Since the SHA1 returned by git ls-remote and the SHA1 of the local repository are different, the plugin assumes another build is required to make them the same. Since they can never be the same (because the ls-remote is requesting the SHA1 of the tag, not the SHA1 of the commit identified by the tag), the builds will run at every polling interval.

I still see Jenkins using the "-h" in polling. I'm using git-client 1.10.1 and git 2.2.5 at the moment. It does appear to strip the "-h" when I prefix with refs/tags. Is it intentional that the "-h" is only removed there and not globally?

That aside, you're right about that tag issue. I'd initially only considered lightweight (i.e. not annotated) tags, which don't have their own object.

Adding a suffix of "~0" or "^0" when using a tag will de-reference the tag and get the commit it refers to for many git operations, but that doesn't appear to work with "git ls-remote".

It is intentional that the "-h" is only dropped when the "refs/tags/tag_name" syntax is used, since that syntax was a new addition and we were not confident we could predict all the side effects if we removed the "-h" from the general case.

There is a suffix we can add which does resolve with ls-remote. It is

git ls-remote tag_name^{}

I haven't yet looked to see if that is safe for both annotated and lightweight tags. If not, then it might require two calls to "git ls-remote" in the refs/tags case, once for annotated tags and once for lightweight tags.

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
src/test/java/org/jenkinsci/plugins/gitclient/GitAPITestCase.java
http://jenkins-ci.org/commit/git-client-plugin/4362cf66b19519a558984d33f7e4272131087b6a
Log:
[Fix JENKINS-23299] tag based builds run at every poll

When a build is defined to use a tag, the "check for changes" uses
ls-remote to compare the SHA1 of the remote tag to the SHA1 of the HEAD
of the working directory. The tag SHA1 is not always the same as the
commit SHA1 (annotated tags), so when that happens, the ls-remote based
"check for changes" can never be satisfied.

This change adapts the tag specific check for changes to use a syntax
which returns the SHA1 of the commit referenced by the tag rather than
the SHA1 of the tag.

JGit always returns the SHA1 of the commit referenced by a tag (a
"peeled" object), while CliGit returns a "peeled" object for tags only
if the refs/tags/tag_name syntax is used.

That difference is maintained for behavioral compatibility for users
of CliGit. Cases where returning the SHA1 of the tag would be better
than returning the SHA1 of the commit referenced by the tag seem rare,
but better to retain CliGit compatibility than risk surprising users in
some as yet undetected use case.

Fixed in git-client-plugin 1.10.2, released 12 Sep 2014

Code changed in jenkins
User: Mark Waite
Path:
pom.xml
http://jenkins-ci.org/commit/git-plugin/4682d5ede81be35da32026c5a1e2124d59c230e3
Log:
Revert "Depend on git-client 1.10.2" until test failure fixed

This reverts commit 87beb7d0270c3058c90fd178b0aa96049ad6a900 until
the automated test which fails in the code can be fixed. The test is
specifically noted that it is an area of bugs in the prior client plugin,
and the fix of JENKINS-23299 in git client plugin 1.10.2 has improved
the behavior, but the test needs to be updated to show the new behavior
(and have its TODO comment removed).

Code changed in jenkins
User: Mark Waite
Path:
pom.xml
http://jenkins-ci.org/commit/git-plugin/8add48556e33f1bbb1595402086644863e0bbb63
Log:
Revert "Update git-client dependency to 1.10.2"

This reverts prior commit until the automated test which fails in the
code can be fixed. The test is specifically noted that it is an area
of bugs in the prior client plugin. The fix of JENKINS-23299 in git
client plugin 1.10.2 has improved the behavior, but the test needs to
be updated to show the new behavior (and have its TODO comment removed).

Code changed in jenkins
User: Mark Waite
Path:
pom.xml
src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java
http://jenkins-ci.org/commit/git-plugin/f654185b384a67b4e107f86d52b1ff2797c616d0
Log:
Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2

Intentionally skip one test, enable another

Depend on git-client-plugin 1.10.2

Code changed in jenkins
User: Mark Waite
Path:
pom.xml
src/test/java/hudson/plugins/git/CliGitSCMTriggerRemotePollTest.java
http://jenkins-ci.org/commit/git-plugin/12351a2ef8dc726144ae5e6234f0e240fc4a5977
Log:
Adapt tests for JENKINS-23299 fix and git-client-plugin 1.10.2

Intentionally skip one test, enable another

Depend on git-client-plugin 1.10.2

It appears not working.
I have Jenkins - 2.27
Git Client Plugin - 2.0.0
Git Plugin - 3.0.0

Project configured to build from "refs/tags/ci-qa"
But polling is still running with '-h'.
As result build is not initiated when revision of tag is changed.

+1
I have same request and am hitting same limitation where I cannot trigger a build just from a tag change (non-annotated tag).

Will the use of annotated tags get around this limitation ?

Are there any plans to fix that small but annoying bug?

progman No plans to fix this bug at this time. You're welcome to submit a pull request with automated tests which show the problem, and with a fix for the problem.