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 partition rules feature comes 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
A partition rule takes the following parameters:
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
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:
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
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. ⬇️