Adjust the merge train to pull and merge when a push fails
Context
On security releases, the merge train is used in two ways:
- During the security release, the merge train updates GitLAb security with canonical changes
- At the end of the security release, the merge train syncs GitLab canonical with the security changes.
Roughly, the merge train logic is:
- The merge train clones or updates both repositories (source and target)
- It attempts to merge the source branch into the target branch.
- Pushes the result to the target repository.
- If the push fails, because the target repository was updated (= a commit was pushed to the branch), a rebase is performed to update the target branch with the new content, then a push is retried.
- Step
4
is repeated 5 times.
The above caused a race condition on the last security release (details on https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/19435#note_1451314842) and the rebase strategy was removed gitlab-org/merge-train!46 (merged)
Problem
Without the rebase, the target branch is not updated with the new changes, and the subsequent 5 git pushes will be deemed to fail.
Proposal
When syncing default branches on GitLab repositories, the target branches should be updated via pull and merge, so the subsequent git pushes containing the new changes, which pending on Git traffic, should allow the git push to go through
Considerations
The problem describe above, only affects projects that require preserving history (like the GitLab project), GitLab FOSS projects can be updated using a rebase strategy (via git_push_with_retries_and_rebase
).