Summary
Branch protection on main currently requires Acknowledgment Check, Related Issue Check, Semantic PR Title Check and CodeQL. It does not require the unit test workflow or dependency-review, so a pull request whose tests are red can still be merged — nothing stops it mechanically, only reviewer attention.
Making the existing contexts required isn't a straight fix. run-unit-tests fans out to 30 jobs (two Node.js versions across 13 workspaces, plus four more jobs), and required checks are listed by name, so pinning all 30 would silently change meaning every time a workspace or Node.js version is added or renamed.
Why is this needed?
The protection rule is the only thing that holds when attention lapses — a busy review day, an automated pull request, or a maintainer merging on a phone. Right now the most valuable signal we produce, the test suite, isn't part of it, so "the checks passed" is a convention rather than a guarantee.
It is also a prerequisite for #5491. Auto-merging even the most boring Dependabot updates means merging without a human reading the checks, and that is only safe once the test suite is part of the protection rule instead of advisory. The workflow for that is in #5568, which must not merge until the contexts described here are required.
Which area does this relate to?
Automation
Solution
Add one aggregate job to reusable-run-linting-check-and-unit-tests.yml that needs the five existing jobs and fails if any did not succeed, then require that single context plus dependency-review:
run-unit-tests / unit-tests-completedependency-review
Two details are easy to get wrong and worth stating:
- The aggregate job needs
if: always(), and must treat skipped as a failure alongside failure and cancelled. A skipped job reports its check run as skipped, and GitHub counts a skipped required check as satisfied — so an aggregate job that skipped when a dependency failed would green-light a broken pull request
pr-run-linting-check-and-unit-tests.yml triggers on [opened, synchronize] only. Without reopened, a reopened pull request never re-reports and would sit blocked forever on a context that can't arrive
dependency-review.yml needs no change: bare pull_request trigger, no paths: filter, so it always reports.
A context has to report at least once before it can be added to a protection rule, so the workflow change has to merge before the settings change.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Summary
Branch protection on
maincurrently requiresAcknowledgment Check,Related Issue Check,Semantic PR Title CheckandCodeQL. It does not require the unit test workflow ordependency-review, so a pull request whose tests are red can still be merged — nothing stops it mechanically, only reviewer attention.Making the existing contexts required isn't a straight fix.
run-unit-testsfans out to 30 jobs (two Node.js versions across 13 workspaces, plus four more jobs), and required checks are listed by name, so pinning all 30 would silently change meaning every time a workspace or Node.js version is added or renamed.Why is this needed?
The protection rule is the only thing that holds when attention lapses — a busy review day, an automated pull request, or a maintainer merging on a phone. Right now the most valuable signal we produce, the test suite, isn't part of it, so "the checks passed" is a convention rather than a guarantee.
It is also a prerequisite for #5491. Auto-merging even the most boring Dependabot updates means merging without a human reading the checks, and that is only safe once the test suite is part of the protection rule instead of advisory. The workflow for that is in #5568, which must not merge until the contexts described here are required.
Which area does this relate to?
Automation
Solution
Add one aggregate job to
reusable-run-linting-check-and-unit-tests.ymlthatneedsthe five existing jobs and fails if any did not succeed, then require that single context plusdependency-review:run-unit-tests / unit-tests-completedependency-reviewTwo details are easy to get wrong and worth stating:
if: always(), and must treatskippedas a failure alongsidefailureandcancelled. A skipped job reports its check run asskipped, and GitHub counts a skipped required check as satisfied — so an aggregate job that skipped when a dependency failed would green-light a broken pull requestpr-run-linting-check-and-unit-tests.ymltriggers on[opened, synchronize]only. Withoutreopened, a reopened pull request never re-reports and would sit blocked forever on a context that can't arrivedependency-review.ymlneeds no change: barepull_requesttrigger, nopaths:filter, so it always reports.A context has to report at least once before it can be added to a protection rule, so the workflow change has to merge before the settings change.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.