Once the surviving checks are required, a check that never reports is not a red
tick. It is a pull request that cannot merge and gives no reason, and it reads as
a slow check rather than as a misconfiguration, so the first response is to wait
and the second is to remove the check from the required set.
The set is assembled from the names a completed run reported, which settles what
the contexts are called and settles nothing about whether they arrive. Those are
different questions and only the first one has an issue.
Three cases produce a context that never arrives, and each is already reachable
in this repository rather than hypothetical.
A workflow that only triggers on some pull requests. A path filter added later so
a documentation change does not spend a build is the ordinary way this happens,
and the pull request it skips is then unmergeable while every tab looks healthy.
The rule to land is that a workflow in the required set runs on every pull request
and decides internally whether it has work to do, so the context always arrives
and sometimes arrives green having done nothing. It says which of the two it was.
A pull request from a fork. The token there is read-only, and one workflow already
in this tree skips its upload on that route while keeping its gate step, which is
the right shape and is also the shape that is easy to get wrong in the other
direction. A required context that cannot be produced from a fork closes this
board to contributions from anybody who cannot push a branch to it.
A job skipped by a condition. A conditional job reports nothing at all rather than
reporting success, which is the same outcome as the path filter by a different
route.
Do the walk rather than reason about it. Open a pull request that touches one
documentation file, open one from a fork, and compare the contexts that arrive
against the required set. The comparison is the deliverable, and the repair is
either a workflow that always runs or a context that is not required.
The place to write the result is the parity document, next to the required set
itself, because a reader asking what stands behind a merge should not have to find
out separately that one of the entries only shows up on some changes.
Done when a pull request touching only a documentation file reports every context
in the required set, a pull request opened from a fork reports every context in
the required set or that context is not required with the reason written in the
parity document, no workflow whose context is required carries a path filter or a
job-level condition that can skip it, and every one of those jobs prints whether
it had work to do.
Once the surviving checks are required, a check that never reports is not a red
tick. It is a pull request that cannot merge and gives no reason, and it reads as
a slow check rather than as a misconfiguration, so the first response is to wait
and the second is to remove the check from the required set.
The set is assembled from the names a completed run reported, which settles what
the contexts are called and settles nothing about whether they arrive. Those are
different questions and only the first one has an issue.
Three cases produce a context that never arrives, and each is already reachable
in this repository rather than hypothetical.
A workflow that only triggers on some pull requests. A path filter added later so
a documentation change does not spend a build is the ordinary way this happens,
and the pull request it skips is then unmergeable while every tab looks healthy.
The rule to land is that a workflow in the required set runs on every pull request
and decides internally whether it has work to do, so the context always arrives
and sometimes arrives green having done nothing. It says which of the two it was.
A pull request from a fork. The token there is read-only, and one workflow already
in this tree skips its upload on that route while keeping its gate step, which is
the right shape and is also the shape that is easy to get wrong in the other
direction. A required context that cannot be produced from a fork closes this
board to contributions from anybody who cannot push a branch to it.
A job skipped by a condition. A conditional job reports nothing at all rather than
reporting success, which is the same outcome as the path filter by a different
route.
Do the walk rather than reason about it. Open a pull request that touches one
documentation file, open one from a fork, and compare the contexts that arrive
against the required set. The comparison is the deliverable, and the repair is
either a workflow that always runs or a context that is not required.
The place to write the result is the parity document, next to the required set
itself, because a reader asking what stands behind a merge should not have to find
out separately that one of the entries only shows up on some changes.
Done when a pull request touching only a documentation file reports every context
in the required set, a pull request opened from a fork reports every context in
the required set or that context is not required with the reason written in the
parity document, no workflow whose context is required carries a path filter or a
job-level condition that can skip it, and every one of those jobs prints whether
it had work to do.