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.
Why Mergify with Rush?
Section titled Why Mergify with Rush?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 MergifyImplementing Partition-Based Merge Queues
Section titled Implementing Partition-Based Merge QueuesOnce 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 ProjectTo 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.
Example Configuration
Section titled Example ConfigurationHere’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 theprojectA
partition. Same for other projects. -
If a pull request alters files in multiple projects, it will be processed in each corresponding partition independently.
Conclusion
Section titled ConclusionMerging 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.