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.