> Should CI create a merged branch behind-the-scenes and run tests on that before allowing the branch to be merged?
This is surprisingly difficult to get right, especially with projects with lots of concurrent changes. Gitlab merge trains[1] really help here.
1. https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli...
The answer to that is: yes. The final test cycle before landing code to master MUST be against the code that would be in master after merging.
This is what the better workflow tools do, among other things to prevent these weird error situations. We have Marge-bot for Gitlab. Uber open-sourced their tool for the same some time back.[0] Bors comes up often as a reference, too.[1]
0: Discussion at the time: https://news.ycombinator.com/item?id=19692820