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 talked to Xiangyu Wang, one of the maintainers working on the Milvus project.
Please could you outline the Milvus project in a few words.
In brief, Milvus is a database that helps people manage vectors, build efficient indexes, and provide high-quality similarity search services. Machine learning models convert unstructured data like text, pictures, or videos to vectors, which are then widely used in image searching systems, text searching systems, and recommended systems. But as there is no dedicated database, people always manage their vectors in applications, which is an inefficient and repetitive way to work. So we created Milvus to help people manage their vectors and make it easier to build search applications and recommended systems.
How many people are working on the project?
About 30 people, and most of them are from the company Zilliz. I am one of 5 maintainers working on the project.
What’s your GitHub workflow on this project?
When someone creates a pull request [PR] on GitHub, the continuous integration system gets an event from it and starts a Jenkins job to test the code in this PR. At the same time, GitHub Actions launches a task to do some lightweight checks on the code. The core team then reviews the PR and leaves some comments or a “LGTM”—looks good to me—message.
When all tests and checks are passed and the PR gets a “LGTM” message, it is merged into the master branch automatically. Finally, when the master branch is updated, a new docker image is built and uploaded to Docker Hub.
What are the main challenges with this workflow?
Some tests are too heavy for GitHub Actions so we need to run some tests in an internal Jenkins and the others on GitHub Actions. Consequently, the statuses of the tests are in different places. The main challenge is that we need to follow up on the updated status and synchronize with the authors in a timely manner. We need to inform the author what checks have failed and merge the PRs that pass. Updating these statuses is not an easy task, and if they are not updated quickly, PRs will pile up on GitHub.
What is your project merge policy?
A PR must meet three conditions to be merged. The first is that the code needs to pass various tests, including static code inspection, unit testing, and regression testing. The second is that it needs to be reviewed by a maintainer and a reviewer. The third is that it needs to pass the developer certificate of origin, or DCO, check as the Milvus project is part of the LFAI Foundation.
What made the project team start using Mergify in the first place?
We wanted a bot to merge PRs after passing tests. That’s how we ended up using Mergify as it can merge them automatically.
Which Mergify features do you use the most?
Without a doubt, the most used function is labeling. We label a PR “dco-passed” or “needs-dco” to indicate whether the DCO check passed or not. And we add or remove the “ci-passed” label as appropriate. Some tests can be re-run, so a PR can pass and then fail. Because we have many types of changes—document changes, C++ code changes, or Go code changes, for instance—and some of them just need to have part of the tests run, we have many rules about labeling if a PR passes or not.
What is your favorite Mergify feature and why?
It has to be the automatic merge. It keeps our codes up to date and the process is asynchronous—the author creates a PR, tests run automatically, some people review the changes, and the bot merges it into the master branch.
What would you say is the most underestimated Mergify feature and why?
Probably the backports feature. We have the need but haven’t used it yet. We maintain multiple versions of Milvus, so when we fix a bug in one branch we need to cherrypick it to another branch. We have done this a lot. If we’d used the backports feature, this work could have been done by a bot!
What has been the biggest impact of using Mergify on your team’s performance so far?
It has allowed us to automate our development process! This was especially noticeable early on in the project because we spent all our time developing the core function at that time.
What would be your n°1 tip for someone new to Mergify?
Try the automatic merge!
When you finish the configuration of auto-merge, you will have an extra team member who will merge all the finished code for you.
If you had time to contribute to the Mergify project, what would your contribution be about?
It would be helpful for us to have Mergify connected to the messaging app WeChat to inform people when a PR has been merged.