|
||||||||
|
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/groups/opt_out.
It's Worse Than You Think.
The ls-remote polling, as written, makes a hard build/no-build decision based on the git ls-remote output only. This interacts ... poorly with the GitSCM plugin features that filter commits (UserExclusion and so on), since they need to look at the individual commits to make their own go/no-go decisions - but that can't be done remotely.
Forcing workspace polling fixes that (and I've got a related PR open for JENKINS-20607 anyways) but reintroduces the problem Christian et al are complaining about. I suspect the real solution is to always do the polling on the master, possibly outside the workspace, and have the build runs re-fetch and check out the correct commit.
From working on JENKINS-20607 I'm well aware of how much work that is.