You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alice creates a new merge request and assigns Bob and Charlie as reviewers
Both review the code and after all issues they raise are resolved by Alice, they approve the merge request and assign it to marge-bot for merging.
Marge-bot rebases the latest target branch (typically master) into the merge-request branch and pushes it. Once the tests have passed and there is a sufficient number of approvals (if a minimal approvals limit has been set on the project), Marge-bot will merge (or rebase, depending on project settings) the merge request via the GitLab API. It can also add some headers to all commits in the merge request as described in the next section.
Is not enough for a green master and I cannot see how this should be.
Basically if you work on a mono repo with a few developers that is what happens in real life:
Developer creates a MR and assign reviewers
Reviewers only have time on the next day or even later
Meanwhile other people have already merged into master
Because of ff-merge rebase gets nasty (Marge Bot has not yet been assigned to the MR because we are waiting for the reviewers)
Conclusion: Marge Bot won't help much. If the intention of Marge is only to merge once the policies succeeds, this is only a click in the UI > Merge button. The problem with GitLab is the Rebase button showing every time the remote changes causing developers to get crazy. The ff-merge strategy is not well seen by ours developers.
Suggestion: Allow Marge Bot to continously rebase without the intention of merging into the target branch. This should be possible by assigning Reviewers and Marge at the same time to the MR. Currently once ONE SINGLE Rebase get resolved by Marge Bot, Marge Bot gets unassigned from the list of Assignees on GitLab.
The text was updated successfully, but these errors were encountered:
The currently suggested workflow:
Is not enough for a green master and I cannot see how this should be.
Basically if you work on a mono repo with a few developers that is what happens in real life:
Conclusion: Marge Bot won't help much. If the intention of Marge is only to merge once the policies succeeds, this is only a click in the UI > Merge button. The problem with GitLab is the Rebase button showing every time the remote changes causing developers to get crazy. The ff-merge strategy is not well seen by ours developers.
Suggestion: Allow Marge Bot to continously rebase without the intention of merging into the target branch. This should be possible by assigning Reviewers and Marge at the same time to the MR. Currently once ONE SINGLE Rebase get resolved by Marge Bot, Marge Bot gets unassigned from the list of Assignees on GitLab.
The text was updated successfully, but these errors were encountered: