Every day, many projects use Mergify to automate their GitHub workflow. Independently of their team size, the one thing they all have in common is that the project leads are willing to let their developers focus on what's important—code. So, we decided to meet with some of them to learn more about their challenges and discover how Mergify helps them be more efficient regarding pull requests. This time, we talked to Adrian Jost, an enthusiastic developer with a wide range of personal projects.
Can you tell us more about you and your project?
I am a software developer based in Berlin.
I joined the job market about four years ago, and before that, I studied computer science at Potsdam in Germany.
I'm currently working at Afilio, a young startup in the market of emergency and retirement provision.
In my spare time, I work on other side projects and contribute to open-source projects.
Are you alone on this project?
When I started using Mergify, it was part of a large open-source project. So, we work in a collaborative environment.
But now, I only use it for my personal projects. De facto, I'm the only one working on it and, therefore, the sole contributor.
I mainly work on private repos now and in my job. And unfortunately, we don't use Mergify there. And rightly so, since we don't need it at the moment.
What were your pain points?
For both my work and my personal projects, I use Dependabot to update my dependencies.
In theory, Dependabot can automatically merge dependency updates thanks to a specific feature. It can, therefore, take charge of the process from A to Z, creating pull requests and then merging them.
But that's just theory. As soon as there's a merge conflict, human intervention is required. Most of the time, this means asking Dependabot to rebase its PR, and that's it.
However, I couldn't automate this PR update process via GitHub Actions because of specific permissions, restrictions, or other constraints. That's where Mergify comes in. It does what I should be doing, i.e., asking Dependabot to rebase its pull requests.
But I'm guessing, by clarifying my use case, that this isn't the one Mergify was actually created for.
Can you tell us more about how you found Mergify?
I discovered Mergify during my previous professional experience at my last HPI Schul-Cloud job. That was three and a half years ago. We used it intensively on a public repo for an Open Source project.
After discovering Mergify, I adopted it on my projects to automate dependency updates.
I installed Mergify on all my public repositories, and now it must be three years since I've touched anything. Everything works very well, is automated, and is maintenance-free.
Mergify communicates with Dependabot autonomously to automatically merge all dependency pull requests. If all tests pass, of course.
Was it easy to set up?
It was super simple to install.
When Mergify was first created, configuring Mergify was super easy, thanks to the documentation. The tricky part was validating the configuration. It was more complicated.
So, I built a UI specifically to validate the configuration. A few months later, Mergify had implemented almost the same thing, and the documentation had been updated.
Did Mergify help you with your pain points?
Yes, of course, there's a before and after.
In my case, most of my projects are in some way "finished." But sometimes, I must return to them or use what I've done.
For example, seven months after the last modification, I had to return to a project and make a tiny change. The great thing is that I can get straight down to work without worrying about whether my dependencies are up to date. Mergify and Dependabot will have done their utmost to ensure this, except for those that would have led to errors. But that's rare.
So it's a huge time-saver and a lighter mental load. I can concentrate on the needed features and keep myself manageable.
Before, I had to take a long time to find out which dependencies needed updating and do it by hand before I could get on with what I needed.
This helps enormously with motivation. I can return to a project and concentrate on tiny change requests. When I'm working in my spare time or on the weekend, I want to spend only two or three hours updating all my dependencies before developing a feature in 15 minutes.