Prevent stale merge requests from being mergeable
Problem to solve
Merge requests specify a particular SHA to merge against in a target branch. As time goes by, the target branch moves on and the MR "falls behind". Depending on the files it touches, it can fall many thousands of commits behind without becoming unmergeable due to merge conflicts.
That an MR passed tests, etc, against a particular SHA in the target branch doesn't mean that it will succeed against the HEAD of that branch. So if we merge an MR that is very far behind the target branch, it can cause master to become red.
I know we have a number of solutions in the works to the general problem, including the Merge Train, but I think there's one more thing we can do
Intended users
Project maintainers, mostly.
Further details
A pattern that has recently emerged internally is for people to base their MRs against the last known good commit on master. As we are right now, when master has been red for a long time, this increases the risk of introducing new failures. As a maintainer, I push back on this (e.g., https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28743#note_178171698 ), but it would be nice to make GitLab enforce the rule.
Proposal
Add a "maximum age" (terrible name) setting to the project. When merge requests target a SHA older than this (measured either as number of commits behind, or age of the commit we're targeting, I don't mind), they autoamtically become unmergeable, and the author is sent a notification asking them to merge / rebase against latest master.
At GitLab, we could have this set to a fairly relaxed number (3 days, maybe 500 commits?) in normal circumstances, but when master is red, we could update it to require MRs to be within, say, 50 commits of HEAD.
The closer to HEAD we are, the more likely it is (although not certain, for sure) that the merge won't introduce new failures, so this gives us a route to make it less likely that new failures will be introduced, while failures already exist.
Permissions and Security
The setting should be controllable by project maintainers only.
Perhaps we should allow maintainers to "merge anyway" on a per-merge-request basis, perhaps not. That needs some thought.