Optimizing Monorepos with Rush and Mergify

How to leverage your Rush monorepo with Mergify.


Rush is a renowned open-source build orchestrator facilitating the handling, building, and publishing of multiple packages within a single Git monorepository (monorepo). Rush efficiently breaks up large applications into manageable pieces, each with its lifecycle and build processes. In a Rush-enabled monorepo, Mergify enhances the development workflow by automating merges, implementing project-specific merge queues, and adapting workflows to each sub-project’s unique requirements.

Mergify’s merge queue comes furnished with exclusive features, especially designed for managing high velocity, large-scale monorepo projects. These features enable:

  • Independent management of each sub-project;
  • Uninterrupted and parallel development cycles for each sub-project;
  • Adaptation to each project’s unique processes and CI checks.

Partition rules are Mergify’s solution to monorepo management complexities. Each partition operates in parallel and encompasses all the queues defined in the queue_rules. They function independently, allowing multiple sub-projects to coexist, each running their merge cycles without interference from the others.

Integrating Rush Project Structure with Mergify

Section titled Integrating Rush Project Structure with Mergify

Implementing Partition-Based Merge Queues

Section titled Implementing Partition-Based Merge Queues

Once Rush has modularized your project, each sub-project or app can have its Mergify merge queue, automated according to its specific needs, CI checks, and development lifecycle.

Creating Partitions for Each Project

Section titled Creating Partitions for Each Project

To implement this, we define partitions for each sub-project using partition_rules in our Mergify configuration. Each partition can then have its specific queue_rules defining the merge conditions based on each sub-project’s requirements.

Here’s a simplified example where Rush has split a project into projectA, projectB, and projectC, and we create a partition and queue for each:

partition_rules:
  - name: projectA
    conditions:
      - files ~= ^apps/projectA

  - name: projectB
    conditions:
      - files ~= ^apps/projectB

  - name: projectC
    conditions:
      - files ~= ^apps/projectC

queue_rules:
  - name: default
    merge_conditions:
      - and:
        - or:
          - partition-name != projectA
          - check-success = ciA
        - or:
          - partition-name != projectB
          - check-success = ciB
        - or:
          - partition-name != projectC
          - check-success = ciC

In this configuration:

  • Pull requests modifying files in projectA will be managed by the projectA partition. Same for other projects.

  • If a pull request alters files in multiple projects, it will be processed in each corresponding partition independently.

Merging Mergify’s automation prowess with Rush’s monorepo management capabilities leads to a streamlined, efficient, and organized development workflow. It not only fosters parallel development but also ensures each sub-project retains its unique development rhythm, making monorepo management a breeze.