|
| 1 | +--- |
| 2 | +title: Monorepo CI |
| 3 | +description: Run the right tests for the right pull requests by combining scopes with your CI system. |
| 4 | +--- |
| 5 | + |
| 6 | +Monorepos supercharge collaboration, but they also make continuous integration |
| 7 | +expensive. Every change potentially touches hundreds of packages or services, |
| 8 | +and running the full test matrix for all of them at every pull request update |
| 9 | +quickly becomes unsustainable. |
| 10 | + |
| 11 | +Mergify Monorepo CI brings precision testing to your existing CI pipelines by |
| 12 | +tagging each pull request with **scopes**. Scopes are named slices of your |
| 13 | +repository that describe a service, package, or set of files (see |
| 14 | +[Merge Queue Scopes](/merge-queue/scopes) for the full specification). A scope acts as |
| 15 | +the contract between your codebase and your CI: if a pull request touches files |
| 16 | +that belong to the `frontend` scope, every workflow that cares about that scope |
| 17 | +knows it has work to do. |
| 18 | + |
| 19 | +With scopes in place you can: |
| 20 | + |
| 21 | +- Detect which projects or services are really impacted by a change. |
| 22 | +- Run only the CI jobs that matter for those scopes. |
| 23 | +- Reuse those scopes later in the merge queue to build smarter batches. |
| 24 | + |
| 25 | +Today, GitHub Actions is the first CI platform with native support through our |
| 26 | +[`gha-mergify-ci`](https://github.com/Mergifyio/gha-mergify-ci) action. |
| 27 | + |
| 28 | +## How it works |
| 29 | + |
| 30 | +```dot class="graph" |
| 31 | +strict digraph { |
| 32 | + fontname="sans-serif"; |
| 33 | + rankdir="LR"; |
| 34 | + nodesep=0.9; |
| 35 | + ranksep=1.1; |
| 36 | + splines=polyline; |
| 37 | +
|
| 38 | + node [shape=box, style="rounded,filled", fontname="sans-serif", margin="0.35,0.2", color="#165B33", fillcolor="#347D39", fontcolor="white"]; |
| 39 | + edge [fontname="sans-serif", color="#374151", penwidth=1.2, arrowhead=normal]; |
| 40 | +
|
| 41 | + subgraph cluster_repo { |
| 42 | + label="Repository"; |
| 43 | + style="rounded"; |
| 44 | + color="#1CB893"; |
| 45 | + fontcolor="#063C2C"; |
| 46 | +
|
| 47 | + PR [label="Pull request\nchanges"]; |
| 48 | + ScopesConfig [fillcolor="#1CB893", fontcolor="#063C2C", color="#0B7A5C", margin="0.4,0.2", label="Scopes config\n(.mergify.yml)"]; |
| 49 | + } |
| 50 | +
|
| 51 | + Detect [fillcolor="#2563EB", color="#1E40AF", label="gha-mergify-ci\n(scopes)"]; |
| 52 | +
|
| 53 | + subgraph cluster_ci { |
| 54 | + label="GitHub Actions jobs"; |
| 55 | + style="rounded"; |
| 56 | + color="#1CB893"; |
| 57 | + fontcolor="#063C2C"; |
| 58 | +
|
| 59 | + Frontend [label="Frontend tests"]; |
| 60 | + API [fillcolor="#6B7280", color="#4B5563", label="API tests\n(skipped)"]; |
| 61 | + Docs [fillcolor="#347D39", color="#165B33", label="Docs checks"]; |
| 62 | + } |
| 63 | +
|
| 64 | + Queue [fillcolor="#111827", color="#0B1120", label="Merge Queue\n(optional reuse)"]; |
| 65 | +
|
| 66 | + PR -> Detect; |
| 67 | + ScopesConfig -> Detect; |
| 68 | + Detect -> Frontend [label="scope: frontend"]; |
| 69 | + Detect -> Docs [label="scope: docs"]; |
| 70 | + Detect -> Queue [style=dashed, color="#9CA3AF", fontcolor="#9CA3AF"]; |
| 71 | +} |
| 72 | +``` |
| 73 | + |
| 74 | +1. **Define scopes** in your `.mergify.yml` file by mapping the areas of your repository (via file |
| 75 | + patterns) to scope names that matter for your CI. |
| 76 | + |
| 77 | +2. **Collect scopes in CI.** A helper (currently |
| 78 | + [`gha-mergify-ci`](https://github.com/Mergifyio/gha-mergify-ci)) inspects the |
| 79 | + pull request diff and dispatches only the jobs whose scopes are touched. |
| 80 | + |
| 81 | +3. **Drive your jobs conditionally.** Use the reported scopes to decide which |
| 82 | + workflows, test suites, or deployment steps should run for the current pull |
| 83 | + request. |
| 84 | + |
| 85 | +4. **(Optional) Share scopes with Merge Queue.** The very same scopes help the merge queue build |
| 86 | + batches that group related pull requests, reuse your CI runs, and unlock advanced strategies like |
| 87 | + [batch merging](/merge-queue/batches) or [two-step CI](/merge-queue/two-step). |
| 88 | + |
| 89 | +## What you can do with Monorepo CI |
| 90 | + |
| 91 | +- Gate language-specific test suites with fine-grained scope checks. |
| 92 | +- Trigger targeted build pipelines for individual services or packages. |
| 93 | +- Run nightly or specialized workflows only when relevant scopes change. |
| 94 | + |
| 95 | +## Get started |
| 96 | + |
| 97 | +Define your scopes first so every workflow speaks the same language: |
| 98 | + |
| 99 | +1. List the services, packages, or domains that deserve their own scope. |
| 100 | + |
| 101 | +2. Map each scope to file patterns inside the |
| 102 | + [`scopes`](/merge-queue/scopes#configuration) block of your `.mergify.yml` |
| 103 | + file. |
| 104 | + |
| 105 | +3. Commit the configuration and open a pull request to verify that the reported |
| 106 | + scopes match your expectations. |
| 107 | + |
| 108 | +Once those scopes exist, pick the workflow that matches your setup: |
| 109 | + |
| 110 | +- [GitHub Actions setup](/monorepo-ci/github-actions) |
| 111 | +- [Monorepo integrations for merge queue](/merge-queue/monorepo) |
| 112 | + |
| 113 | +Looking for a different CI provider? [Let us know ](mailto:[email protected]); more platforms are on our roadmap. |
0 commit comments