Hello to all the existing, and soon-to-be, fans of Trunk! As of not too long ago, I became the Developer Advocate for Trunk. I wanted to take a few moments to tell y’all about the experience I had with my first Pull Request (PR) to merge into the Trunk Monorepo, our single source of truth.
I really shouldn’t have been surprised by how easy it was. Trunk’s entire purpose is to enhance the developer experience, after all. For starters, using the Trunk Check VS Code Extension to ensure that the code changes I was making were automatically run through the necessary linters and formatters, was a big help. This way, I knew that at least my changes were in a good state before I committed them to the repository. But, that isn’t really why we’re here. I want to talk about my first experience with Trunk Merge.
Trunk Merge is a service that connects directly to your GitHub repository and will queue all your PR’s, smack them around with all of the tests you need to have run, then merge them automatically into the Main branch. This type of service ensures that all the code that gets merged not only passes tests in isolation but that it passes tests when merged into the Main branch, avoiding the dreaded broken Main branch caused by logical merge conflicts. This may not be hugely necessary for a single developer but can become exponentially more helpful when you have a team of developers working on the same codebase.
“How do you set up a workflow for something like that?” you ask. Great question! Our repository is set up with branch protection rules so that things can’t just be YOLO’d into the Main branch. All PR’s are required to go through testing before they are merged. We also have a two-key rule where the PR needs to be reviewed and approved by someone other than the submitter. And on top of that, even when all criteria are met, you can’t just click “Merge” from the GitHub UI. Because we have so many developers working at once, we need to submit the PR to the merge queue. That task is as simple as writing a comment of /trunk merge inside the PR. That’s literally it.
That’s what makes this entire process so easy. I don’t have to sit and wait for any of the branch protection rules to be met. I don’t have to monitor testing. I don’t have to go back and manually click merge. Trunk Merge automatically takes over everything.
From my command, it added the PR to the merge queue. If there were other PR’s in line before mine, then my PR was tested automatically against a test branch that consisted of the Main branch + the anticipated PR(‘s) ahead of me. Because, why would I care about just testing against Main if that won’t be what the code looks like when mine is ready to merge? It is also aware that the PR requires approvals in GitHub.
Once all the required branch protection rules are satisfied, my PR is merged to Main automatically.
What’s that you say? You don’t want to go back to GitHub to find out when your PR is merged? Never fear, there’s a Slack notification for that!
So, what did I do after I typed /trunk merge into the PR? I went and did something else. Why would you want to babysit a PR that you already know is going to be good to go when you can just move on to whatever is next? Exactly, you wouldn’t. Interested in having this kind of set it, and forget it workflow for your team? You should definitely check us out!
