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 [https://blog.mergify.com/what-is-a-merge-queue/] is [https://blog.mergify.com/what-is-a-merge-queue/], what problem speculative checks [https://blog.mergify.com/announcing-speculative-merge-queues/] solve, and how mixing speculative checks and batching can save you a
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
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.
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