They use Mergify: Rook
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 learn more about the challenges they face and discover how Mergify helps their teams be more efficient when it comes to pull requests. This time, we talked to Travis Nielsen, a senior principal software engineer at Red Hat and the lead maintainer for Rook.
Please could you explain what Rook is?
Rook is an open-source storage solution that works with the cloud-native environment Kubernetes. So basically, we make storage available to Kubernetes clusters. We became a CNCF [Cloud Native Computing Foundation] graduated project a couple of years ago. It’s a good sign that the community is adopting Rook—there are a lot of users in production, and we have a pretty active Slack community.
We also have over 10,000 GitHub stars, more than 270 million downloads, and over 400 unique users who have contributed to the project. We’re happy Rook is a project the community can use!
How many people are currently working on Rook?
We have two levels of maintainers: those who have access to merge, about five people, and those who only have approval access, about three people. So in total, we have about eight people who are regular contributors to the project and around five people on a full-time, everyday basis — one of which is me. I am the only maintainer still working on the project out of the people who created Rook in 2016 and announced the project at KubeCon Seattle.
Please describe your GitHub workflow.
We have our main branch where all pull requests [PRs] are expected to merge first, whether they are development features or bug fixes. But we don’t release builds from the master branch—we have release branches for that! Every 3 or 4 months, we create a new release branch and release from those. And every week or two, we implement a new patch release from those branches.
How do you manage dependency updates in this workflow?
We don’t have special branches for that—we have a PR when we need to pull in an update from a dependency, and the PR goes to the main branch. We make sure the CI is stabilized on the PR before the merge.
What are the main challenges with this workflow?
The main challenge is making sure that PRs are reviewed and of high quality! That’s tricky because every PR is different, and every contributor is different to work with. That’s not something tools can help with. Dividing the work among the maintainers is also a challenge, as not everyone is full-time.
So how does Mergify help with this workflow?
Mergify makes our lives a lot easier! After a PR is merged to the master branch, Mergify will automatically open a PR to backport it to the release branches based on labels. After it is backported, our CI GitHub Actions runs, and all the maintainers have to do is click to approve the backport PR. It is then automatically merged.
How many PRs do you manage on Rook?
We merge about 20 to 30 PRs a week. If we are developing larger features, then it’s fewer than that.
Could you tell us more about your merge policy?
We only require one person to approve a PR. But we don’t use the automatic merge—every PR must be merged by a maintainer manually. Only the backport PRs are merged automatically after they are approved.
What is your favorite Mergify feature?
Definitely the opening and merging of backport PRs! But other features are helpful. For example, we have a rule that adds a comment to each of the open PRs that are in conflict with a PR that has just been merged. It’s just helpful to notify people that there is a conflict and warn them that they will have to deal with it.
Another one is, if somebody opens a PR against the release branch directly, Mergify comments on the PR to ask if it was done on purpose so that we don’t accidentally merge things to release branches before the main branch.
What has been the most significant impact of using Mergify on your team’s performance so far?
I’d say we backport a lot more now than we used to because it was more painful to backport manually in the past.
What would be your #1 tip for someone new to Mergify?
If they have a similar workflow with release branches and merge to the main branch first, I’d say configure the backport to open PRs automatically and merge automatically. Get that feature working!
How would you improve Mergify if you could?
When a backport PR is opened, it would be nice to have the same labels that were on the PR in the main branch. This is because we have a label on some of the PRs to skip CI when a build is unnecessary. For example, documentation updates do not require CI validation. So if those backport PRs had this skip CI label added, we could save some resources on the unnecessary CI.
