In a pull request, what is a required check, and what happens if it never reports a result?
answer
- not the red X — the silence
- what does no result mean
- the merge rule names it
- absence treated as denial
basics
~20 sA required check must report a passing result before the pull request may merge. An advisory check only posts a result nobody consults. If a required check never reports, the merge stays blocked rather than allowed.
solid answer
~50 sA pull request collects results posted against its commit — builds, tests, policy evaluations — each with a name and a state. A required check is one the merge rule names by that exact name: the merge is permitted only when a passing result for it exists on that commit. An advisory check runs and posts a result that no merge rule reads. The difference that matters is not the red X, it is silence. If an advisory check stops running, the pull request page looks exactly the same as one where it ran clean, so nobody notices. If a required check stops running, the pull request sits unmergeable, which is the fail-closed behaviour you want. So `required` is really a statement that the absence of a decision is treated as a denial, not as a pass.
go deeper
Be ready to say plainly that a required check must post a pass before merge, an advisory one only informs, and that a required check with no result blocks rather than allows.
Explain that the requirement is bound to a result name on a commit, so a renamed or untriggered job changes what the merge rule sees, and that some platforms count skipped as satisfied.
Show the operational instinct: you audit which checks are actually required, keep names stable, and make evaluation errors report failure so silence never reads as approval.
Own the framing that required-versus-advisory decides whose inaction is fatal, and that a rule believed required but in fact advisory is worse than no rule, because it buys false assurance.
## What a check actually is A pull request accumulates **checks**: results posted against the head commit by whatever ran — a build, a test suite, a linter, a policy evaluation. Each result carries a *name*, a *state* (passing, failing, or something neutral such as skipped or cancelled), and usually a link to logs. The platform's merge rules then decide what to do with those results, and that is where "required" and "advisory" part company. ## Required A **required** check is one the merge rule names. Merging is permitted only when a result with that exact name exists for that commit *and* it is a pass. The default state when nothing has reported is not "allow", it is "not yet": the pull request sits pending. That property — not the visible red X — is the real value of a required check. **It fails closed on silence.** ## Advisory An **advisory** check runs and posts a result that nothing consults. A human may look at it. On a pull request with fourteen checks and a release deadline, usually nobody does. ## Why the distinction is the whole point The interesting failure of a policy gate is rarely a denial someone argued with. It is the check that **quietly did not run at all** — the job whose trigger conditions no longer matched, the step that was commented out during the same change, the workflow that was renamed. For an advisory check that outcome is indistinguishable from success: the page shows no red, and no reader can tell "evaluated and clean" from "never evaluated". Work it through with a concrete rule: a new datastore must be provisioned with at least thirty days of backup retention. A pull request adds an `orders-db` with three days. - **Advisory:** the pull request merges. There is a red mark nobody blocked on. The gap is discovered by whoever eventually needs a two-week-old backup. - **Required:** the merge is held until the value is raised, or until someone overrides through a path that leaves a record. Same rule, same evaluation, same denial — completely different authority. ## Two subtleties worth being able to state **1. The requirement binds to a NAME, not to a job.** The merge rule says "a passing result called `policy/retention` must exist". If a change renames the job that produces it, the required name never reports and the pull request stays pending. That is the fail-closed outcome and it is correct. But be careful: some platforms treat a *skipped* result as satisfying the requirement, precisely so that path-filtered pipelines do not wedge every pull request in the repository. That convenience quietly converts "did not run" into "passed". Know which behaviour yours has before you claim a check cannot be skipped. **2. Advisory is a legitimate choice and a dangerous accident.** Running a brand-new rule in advisory mode first, to see what it would have blocked, is good practice. What you must never have is a rule you *believe* is required and which is in fact advisory — or one that was required until the naming drifted. "Advisory on purpose" and "advisory by accident" look identical on the pull request page and completely different in a review of your controls. ## Practical guidance - Keep the list of required check names small, explicit and reviewable; it is the part of your enforcement that is actually load-bearing. - Treat a check name as an interface. Renaming it is a change to enforcement, not a cosmetic edit. - Make an evaluation **error** report a failing state rather than no state at all — an exception that produces no result is the same hole as a job that never ran. - Prefer a gate that emits a decision for *every* change over one that emits a decision only when its trigger conditions happen to match. ## The wrong answer The answer to avoid is "a required check blocks when it fails, an advisory one doesn't". That is true but shallow, and it misses the case that actually bites: no result at all. A candidate who says "if nothing reported, there's nothing failing, so it merges" has described the exact defect that lets a bad change through with a green-looking page.
- A pull request renames the job that produces a required check. Does it merge?Not on a platform that binds the requirement to the result name: the old name never reports, so the pull request sits pending and stays unmergeable. That is the fail-closed outcome. The caveat is platforms that count a skipped result as satisfying the requirement — there, a job that no longer matches its trigger can report skipped and let the merge through.
- When is it right to run a policy check as advisory rather than required?When the rule is new and you do not yet know its false-positive rate or how much existing work it would block. Advisory lets you measure the blast radius before you take the merge button away from people. The discipline is to timebox it and write down when it becomes required; an advisory check nobody ever promotes is a rule that does not exist.
- Your gate throws an exception mid-evaluation. What should the pull request see?A failing result, explicitly. An evaluation error is not an approval, and it must not simply produce no result at all — that is indistinguishable from the check never running. Report error as a distinct failing state with a message saying the rule could not be evaluated, so the reader knows the difference between "you violated this" and "we could not tell".
A required check is a locked turnstile: no valid ticket, no entry, and an empty hand does not count as a ticket. An advisory check is a sign on the wall next to it.
saying these in an interview costs you the question
- Says a required check that never runs simply passes
- Treats a green pull-request page as proof the gate ran
- Thinks required and advisory differ only in failure handling
- Assumes renaming a job keeps its requirement attached
- Lets an evaluation error produce no result at all