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