Hi HN, we’re Spriha and Ankit, founders of MergeQueue (<a href="https://mergequeue.com/" rel="nofollow">https://mergequeue.com/</a>). We enable automatic merges for your Github Pull Requests, based on configurable rules you can set for each repo. These automated merges ensure you never have failing builds on master/main and save time on rebasing your feature branches.<p>If you have a monorepo where a big engineering team is regularly merging changes, the stability of the main branch degrades considerably. This happens because more engineers working on the same codebase introduce incompatible changes, causing builds to break even though their commits pass independently. Here’s an example: <a href="https://blog.mergequeue.com/managing-github-merges-for-high-output-engineering/" rel="nofollow">https://blog.mergequeue.com/managing-github-merges-for-high-...</a>.<p>Github has a setting to restrict branches to be up to date before merging, but turning on that setting ends up forcing a rebase-athon within the team. This results in wasted time, and all too often, a stressful scramble to figure out what changes broke the build.<p>We had this problem in our previous company where we looked for a solution to automate the process. We found this paper [1] published by Uber to manage monorepos at scale and we built a lightweight version of that internally. It immediately eliminated the overhead of keeping builds healthy. After that, we decided to build a public version to save others from re-inventing the wheel.<p>We spoke to engineers at Airbnb, Stripe, Uber, Shopify, Quora and other large companies who have internally built similar tools, but teams who need such tools the most often don’t have the bandwidth to dedicate developers to building and maintaining them.<p>MergeQueue (MQ) is a FIFO queue of Pull Requests (PRs) that works as a Github app. To use MQ as a developer, instead of merging manually, you just add a Github Label “mergequeue” to the PR. MQ then takes care of the rest: it sequentially updates or rebases the branch, monitors the configured CI checks and eventually merges the changes. If the checks fail, it will dequeue the PR, add comments describing the reason and move to the next one. For high output teams, MQ also offers batch mode to run CI in parallel batches.
If you’d like to learn more, there’s a lot more here: <a href="https://mergequeue.com/documentation" rel="nofollow">https://mergequeue.com/documentation</a>.<p>Currently, we are also piloting a way to manage “flaky” (i.e. unreliable) tests through MQ. This integrates with your CI provider (we currently support CircleCI), analyses test results and flags the tests that fail inconsistently. When flaky tests are identified, MQ reruns the test depending on the configuration set.<p>We charge by usage in an organization, so for instance if your organization has 100 developers but only 20 of them use MQ, only those 20 will be billed. You can sign up for a free 14 day trial without a credit card. We also support single tenant or on-prem deployments, have webhooks to connect to your other apps, offer multi-queue support, and are SOC2 certified!<p>We’d love for you to try MergeQueue and give us any feedback you have. If you've used something similar in the past, we're also curious to learn what problems you faced so we're better prepared for them ourselves :)<p>[1] <a href="https://eng.uber.com/research/keeping-master-green-at-scale/" rel="nofollow">https://eng.uber.com/research/keeping-master-green-at-scale/</a> - discussed at the time: <i>Keeping master green at scale</i> - <a href="https://news.ycombinator.com/item?id=19692820" rel="nofollow">https://news.ycombinator.com/item?id=19692820</a> - April 2019 (115 comments)