We have a similar process where each merge to main runs the relevant CI pipeline again via GitLab merge trains, which effectively takes the head of main, rebases it onto your branch, then runs CI on it, and only merges the change if CI still passes on the current head. It means that merges are queued up, but it can be frustrating if you’re stuck behind commits to projects with slow pipelines (someone in our frontend team went wild with their CI setup).
We did this because we found that the CI could succeed on the branch but fail once merged into main if someone had made changes to similar areas of code, which led to a loss of productivity for everyone when they rebased main and their pipeline failed for something irrelevant to their changes.
It’s an interesting trade off, I’m sure a lot of people wouldn’t mind occasionally breaking main in exchange for more agility (if you rebase from main before committing you’re unlikely to have breaking changes, saving you from a queue, but there’s still some possibility of it happening), but I’m sure many people would be adamant that we should do our best to avoid breakages in main.
