Skip to content

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

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

maximum_commits_behind_check

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

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖