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

#1

Post by dist1ll » Thu, Apr 21, 2022, 1:04 PM UTC

So let's assume we open a pull request, merged current main into our feature branch and are running tests. The full acceptance test suite takes 5 minutes to complete. Meanwhile, in those 5 minutes, 10 other commits have been made. If we merge now, we can't be sure that we won't break stuff right?

So after merging the pull request, are you supposed to perform another set of regression tests? Hard to find info about that

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

#2

Post by Revell » Thu, Apr 21, 2022, 1:36 PM UTC

Sounds like you want to implement something like merge trains?[0]

[0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...

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

#3

Post by [deleted] » Thu, Apr 21, 2022, 1:38 PM UTC

[deleted]

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

#4

Post by dmurray » Thu, Apr 21, 2022, 1:39 PM UTC

You run the tests on the same snapshot of the code you are about to deploy. That might be 10 minutes or 2 hours or a month behind your trunk branch that got the 10 new commits.

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

#5

Post by apetresc » Thu, Apr 21, 2022, 1:40 PM UTC

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/)

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

#6

Post by carlmr » Thu, Apr 21, 2022, 1:41 PM UTC

Revell wrote: 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.

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

#7

Post by __alexs » Thu, Apr 21, 2022, 1:44 PM UTC

Such a code base is likely to be large and the changes distributed somewhat uniformly across it. This means that conflicts are actually not super likely and also that your assumptions are not highly likely to get invalidated by the commits that happen in between.

If your change does break after merging, it can usually either be quickly fixed with a minor code change or simply reverted immediately.

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

#8

Post by andersco » Thu, Apr 21, 2022, 1:47 PM UTC

Is it possible that the solution is to look at why there is such a high frequency of commits by different devs into the same main branch?

Rather than look for a technical solution I would explore process and culture changes, such as having the various devs making all the different commits start pairing.

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

#9

Post by tdumitrescu » Thu, Apr 21, 2022, 1:50 PM UTC

carlmr wrote: post #6

Revell wrote: 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.

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

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

#10

Post by chrisshroba » Thu, Apr 21, 2022, 1:51 PM UTC

Revell wrote: 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 useful allocation of engineer time.