Live data from Hacker News

Ask HN: How are pull requests integrated in a repo with high commit frequency?

news.ycombinator.com

11–20 of 71 posts

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#12
post #6
post #2

Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...

Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.

[deleted]

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#13
post #6

Earlier quoted context omitted.

Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.

Almost there: https://github.blog/changelog/2021-10-27-pull-request-merge-...

To note, we signed up for the beta and got accepted in last week. Haven't turned it on yet though.

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#15
Our full acceptance test run in 3 hrs (on build servers with 64 cores and 3xx GB memory) and we have PRs coming up every hour or so.

We run the acceptance tests for all PRs and also the main branch after each change. So a given PR needs to be 'green', and if we merge the PR then we run the tests on the integration branch too. If the integration branchs gets broken somehow, then all merges stop -- we don't merge any further PRs into a 'broken' branch.

We have tried the option of always rebasing PRs on the most recent integration branch and re-running the tests, but that results in exponential number of builds.

Of course you need a meaningful build farm -- we have around 1000 CPU cores for ~30 developers that are fully utilised during work hours.

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#16
I work on a project with a 3 hour CI process that handles about 15 to 40 PRs a day. The problem you describe here is a real challenge. Our PRs don't use a merge button. Once CI passes (your changes built on latest develop), then you can click a box that says this PR should merge. An automated process scoops up all those PRs each night and builds them together. The system test team tests that build in the morning. If there is a problem, that is debugged (we build build some bifurcation builds ahead of time to make this faster). Then the batch is merged to develop. This process has worked very well for us. Develop keeps a good pace but is only very rarely broken.

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#17
post #5

Check out something like Bors, which implements a paradigm that fixes this class of issue: https://github.com/bors-ng/bors-ng (Homepage: https://bors.tech/ )

I can recommend it.

Even if you don't have a supper high commit frequency it is still nice to enable certain rebase/stacked PR workflows. Which can remove a lot of friction even for teams which "just" have idk. 6 PRs merged per day (but other PRs which are based on top of this PRs in review and progress maybe stacked multiple layers deep).

Re: Ask HN: How are pull requests integrated in a repo with high commit frequency?

#18
post #2

Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...

This is a great solution and while I was at Google I noticed several high commit frequency teams using this strategy. Of course Google had built a bunch of custom tooling and infrastructure around it, so I can’t vouch for how easy it would be to integrate into a different company’s dev workflow, but if there are enough developers to make it worthwhile, then tasking a few developers with setting this up should be a us…

GitLab has this feature.
Post reply on HN