They use Mergify: Red Hat Hybrid Cloud Console
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 edition, we sat down (virtually) with Aviel Yosef, a software engineer at Red Hat working on the Red Hat Hybrid Cloud Console project.
Please could you explain what the Red Hat Hybrid Cloud Console project is?
It consists of a collection of services available on the hybrid cloud console that Red Hat provides, which delivers consistent capabilities across bare metal, virtual, private, and public cloud environments. Since late May 2021 my team and I have been developing one of the services available on the console, Edge API.
It’s an API server for edge management capabilities that provides RESTful web services.
What are the main challenges you encounter regarding pull requests on this Edge API project?
The complexity of the pull requests [PRs], without a doubt! Each one takes about 25 minutes to get merged. That’s because the build process of the images is thorough and the internal testing deploys them to an environment. Also, we do some analysis of the formal image that we don’t carry out with the external image.
Could you tell us more about the kinds of tests that you manage?
Sure! So there are both internal and external checks. External checks are handled by Travis, which does the PR checks, takes the images that we need to build within Red Hat’s internal system, and replaces them. For testing, we are actually using the outsource stream CentOS 8 instead of RHEL, because Red Hat images are internal and supported. We also do some cover testing, static analysis, and security code analysis of course.
When does Mergify swing into action?
Once the PR has been checked out—meaning the linting and the external and internal index checks passed—and if there are no labels such as “work in progress” or “do not merge”, no requested changes, and if it has been approved by at least one person, then Mergify kicks the PR into a queue. It merges the main branch into the feature branch and tests whether everything is OK. Then the PR is merged by Mergify automatically. The only exception is Dependabot PRs, which we are continuing to merge manually because we need to check them one by one, whether they are minor or major updates.
How did you first hear about Mergify?
I was helping some other teams at Red Hat that do FIDO Device Onboard [FDO] stuff and they were using it. My first reaction was, “Whoa, that’s cool!” That’s when I decided to give Mergify a try, to see if it could help us on the Edge API project. Also, I am an open-source guy, so I like using open-source projects like Mergify.
What was the team’s reaction when you introduced Mergify?
To be honest, they were a little bit suspicious, and they still are. And that’s understandable. Mergify can create PRs for itself, merge them into our codebase and possibly affect our stage environment or something else. It would be a disaster if something were to fall into the wrong hands! But I guess you could say that about almost everything on the GitHub marketplace. What made me feel more confident about using Mergify is that a lot of open-source projects are using it. It was not something that came out of the blue.
What Mergify features do you use the most?
The queue. But we use the basic one, not the premium feature one with priorities.
What is your favorite thing about Mergify?
The main goal of it! Which is to merge PRs automatically. Thanks to Mergify, I don’t need to look at a PR again once I’ve approved it! If an issue occurs, the person who created the PR will fix the code, and then Mergify will handle the rest and merge it.
What would be your #1 tip for someone new to Mergify?
To start by using the basics—the queue and the automatic merge. That’s what we do and it is good enough for us. In most cases, you don’t need anything else!
