What reading the workflows by hand gets you
For one workflow with one job, this is genuinely faster than pasting
anything into a page: open the file, read the job's name:
or its id, compare it to what Settings → Branches requires, done. It
stops scaling the moment a repository has more than a couple of
workflows, any matrix jobs, or a required-check list nobody has
re-audited since it was set up — which is precisely when drift is
most likely to have already happened.
What this checker does instead
Paste your required check names (from Settings → Branches, or
the branch-protection API's JSON) and one or more workflow files, and it
computes every job's current reported name — its name:
field if set, otherwise its job id, with matrix combinations expanded in
declared order — and flags every required name nothing can
currently satisfy. A dynamic matrix or a reusable-workflow call is
reported unverifiable rather than guessed at, so a result
never claims more certainty than the YAML actually gives it.
| Reading every workflow file by hand | This checker |
|---|---|
| Works for one workflow, one job. Scales badly across a dozen workflows and several matrix jobs, and has to be redone from scratch after every workflow edit. | Computes every job's current check name from the pasted YAML in one pass, matrix combinations included, every time you run it. |
A quick read checks the job's name: line and stops
there — which passes a workflow that dropped its
pull_request trigger, because the name is still
correct even though the job can never report on a pull request
again. |
Checks the trigger as well as the name, so a required check pointed at a push-only workflow is flagged the same as a renamed or removed job. |
| Guesses at a matrix job's reported name by eye, which is exactly the case most likely to be gotten wrong by hand (the appended combination text has to match GitHub's own ordering exactly). | Expands a static matrix in its declared order and reports a
dynamic one as unverifiable rather than a guess either
way could be wrong about. |
| Gives you no artifact to hand to a teammate or re-run after the next workflow change — the check lived in your head for as long as you were looking at the files. | Wires into CI with check.py --fail-on-stale, so a
newly-drifted required check is caught the moment it happens rather
than the next time someone happens to notice a stuck PR. |
Common questions
Why can't I just read the workflow files myself?
You can, and for one workflow with one job it is faster than pasting
anything anywhere. The problem is scale and drift: a repository with a
dozen workflows and matrix jobs across several of them means
re-deriving each job's current reported name (its name:
field if set, otherwise its job id, with matrix combinations appended)
from YAML, by eye, for
every job, every time you suspect drift — and doing it again
after every workflow edit, because nothing tells you when a rename
happened.
What does GitHub's own UI tell me when this happens?
Nothing useful. The pull request sits at "Expected — Waiting for status to be reported" indefinitely, with no message naming which required check is the problem or why. Settings → Branches shows you the required name you configured, but does not check it against what your workflows currently produce — that comparison is exactly what GitHub never runs for you.
Is reading the workflow by hand ever wrong, not just slow?
Yes, in the case that matters most: a workflow that dropped its
pull_request trigger. The job can have the exact right
name and pass every time it runs, and still never satisfy the required
check on a pull request, because it only runs on push. Reading the
job's name tells you nothing about its trigger, so a hand check that
only looks at name: lines can pass a workflow that is
actually broken for this purpose.
Does this tool check my branch protection settings for me?
No. It makes no network calls of any kind and never reads your repository or its settings. You paste the required check names and the workflow YAML yourself, and the comparison runs entirely in this page.
Nothing here says reading a workflow file is a bad habit — it is exactly the right tool for a quick, one-job check. This page describes the point where that habit stops scaling to a real branch-protection list.
Check your own workflows
Paste your required check names and workflow files and see every required check nothing can currently satisfy — the comparison a by-hand read has to redo from scratch every time.