[eru]

> But prevent a merge request from being merged to your trunk branch until everything is green.

You want to go even further: only merge feature branches were you know that they won't break master after the merge.

Some feature branches might pass tests by themselves, but something has changed with master since they were branched off.

Bors (https://bors.tech/) helps with that.

[davedx]

Yep, forcing MR's to be rebased to the last master/develop commit helps a lot here. IIRC this is a feature you can enable in Gitlab. Much less chance your MR will break master/develop if your work is rebased on the latest commit.

[eru]

Bors doesn't force you to rebase. Forcing the rebase is super annoying in projects with more than a few developers (I've worked on one that did).

What bors does is essentially the same thing, but automated: after all the tests have run on your MR branch, and people have approved your changes, bors does a speculative merge into master, and runs the tests on that merge commit.

If the tests pass, bors declares that very same commit to be the new master.

The effect is the same as the Gitlab option you mention, but the busy work is done by the bot.