Announcing our Monorepo Feature: Partition Rules
Monorepos have become increasingly popular in recent years as they provide a centralized place for storing code for multiple projects or services. However, managing a monorepo can be challenging, especially when it comes to merging pull requests. This is where our merge queue and its partition rules feature come in handy.
What Are Partition Rules?
Partition rules allow you to split your repository into smaller, more manageable parts called partitions. Each partition can run its own queue in parallel with other partitions. Partitions are independent of each other, meaning that changes queued into one partition will not affect the others.
How Does This Work?
When a pull request is submitted to the monorepo, it can be queued into one or multiple partitions simultaneously. Each partition can represent a subproject inside your monorepo and splitting your repository into partition can be done based on any criteria: folders and files modified, impacted service, programming language, CI run, or even the pull request author if you wished.
Mergify will wait for the pull request to be validated in each partition before it can be merged. This allows the different partitions to work together to ensure that the pull request meets all the necessary criteria for each partition.
If a pull request is queued in several partitions and the queue checks fail in at least one partition, the pull request will be reported as not mergeable. To be merged, the pull request needs to fulfill all the requirements of all the partitions it is queued in.
Partition rules can also be used to handle different projects in a monorepo that have different criteria for merging pull requests. This can be achieved by replicating the partition rules logic inside the queue rules merge_conditions
and by using the attribute queue-partition-name
.
A partition rule takes the following parameters:
Use Case
If a pull request contains a modification on any file in the folder projectA/
it will be added to the partition projectA
, if it contains a modification on any file in the folder projectB/
then it will be added to the partition projectB
, if it contains a modification in both folder projectA/
and projectB/
, then it will be added to both partitions.
If none of the two partition's rules matches, then the pull request will be added to both partitions. The queue_rules
determines in which queue in the partition(s) the pull request will be added.
Here is a table representing the partition and queues with the code below:
projectA | projectB |
---|---|
hotfix | hotfix |
default | default |
shared:
priority_rules: &priority_rules
- name: hotfix PR detected
conditions:
- label=hotfix
priority: high
- name: lowprio PR detected
conditions:
- author=dependabot[bot]
priority: low
pull_request_rules:
- name: queue PR with queue label
conditions:
- label=queue
actions:
queue:
partition_rules:
- name: projectA
conditions:
- files~=^projectA/
- name: projectB
conditions:
- files~=^projectB/
queue_rules:
- name: hotfix
priority_rules: *priority_rules
routing_conditions:
- label=hotfix
merge_conditions:
- or:
- and:
- queue-partition-name=projectA
- check-success=ciA
- and:
- queue-partition-name=projectB
- check-success=ciB
- name: default
priority_rules: *priority_rules
merge_conditions:
- or:
- and:
- queue-partition-name=projectA
- check-success=ciA
- and:
- queue-partition-name=projectB
- check-success=ciB
Conclusion
If you're managing a monorepo and struggling to keep track of pull requests, consider using Mergify's partition rules feature. They provide an effective way to manage multiple projects or services in a monorepo and can help to streamline the process of merging pull requests.
With partition rules, you can ensure that each project or service is validated independently before it is merged into the main branch, helping to keep your codebase stable and your development process running smoothly.
Don't hesitate to check out the feature documentation to know more. ⬇️