DEV Community

Cover image for [GitHub] Combine Pull Requests... For The Win!
Tib
Tib

Posted on

[GitHub] Combine Pull Requests... For The Win!

Picture from Lance Grandahl

In GitHub, whether you want to improve merge velocity, test interdependent changes or setup some sort of releasing model, you could be interested in grouping code changes.

It is called "bundling" or "combining" pull requests.

It allows multiple pull requests to be built and tested together (in CI) and qualified together (e.g. pre-production deployment with shadow traffic).

In order to achieve this easily, you would need some automation. You're lucky, I'm going to share an elegant solution to solve this.

(before we continue, also think about GitHub merge queues)

Demo!

I have 2 pull requests (from forks) targeting main. They have passed minimal tests running on PR but I now would like to run long and consuming tests together. I also want to check they work well together without merging first one of them to main (or to a release branch).

My plan for the two following changes is to target the next release v2.3, so I added a label v2.3 to the pull requests:
Label v2.3

In order to trigger the bundle creation, I create the branch v2.3 from main
Create branch v2.3

Once I finished to create branch, it already started to run an action:
Combining

After seconds, the run is finished:
Combined

A new pull requests (targeting main) appeared:
New PR

The pull requests contains well the 2 pull requests changes (and branch v2.3 was updated):
PR combined contains 2 PRs

Later, when the bundled pull request will be merged, the combined pull requests will be automatically merged:
Remotely merged

Hello "combine-pull-requests"

This magic can happen thanks to the great combine-pull-requests πŸŽ‰

Thank you Bob van der Linden for this πŸ‘ πŸš€

This GitHub action makes it deadly simple to combine multiple pull requests based on their labels.

My preferred workflow consists in triggering bundle by branch creation (but you can use other events) then push and open a pull request to main.

I know you want to see the code, please find below my setup:



name: Combine
on: create

permissions: write-all

jobs:
  combine:
    runs-on: ubuntu-latest
    if: ${{ github.event.ref_type == 'branch'}}
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: bobvanderlinden/combine-pull-requests@master
        with:
          label: ${{ github.event.ref }}
          repo-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.event.ref }}
      - name: Create pull request
        uses: devops-infra/action-pull-request@v0.4.1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          title: "[${{ github.event.ref }}] combined!"
          body: ""
          source_branch: ${{ github.event.ref }}
          target_branch: main
          template: .github/BUNDLE_TEMPLATE.md
          label: "bundle


Enter fullscreen mode Exit fullscreen mode

Then you would probably put your build-test-deployment... at the end of this same workflow.

Or you can leave the responsibility to another workflow. There's various manners to differentiate the bundle from other pull requests, for instance you can filter the label bundle.

To give you an example on how you would run/skip a workflow based on PR having the label bundle:



on:
pull_request:
types:
- opened
jobs:
run_if:
if: contains(github.event.pull_request.labels.*.name, 'bundle')
runs-on: ubuntu-latest
steps:
- run: echo "This is a bundle, run more tests"

Enter fullscreen mode Exit fullscreen mode




What else?

What if I pushed a new commit to one of the pull request? Just need to delete and recreate branch v2.3. Same procedure applies if I want to add or remove a pull request from the bundle.

Customize to your needs, you can listen to more events than only on: create πŸ˜‡

Another great thing with labels is that same pull request can belong to multiple bundles πŸ”₯

Conclusion

You should design tooling and branching model that suits you the best, so maybe this is not for you, but I really like how elegant is this workflow and I needed to share.

I hope you can also find it useful for you.

Then, now it only remains for me to wish you "happy hacking!" 😁

Top comments (0)