> How frequent is creating new branches that are not backed by a PR in the real world? Because this delay should only really be required by new branches given that subsequent pushes to the branch already have the PR in place to tell Jenkins not to build the branch.
I do this all of the time once I've opened a PR and am making revisions against it; if I have a branch `feature` that is a PR then I'll push to `feature-staging`, verify that CI passes, then merge `feature-staging` into `feature`. This prevents me from accidentally pushing totally broken stuff to the original PR.
That being said, I've also been running into issues because of the current behavior. The most nefarious issue is when an intermittent failure causes the branch build to fail but the PR build succeeds; this causes the overall PR on GitHub to be marked as failing CI because of the branch build failure. A workaround is to manually re-trigger the build in the branch and hope it succeeds, but if the branch has been cleaned up there's no way to even re-trigger the branch build so the PR stays marked as failing CI with no way to fix the GitHub status from Jenkins. There should be some kind of way to (preferably automatically) detect and fix this issue from Jenkins.
In my opinion, the following two things should be done when a PR build is created and the corresponding branch is supposed to be excluded from the build:
- Abort any outstanding build jobs against the branch job
- Create a pending build status for the PR and then submit a successful build status against the branch (since there doesn't appear to be a way to clear existing statuses)
This would allow branch jobs to continue as normal while also doing the needed clean-up when a PR is opened.
In addition, when scanning a GitHub repo, Jenkins should check for PRs with stale build statuses and fix them as above.
Thoughts?
P.S. The workaround to fix a stale branch build status is:
$ curl -L -X POST -H "Authorization: Bearer ${TOKEN}" https:
My understanding of that option is that it doesn't actually prevent Jenkins from building from the untrusted source but rather just instructs Jenkins to ignore the Jenkinsfile such a change-request and use the Jenkinsfile from the project's master.The above was my confusing the new feature you are suggesting using with some previous functionality around PRs from untrusted sources.
How frequent is creating new branches that are not backed by a PR in the real world? Because this delay should only really be required by new branches given that subsequent pushes to the branch already have the PR in place to tell Jenkins not to build the branch. And if it were configurable from 0 to whatever delay a Jenkins admin desires, then it's backward compatible with existing (flawed) behaviour of anyone wants to retain that. But it does allow fixing this behaviour for anyone who desires that.
The gripers are griping about a completely different issue to this issue so it's really quite orthogonal. They are griping about an issue that occurs when trying to employ your suggested "work-around". And the explanation of why your work-around cannot work in some situations is only use-case why that work-around doesn't work.It could just plainly be that an organisation doesn't want PRs from forks for other organisational reasons.Ultimately any workarounds are just pussy-footing around the real issue of the branch/PR race that is inherent in any design which doesn't allow for a (configurable if you wish) delay to give the PR time to be submitted. So please, let's not get off into the weeds about why any particular work-around is not suitable and just fix the root issue?