|
||||||||
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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi,
I identified the reason (at least in our scenario).
We are currently using git-client 1.6.1. But I checked the sources, the bug is also contained in the latest HEAD (20d98ce042e4d9d5ea1f3247567072d8dd0e2e35).
We have a repo with several branches containing namespaces (e.g. "feature1/master").
In the job config as branch specifier we use "remotes/origin/feature1/master"
Having a look at the code you will recognize the following:
hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(AbstractProject<?, ?>, Launcher, FilePath, TaskListener, SCMRevisionState)
calls
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(String url, String branch)
In our case branch is "remotes/origin/feature1/master"
branch is split at '/' and only the last segment is used as branch -> "master" in our case (instead of "feature1/master" which would be correct)!
Since we have multiple "feature<x>/master" branches the called command returns multiple revisions and branches in random order.
$ git ls-remote -h ssh://git:29418/xy/main.git master
eb625526cc489b9466a709501550d5adab08e884 refs/heads/featureX/master
97dfc02c8a98745999d7fd1648b9532ac98be225 refs/heads/feature1/master
0e186342e89971ecd46ab58ffb999136326dabce refs/heads/featureY/master
CliGitAPIImpl takes the first entry which is not necessarily the correct one.
Since the hash does not match the hash of the last build the build is triggered again and again!
Kind regards,
Alexander Link
SAP AG, Germany