Minor Use case:
- We have many PRs in-flight at any point in time. Often many of these are already-green PRs which are just waiting for code review to finish, but code review can often take a long time.
- Many times a day, a PR actually gets to merge, and new commits appear on master.
- We have a finite amount of resources available in our build farm, so we can't afford to run N(PRs) jobs for every commit. In fact, we're already paring down what we do test in PRs, because running the full suite on all supported platforms ties up too many resources.
Current behaviour:
- When the hourly scan of the repository comes around, all new commits to master trigger all PRs to rebuild.
- Rebuilding all PRs locks up the build farm for a long period of time, delaying all other PRs (typically noticed when the change in the PR you're trying to get built seems much more important than the others) while it rebuilds ones which have already passed.
What we'd prefer:
- When a new commit appears on master, it doesn't trigger a rebuild of all PRs at all.
- We do acknowledge that, yes, if a change goes into master, the PR might now be failing. But we don't have the budget to allocate enough resources to actually handle the ideal case, no matter how nice it would be to have that kind of budget. We're a big project with a lot of code, but we're not a Google and can't afford to throw money at the problem, even though it does seem like money is the only issue here.
- Developers can still manually merge master to their PR branch, which would then be a change in the actual PR branch, and would trigger a rebuild like normal.
I looked around for settings which might enable this kind of behaviour and I didn't see anything which looked like it could do this, but it's possible that I missed something.
[JENKINS-51936] Reduce trigger-happy building from master/upstream commits
trejkaz
added a comment - Hmm, it might. I was under the impression that we did still want to merge with the latest master when the build does run, but maybe losing that is acceptable considering the alternative.
I'll have to check.
trejkaz
added a comment - Hmm, it might. I was under the impression that we did still want to merge with the latest master when the build does run, but maybe losing that is acceptable considering the alternative.
I'll have to check. trejkaz
added a comment - After discussing this one with team members and others, I can confirm that we do still want to merge with the latest master if someone manually requests a new build, but that we still don't want new builds to kick off automatically for every change on master.
trejkaz
added a comment - After discussing this one with team members and others, I can confirm that we do still want to merge with the latest master if someone manually requests a new build, but that we still don't want new builds to kick off automatically for every change on master. trejkaz I'm not aware of any user interface setting that will cause "Build now" to perform a merge with the master branch without also causing each change to the master branch to run the build. I suspect that use case might be possible to cover by creating a new plugin which adds that behavior as a branch discovery implementation. That is how the multibranch Pipeline implementation has been generally guiding implementations of specialized behaviors.
You might also be able to implement the merge in your Jenkinsfile as a call to the git command line to perform the merge.
Kalle Niemitalo
added a comment - The Basic Branch Build Strategies plugin has this feature, "Ignore rebuilding merge branches when only the target branch changed". See https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/basic-branch-build-strategies-1.3.2/docs/user.adoc#change-requests. The feature has been there ever since the initial commit.
Kalle Niemitalo
added a comment - The Basic Branch Build Strategies plugin has this feature, "Ignore rebuilding merge branches when only the target branch changed". See https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/basic-branch-build-strategies-1.3.2/docs/user.adoc#change-requests . The feature has been there ever since the initial commit. Kalle Niemitalo
added a comment - Resolving as fixed because this feature worked when I used it. 
I think the use case you want is already covered by the GitHub branch source and the Bitbucket branch source. They both have an option to discover pull requests as:
The bitbucket branch source:
The GitHub branch source:
If you can confirm that meets your need, could you mark this as resolved?