|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
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.