Monorepo CI skips tests for packages that depend on your change: build the graph, then handle required checks

Why a path filter is not enough

The simplest way to stop building everything is a path filter on the workflow: run it only if files in this folder changed. That has two flaws. A filter looks only at the files that changed, so a change to a shared package does not match the folder of the application that depends on it, and the application's tests are skipped while its behaviour may have changed. And on GitHub, a workflow skipped by path filtering leaves its checks pending, so if those checks are required, the pull request cannot merge even though nothing was wrong. Filters also are not evaluated for tag pushes, so a release tag may run differently from the change that preceded it.

Graph-based detection and how it fails

Workspace tools solve the first flaw by deriving a dependency graph from the packages' own manifests: find the packages that own the changed files, then add everything that depends on them. Turborepo offers an affected flag that compares the current branch with a base; Nx computes affected projects between a base and a head. Both fail in the same quiet way: if the checkout is shallow, there is no base to compare with, and the tools treat every package as changed. That is safe but makes the whole exercise pointless, and it looks like the tool is not working. Fetching full history in the pipeline fixes it.

Dependencies must be declared. If a package imports another through a relative path instead of a declared dependency, the graph cannot see it and a change will be missed. Vercel's built-in skipping has the same requirement, with unique package names and explicit dependencies between packages. Lockfile changes are handled conservatively by default: a changed lockfile can mark every project affected, and Nx can be configured to diff the lockfile so only the packages whose dependencies changed are affected.

• Missing history makes everything look changed.
• Undeclared dependencies are invisible to the graph.
• Lockfile changes are global unless configured otherwise.

Five changes to test before you trust it

Choose five synthetic changes and write down which jobs should run for each: a documentation edit, a change in one leaf package, a change in a shared package, a change to the lockfile and a change to root configuration. Run each on a branch and compare the jobs that ran with the list. A documentation edit should run none of the package builds or a minimal set. A shared-package change should run every dependant. The lockfile and root configuration changes should run what you decided, and the default branch should always run everything, so that a missed dependant is caught before release rather than never.

Keep a required check reporting

Make the required check a single summary job that always runs. It waits for the jobs that were supposed to run, passes if they passed or were legitimately skipped, and fails if a job that should have run did not run or failed. Required settings then point at the summary rather than at individual jobs that may be skipped. The branch-protection change itself belongs to your maintainer.

How the paid outcome is accepted

The fixed job covers one monorepo and one CI system. It is accepted when each of the five agreed test changes runs exactly the expected jobs, a documentation-only pull request can merge without waiting on skipped jobs, a push to the default branch runs every package, and before-and-after durations are recorded for each test change. No time saving is promised, because it depends on the shape of each change. It starts at £795, untested, and is paid after you sign off.