New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-29066] potential fix #331
Conversation
for (BranchSpec branchSpec : getBranches()) { | ||
HEADS: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where it used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
useless indeed
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
@reviewbybees |
I think it is ready to merge, though the first commit seems to be solving a different problem. Wouldn't it be better to rephrase the commit message on the first commit to remove the reference to JENKINS-29066? Would you also consider an additional test case that I wrote while trying to confirm that it is well behaved with remote polling enabled and with remote polling disabled? It would also be nice to remove the unused label "HEADS" that was mentioned by Kostya. |
…ected during polling, and later call to determineRevisionToBuild won’t consider, resulting in infinite build schedule
This reverts commit ccd4efa.
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be |
🐝 |
@ndeloof, based on the reviewbybees process rules, since there has been 1 review (by Stephen) and more than 12 hours since the last commit, is this considered ready to merge? |
@MarkEWaite as non CB employer you can merge any PR without looking on their 🐝 |
@KostyaSha thanks for your note. I know that the process is very careful to describe that I can ignore the CloudBees markers, but I am trying to exercise extra care with the git plugin as we bring it to its next release. I hope we're not many days from the next release, since there are many fixes already merged and verified. I believe this PR needs to be merged and two PR's from Jean Blanchard, then we should be ready for a few days of final test and a release. |
@MarkEWaite from cloudbees review process PoV this PR indeed is ready to be merged |
[JENKINS-29066] potential fix
@@ -518,7 +518,7 @@ private boolean requiresWorkspaceForPolling(EnvVars environment) { | |||
for (GitSCMExtension ext : getExtensions()) { | |||
if (ext.requiresWorkspaceForPolling()) return true; | |||
} | |||
return false; | |||
return getSingleBranch(environment) == null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/**
* If the configuration is such that we are tracking just one branch of one repository
* return that branch specifier (in the form of something like "origin/master" or a SHA1-hash
*
* Otherwise return null.
*/
private String getSingleBranch(EnvVars env) {
// if we have multiple branches skip to advanced usecase
if (getBranches().size() != 1) {
return null;
}
Kills polling without workspace for jobs that tracks origin/**
and causes infinite builds for cloud slaves.
I was able to reproduce JENKINS-29066 using github.com/ndeloof/oki-docki-demo as a repository. JGit does return /ref/pull/1/merge as a candidate revision during polling, which is ignored by BuildChooser when looking for revisions to build, resulting in an infinite build loop.
This commit do ensure polling do only consider the configured refspecs. Probably need to also review the BuildChooser extension point to ensure it uses the same logic to avoid such issues