Hacker News Reader

Comment by orf | Hacker News Reader

> 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...

View on HN

> Should CI create a merged branch behind-the-scenes and run tests on that before allowing the branch to be merged?

Yes. Anything else is bound to run into the issue described in the article.

I'm honestly surprised that anybody would operate a system that does not do this. Master has to be where all tests are green.

> Should CI create a merged branch behind-the-scenes and run tests on that before allowing the branch to be merged?

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

1: https://github.com/bors-ng/bors-ng

This is helpful, thank you. I will bring this up with my colleagues.

It isn't difficult if you use tools like GitHub, Bitbucket, Azure DevOps, Gitlab, Gitea/GOGS, etc. Because they automatically create git refs for those merge commits for each Pull Request that you can use in your CI. Often called refs/pull-requests/<PR-ID>/merge or similar.

As I always understood it, the role of a CI server was primarily to draw together all outstanding ready-to-merge feature branches into a single merged proposed branch and run integration tests against that. Anything which didn't integrate would be marked red by default, effectively "breaking the build". By doing that consistently before merging you'd have many fewer opportunities to land things which break other branches.

The "integration" part of CI appears to have largely been lost - CI pipelines now tend to just build branch tips and confirm tests run. Performing the proposed merge and checking that combination still runs is still pretty rare IME.

I'd like to actually do this, but how do you tell your CI server what it needs to merge where? In our case we have Jenkins and BitBucket. It's not in my power to change that, and these tools aren't integrated that well (to my knowledge) that you could say which PRs are open and which branch merges into which.

Maybe if you have a workflow where it's always the same target branch (master) it works, but we often have long standing feature branches that get multiple smaller merges from other branches.

Bitbucket (at least on-premise version) has REST api designed to give you information and allow to modify existing PRs.

This is new to me, thank you for sharing! It would fit the bill. Very interesting.

EDIT: Hang on a second, Tom Forbes! Fancy bumping into you here yet again. It's Dan from Marvel!

Is this the best OSS implementation of this? It looks like there's research in doing it better[0] but I can't find an open implementation.

[0] https://news.ycombinator.com/item?id=19692820

Reply on news.ycombinator.com