Job monorepo-build-only-affected-packages · revised 11 October 2026
Make monorepo CI build and test only the packages a change affects
For five agreed test changes, only the packages that depend on the change run their jobs, required checks still report, and the default branch still runs everything.
You might be seeing
- A documentation edit starts every package's build and test jobs
- Someone added path filters, and now some pull requests are stuck waiting for a check that never runs
No passwords, keys, card details or admin invites needed to start.
What usually happened
The pipeline has no idea which package a change touches. Without a dependency graph and a reliable base commit it must build everything, or it uses path filters that miss packages which depend on the changed one and that leave required checks pending when their jobs are skipped. Shallow checkouts, lockfile changes and shared configuration each add cases that simple filters get wrong.
Who it’s for: A team whose single repository holds several packages or apps and whose CI builds and tests all of them for every change, so a one-line edit waits for the whole suite.
Usually starts when: Pipeline time has grown with the number of packages, and people have started merging without waiting or skipping checks to save time.
The result: For five agreed synthetic changes on test branches, the jobs that run are exactly the expected set: the changed package and its dependants, or none for a documentation-only change. Required checks still report so merges are not blocked, and a push to the default branch runs every package.
Check whether this job fits
Answer from how the repository and its pipeline are set up today.
What you get
- A pull request with the pipeline change and a short operator note
- A table of the five test changes, the expected jobs and the jobs that ran
- Run links for each test and for the default-branch run
- Before and after durations for each test change, with their limits
- Steps to revert the change
Included
- One monorepo with one package manager workspace and one CI system
- Map the package dependency graph and agree what counts as a global change, such as the lockfile or shared configuration
- Configure affected detection from a reliable base commit using the workspace tool you already have, or path and graph rules if none exists
- Make required checks report when jobs are skipped, so skipped work does not block merging
- Test five agreed changes on branches and a push to the default branch, and record the jobs that ran
Not included
- Restructuring the repository, moving packages or changing the package manager
- Setting up shared remote build caches or paid platform features
- Splitting slow tests across machines
- Changes to deploy steps or hosting settings
- A promised saving: the saving depends on the shape of each change
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each of the five agreed test changes, the set of jobs that run matches the expected set written in the agreed table, including none for a documentation-only change.
Evidence: The table of changes, expected jobs and actual jobs, with a run link for each.
A change to a shared package runs the jobs of every package that depends on it, and a change to a global file runs all packages.
Evidence: The run links and job lists for those two test changes.
On a documentation-only change, the required check reports a result and the pull request can merge without waiting on skipped jobs.
Evidence: The pull request's check list showing the summary check passed.
A push to the default branch runs every package's build and test jobs.
Evidence: The default-branch run link and its job list.
Sign-off. You inspect the table, the runs and the check list, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If a test change runs the wrong set of jobs or a required check blocks merging, you do not pay for this fixed scope. If the dependency graph cannot be derived or nearly everything is global, we explain it and stop.
When it fits, and when we stop
It fits when
- Packages declare their dependencies on each other in their own manifests
- CI can run on test branches without deploying
- The base commit for comparison is obtainable in CI, or the checkout can be changed so it is
- A maintainer can change the repository's required checks if needed
We stop and tell you if
- Packages depend on each other through undeclared paths, so no graph can be derived and the team will not declare them
- Nearly every change touches shared configuration, so almost everything is always affected
- Required checks are enforced by a policy that we cannot change and that blocks skipped jobs
What could go wrong
Before merge, closing the pull request leaves your pipeline unchanged. After merge, your maintainer can revert the commit and every change runs everything again, as before. A change to required checks is reversed by your maintainer using the note we supply.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A package is missed because a dependency is undeclared, so a broken change merges. | The graph is checked against the manifests, undeclared dependants are reported before work continues, and the default branch still runs everything. |
| A skipped required check blocks merging, or a stale pass is reused. | A single summary check always runs and fails if any needed job failed or did not run when it should have. |
| A shallow checkout makes every change look affected, hiding that the change did nothing. | The checkout is set to provide the base history, and a test change confirms the narrower set. |
An independent reviewer checks the expected and actual job sets, that a skipped job cannot let a broken package merge and that the default branch still builds everything. Your maintainer applies any branch-protection change and merges.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the packages, the global-change files, the five test changes and the required checks in writing
- Read the manifests and the pipeline, derive the dependency graph and note the checkout depth
- Configure affected detection from a reliable base commit, with global changes running everything
- Make the required checks report even when jobs are skipped, using a single summary check
- Run the five test changes on branches and a push to the default branch, and record the jobs that ran against the expected sets
- Have an independent reviewer compare the table with the runs and the diff, then hand over the pull request and revert steps
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Platform, runner and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If monorepo CI time creeps back up as packages are added, a monthly build-time budget can watch it.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Workspace tools can compute affected packages themselves. Turborepo documents an affected flag that compares against a base and treats everything as changed if the history is missing, and Nx documents affected commands with a base and head and a safe default for lockfile changes. turborepo.dev
- On GitHub, a workflow skipped by path filtering leaves its required checks pending, which blocks merging; the workflow syntax reference explains the filter rules. docs.github.com
Questions
Will this make every pull request faster?
No. A change to a shared package or a global file still runs many jobs. We record the before and after time for each test change and do not promise a saving.
Why not just add path filters?
Path filters miss packages that depend on the changed one and can leave required checks pending. A graph and a summary check avoid both.
Do you change our package layout?
No. If packages depend on each other through undeclared paths, your maintainers must declare them first.
Send an enquiry
Send us
- The workspace layout: how many packages and which tool defines them
- How CI is triggered today and whether path filters exist
- Which checks are required before merging
- Do not send credentials, source code or an access invitation in the first enquiry
Later, once you agree
- The repository's pipeline files and workspace manifests through an authorised company-controlled route
- The list of global-change files you agree, and the five test changes
- Approval for branch runs and for any change to the required checks
You own the repository, the CI account and branch protections. We work from authorised files on a branch through a company-controlled identity and change nothing in repository settings ourselves; your maintainer applies any required-check change. You merge the pull request.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “monorepo-build-only-affected-packages” as the subject.