Add "maximum commits behind" check before merge (#57581) · Issues · GitLab.org / GitLab FOSS · GitLab (original) (raw)
Add "maximum commits behind" check before merge
Problem to solve
Merging into a branch comes with certain risks, depending on how out of date the source branch is vs. the target. For a simple example, someone in the target branch may have removed a dependency that the source branch still needs. There's no merge conflict so the merge can go through, but there's a semantic problem that will result in everything not working.
We are addressing more advanced strategies for these kinds of pipelines by https://gitlab.com/gitlab-org/gitlab-ee/issues/9186, but a basic and easy to understand mitigation strategy could help immediately and allow more teams to immediately adopt https://gitlab.com/gitlab-org/gitlab-ee/issues/7380.
Even aside from those scenarios, having a simple rule for this can help nearly any project avoid broken masters. This feature can be considered a simple version of the more advanced EE feature.
Target audience
- Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
Further details
This would be further improved with automatic or scheduled rebasing: https://gitlab.com/gitlab-org/gitlab-ee/issues/895
Solution
Without having to analyze and understand interdependencies of everything in the project, we can help mitigate this by setting a maximum difference between the source and target branch in terms of number of commits. An elegant way to do this is to take the average number of commits per day (looking at a one month period) in the project and disallow merges that are > than that value behind. This helps in a couple different scenarios. Imagine a project with 25 commits per day:
- On an average day with about 25 commits happening, you can be about a day behind and there is no issue. You will only be prompted to rebase when you want to merge and are more than a day behind.
- In a "code freeze" situation where 75 commits are happening in a day, the risk is much higher that all of the things coming in will have semantic incompatibilities with each other. By using the average commits per day value, we automatically scale the number of rebases needed on that day in order to keep things more likely to succeed.
Because we don't know exactly how to tune this best, it makes sense to have two feature flags available to control the behavior.
- With feature flag 1 enabled, the maximum amount behind should be 1x the average commits per day value
- With feature flag 2 enabled, the maximum amount behind should be 2x the average commits per day value
- Both enabled should be considered invalid and disable the feature.
Design
- Add in check option of maximum commits behind
- Design relies on settings restructuring which is part of https://gitlab.com/gitlab-org/gitlab-ee/issues/7380
- Includes commit count
- When double value FF enabled copy should state
Source branch cannot be more than double the monthly average commits per day (30) behind the target branch(30)got removed =>Source branch cannot be more than double the monthly average commits per day behind the target branch
What does success look like, and how can we measure that?
TBD
What is the type of buyer?
Individual Contributor
Links / references
- Thanks to @dosuken123 for the nice idea
Edited Feb 18, 2019 by Dimitrie Hoekstra