Rule to prevent merges >x commits behind target
Problem to solve
From @dosuken123
In general, even though a feature branch is several commits behind from HEAD, it's unlikely to break a pipeline. But, if it's 100 commits behind, it would, if it's 1000 commits, the chance of breaking pipeline will significantly increase. In addition, we don't have a safe mechanism to check how old master the feature branch is based on. I'd still suggest to take the advantage ourselves, it's simply valuable functionality.
Target audience
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
Delaney wants to keep the downstream branch working so having a policy to prevent merges that need to be tested with a rebase (even if they technically merge) would be helpful.
Further details
This will also help keep master green in relation with https://gitlab.com/gitlab-org/gitlab-ee/issues/7380
Proposal
TBD
What does success look like, and how can we measure that?
TBD
What is the type of buyer?
Individual Contributors (Core)