They use Mergify: Wheatstalk

Every day, major projects use Mergify to automate their GitHub workflow. Whether they have a core team of 3 or 50 people, the one thing they all have in common is that the project leads are willing to let their developers focus on what’s really important—code. So we decided to meet with some of them to get to know more about the challenges they face and discover how Mergify helps their teams be more efficient when it comes to pull requests. For this iteration we sat down with the Canadian solutions architect Josh Kellendonk, the man behind the Wheatstalk project.

Please could you explain what the Wheatstalk project is.

Yeah, sure! So Wheatstalk is my small consulting business for cloud native AWS projects. It has been running for about 5 years now and there are 3 of us. I focus more on the software side and we typically work with the AWS Cloud Development Kit [CDK], which is a framework that helps define packages of features that you can put on Amazon and reuse. While consulting, we’ve developed a handful of targeted building blocks that we reuse from customer to customer and we package and ship those building blocks and put them up on npm, Python, Java, C#, and a bunch of different popular package management platforms so that others can access them.

What’s your GitHub workflow on this project?

What usually works for us is having a GitHub repository per construct project. We then use a CDK adjacent tool called Projen to maintain the project configuration. It’s kind of nice because it helps us with the boilerplate and maintenance of things like testing setups, configurations for CI/CD or automatic updates, and it includes a whole bunch of other features, including support for Mergify.

So typically what we’re doing is opening up feature branches and popping them up onto pull requests [PRs], where the work is subject to our CI and all the different processes that we have. And as we work we get continuous feedback on these features, and when the PRs are finally good to go for review, we do our review and approve. And if all that goes to plan, the PRs just pop into the main branch because Mergify is configured.

Regarding the CI/CD, we’re using GitHub actions. But for certain types of projects we need to reach out to the AWS cloud for CodePipeline, which helps us put actual infrastructure up when we make changes so that we can verify that things are actually working as they should be in a more production-like environment. We usually do that more on main branches than on feature branches and it usually happens after Mergify is involved.

When did you start using Mergify?

We have probably been using it for a year and a half now. We first saw it when we were working with the AWS CDK team in the main project repository. We saw that there were a significant number of PRs coming in and they were merging a high volume of things back into their PRs and into their main branch automatically. If that was working for them, we realized it could obviously work for us! Especially considering that we’re doing similar work that is built on their framework. We were using Projen to begin with, which added Mergify support at a certain point, and then we started using Mergify through Projen.

What features of Mergify do you use?

We’re primarily using the PR conditions. When CI passes and one person approves the PR, then Mergify automatically starts the process to put it into the main branch. When we do things like pull in the latest changes to the feature branch, it reruns the build, and if that passes it merges it in a squash capacity back into the main branch. Then it cleans up the PR and the extra branch.

How do you manage dependency PRs?

We have an automated process to approve those. As a part of our CI, when an update comes in, we run a battery of automated checks to see whether our code still works as expected. If all automatic checks pass, the update gets an auto approval because the PR has a special label on it.

What other features of Mergify do you use?

We use the merge queue. That’s a handy feature!

What’s your favorite Mergify feature?

Definitely the conditional PR rules! They save us a lot of time, especially when it comes to auto-update PRs. We’ve got enough testing on our projects to be pretty confident about any individual PRs coming in, no matter what they are. But automating that whole update process was a game-changer for us.

I also really like that you can mention “@Mergifyio” in the comments of a PR. I use that quite a lot when I need to pull things into my branch. I’ve also been in situations where I’ve created the PR before Mergify has been enabled on that project, and I need Mergify to come in and take a look at it. So I add @Mergifyio refresh and it gives me a little thumbs-up, which is really cool. And then it goes and does the work. I quite enjoy that!

What has been the biggest impact of using Mergify?

The thing I like the most about Mergify is that it increases the frequency at which we can apply updates to our codebase automatically. We have an automatic job that pulls in the latest dependencies and creates the PRs, and it does that every day. It means that any individual changes that could break our system happen in smaller increments. And because Mergify allows us to merge all of that very quickly, it streamlines our entire process for applying updates to our codebases. Because we have a large number of repositories, it’s basically doing that 26 times a day!

We like Mergify so much that we even use it for some of our customers and recommend it to them!

What would be your #1 tip for someone new to Mergify?

I would definitely recommend looking at some of your favorite projects and seeing how they use Mergify because you can find a lot of tips about the development process and the way they configure their Mergify. It might change the way you build your software!

If you had time to contribute to Mergify, what would that contribution be about?

I would like Mergify to monitor the status of downstream builds and deployments. And then, if those things fail, automatically cause a revert to happen on the main branch and reopen the PR. Then we can just resume work on the PR. Because what is happening is if we deploy something that breaks and wasn’t caught in CI, even though our systems are smart enough to automatically roll back changes if anything fails dramatically, we still end up with a broken main branch.