7 ms·

This is an ad. It doesn't introduce anything new and is probably not a great solution to the posited problem anyway. Put in-progress code paths behind developm

This is an ad. It doesn't introduce anything new and is probably not a great solution to the posited problem anyway. Put in-progress code paths behind development flags and merge frequently to main. That one sentence removes the need for extra tooling and obviates the need for more buzzwordy workflow names like "stacking" or "trunk based" or whatever the trendy thing is at the moment.

bryanlarsen 3y ago
What do you do if CI is slow and you're merging small commits frequently? For example, what if CI takes 15 minutes and you're trying to merge more than 4 PR's per hour? Our integration tests spin up and reboot Windows machines, it would be tough to get that test under 15 minutes. We use the "merge when pipeline succeeds" button on GitLab, but if two people have clicked that button it's a race. The winner gets their PR merged, the loser gets their pipeline invalidated because `main` has changed; they have to rebase onto main and try again. OTOH, if instead of rebasing onto main when running the final pipeline before merge you rebase onto what will be main once its pipeline succeeds your own pipeline will still be valid. In other words, by using stacking we can do final merge CI pipelines in parallel rather than series. Unfortunately, we haven't found good tooling for this flow that works with GitLab. git town does stacks and works with GitLab, but it has a few limitations that make it a poor fit for what I call "merge trains".
- iandanforth 3y ago
  We have dozens to hundreds of PRs merged per hour using this flow. Yes the pattern of requiring unchanged main causes a backup. Don't do that.
  - bryanlarsen 3y ago
    And you never break main doing that? MR A could be fine, MR B could be fine, but A+B can be broken. It's rare, but it does happen. It's not common enough to fix if the alternative is slowing down merges. But you can have your cake and eat it too -- merge trains allow rapid merging and ensure that the combination gets tested before merging.

bryanlarsen 3y ago

What do you do if CI is slow and you're merging small commits frequently? For example, what if CI takes 15 minutes and you're trying to merge more than 4 PR's per hour? Our integration tests spin up and reboot Windows machines, it would be tough to get that test under 15 minutes. We use the "merge when pipeline succeeds" button on GitLab, but if two people have clicked that button it's a race. The winner gets their PR merged, the loser gets their pipeline invalidated because `main` has changed; they have to rebase onto main and try again. OTOH, if instead of rebasing onto main when running the final pipeline before merge you rebase onto what will be main once its pipeline succeeds your own pipeline will still be valid. In other words, by using stacking we can do final merge CI pipelines in parallel rather than series. Unfortunately, we haven't found good tooling for this flow that works with GitLab. git town does stacks and works with GitLab, but it has a few limitations that make it a poor fit for what I call "merge trains".

iandanforth 3y ago
We have dozens to hundreds of PRs merged per hour using this flow. Yes the pattern of requiring unchanged main causes a backup. Don't do that.
- bryanlarsen 3y ago
  And you never break main doing that? MR A could be fine, MR B could be fine, but A+B can be broken. It's rare, but it does happen. It's not common enough to fix if the alternative is slowing down merges. But you can have your cake and eat it too -- merge trains allow rapid merging and ensure that the combination gets tested before merging.