APIs are everywhere. They became ubiquitous over the last years and every startup building a product is now ordered to offer them. They became a major selling point for any SaaS business. Engineering and product teams focus on the design of their API, from top to bottom, making sure they
As you may guess, Mergify relies a lot on third-party APIs like the Stripe API [https://stripe.com/docs/api] or the GitHub API [https://docs.github.com/en/rest] and their behavior. Like any third-party service, we need to deal with many things to ensure our integration never breaks.
It's not a secret that we are fans of Redis. We've been leveraging it since day one at Mergify to store various volatile data. It's fast, robust, and easily scalable. Six months ago, we introduced speculative checks [https://blog.mergify.com/announcing-speculative-merge-queues/] support for our merge queue. We chose a
If this title does not ring a bell, you might need to read first what a merge queue is, what problem speculative checks solve, and how mixing speculative checks and batching can save you a lot of time. Go ahead. We'll wait. Now that you have an idea of what
In every engineering team, developers want to see their "ready to merge" work landing as soon as possible into their source code repository. Nobody wants to wait, and this directly impacts the velocity of the team. The worst part of the merging process would be to have to revert a
Today, we are pleased to announce the general availability of the Mergify API. This has been one of our focuses over the last months, as it has been one of the most requested features from our beloved users. We are thrilled to release it and are eager to add more
When Mergify started to automate pull request merges, users expressed rapidly the need for having a way to keep their pull requests updated. We soon introduced the strict mode [https://docs.mergify.com/actions/merge/#strict-merge] for the merge action, offering pull request merge serialization. This was our first, very
A year ago, we wrote about our workload issues [https://blog.mergify.io/handling-300k-github-events-per-day/] and how we were handling 300k GitHub events per day. Our main challenge was avoiding GitHub rate limit and quota system while delivering service with low latency and high throughput. Earlier this year we noticed more
Last month, we announced [https://blog.mergify.com/announcing-time-based-conditions/] a new set of conditions for Mergify rules based on time. You can now use a time and date and compare pull request attributes to dates and times. We had the idea for this feature since the beginning of Mergify, but
Today, we're happy to announce the general availability of one of our most awaited features. Expressing conditions to act upon is the core of Mergify rules. While many dimensions are exposed through our configuration file and allow us to filter on many pull request attributes, one important was missing. Time.
Over the years, Mergify users wish they could be more expressive in the way they write their pull request rules. As those rules are a combination of conditions, being able to use or and and operators inside those expressions is a must-have. We are pleased to announce that this long-awaited
Consuming API in React sounds straightforward. Fetching data can be resumed by using the `fetch` function and getting back the value. Using this simple approach would be fine if everything always worked as intended. However, fetching data is way more than retrieving some value. You have to deal with unexpected