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. ⬇️