Required GitHub checks: verify what ran before accepting an agent PR

A mergeable check does not answer whether the tests ran

Before accepting an agent's claim that tests passed, open the check behind the badge. GitHub documents successful, skipped and neutral outcomes as acceptable for required status checks. It also says a job skipped by a condition reports Success and does not itself prevent merging, even if that check is required. That is documented behavior, not evidence that the intended test command executed.[1][2][3]

A pull request (PR) proposes a code change. Continuous integration (CI) runs automated work against code revisions. In GitHub Actions, a workflow defines that automation, a job groups steps, and a step may run tests. A check reports a result; an external service can also publish a commit status. The check's producer is the app or integration reporting it. A familiar check name is not enough to identify the underlying work.[1]

Use the procedure below to answer one bounded question: did the intended tests execute successfully for the revision this PR requires? A positive answer supports that execution claim only. It does not establish test coverage, code safety, reviewer approval or permission to merge.

Trace the requirement to the test evidence

Start with the PR, its target branch, the intended test suite and authorized read access to check details and logs. Ask the repository administrator for the applicable requirement if you cannot inspect it. Do not infer settings from another repository or weaken a protection to finish this check.

• Identify the actual requirement. Record the check name, whether it is a check or commit status, and any expected GitHub App. Compare the observed producer with that requirement. GitHub allows a specific expected app; when any source is allowed, the name alone still does not establish the producer. Duplicate job names across workflows can make results ambiguous. If a check and commit status share a required name, both must pass.[1][2]
• Select the applicable revision from the PR status-check box. A commit SHA is the identifier for a particular code revision. The head is the latest commit on the PR branch; the test merge commit combines the PR head with the base branch for GitHub's evaluation. GitHub's troubleshooting rule says that when the test merge commit has a status, that commit must pass; otherwise the head must pass. Record the full applicable SHA and keep the two identities separate. An older passing commit does not satisfy the latest requirement.[1][2]
• Follow that check to its workflow run and exact attempt, then the relevant job. Record the workflow identity and revision, triggering event, run/attempt and job link or identifier. Establish which commit the check reports on. Inspect the workflow and checkout/test inputs to verify the code under test against the applicable SHA; keep the workflow definition's revision distinct from the tested code. Do not assume every green run concerns this PR.
• Read the decisive test step, not only the job conclusion. Confirm that the intended suite ran, what its result means, and the supporting log or test-report passage. Check the job condition and upstream dependencies when the step or job is absent. A lint result does not prove integration tests ran, and a successful job containing other work does not supply missing test evidence.
• Write a bounded decision. Accept the named execution claim only when its identity, revision and test evidence match. Otherwise record HOLD with the missing evidence, a repair owner and the next verification. When a team intentionally excludes a suite under its reviewed policy, record that exclusion as NOT RUN rather than calling the tests passed.

The run-to-step record and HOLD rule are our proposed evidence standard. Keep the repository/PR and target branch, required and observed producer, full applicable SHA, workflow/event, exact run attempt/job, decisive test evidence and decision together in the review record. Preserve authorized evidence references without copying secrets or private logs into public comments.

Distinguish the cases before choosing a repair

For dependent jobs, GitHub recommends always() with needs so a required downstream job can run despite an upstream failure. That addresses whether the downstream job runs. It does not, by itself, assert that upstream tests succeeded. If a final job aggregates results, its reviewed logic must evaluate the relevant outcomes and report failure when the team's test policy requires it. Do not treat adding always() alone as a completed repair.[2][4]

A completed fictional decision: lint passed, integration tests did not run

This teaching case is fictional and unexecuted. The labels Head-H and Merge-M are symbolic revisions, not real SHAs or lookupable records. A real review must retain full SHAs and actual evidence links.

An agent-authored PR changes application code and targets main. In this scenario, the team's reviewed policy requires integration tests for that change. The requirement is the integration-test check from GitHub Actions. The PR status box identifies test merge revision Merge-M as applicable, combining Head-H with the base branch.

In the fictional run for Merge-M, lint executed successfully, but the integration-test job was skipped by its condition. There is no integration-test step execution to cite. The completed decision is HOLD for the claim that integration tests passed. Lint remains a valid lint result; it cannot substitute for the missing suite. This scenario illustrates GitHub's documented conditional-skip behavior, not an observed repository incident.[3]

The fictional CI maintainer owns review of the condition and an authorized correction consistent with the team's coverage policy. The next check is to re-establish the applicable revision, match its required check and producer to the exact run attempt, and inspect the integration-test step and result. If the applicable revision has changed, evidence for Merge-M cannot close the new claim. No rerun, correction or successful outcome is being asserted here.

If a green run still does not satisfy the requirement

Check the event as well as the SHA. GitHub's current troubleshooting page says checks from a workflow_dispatch run on the PR head branch do not appear in the PR checks section or satisfy a branch-ruleset required check, even if they pass. That event restriction is for workflow-job checks, not checks created by an external GitHub App. A manual green run is therefore not a universal repair. Ask the CI maintainer to verify an eligible event appropriate for the workflow; do not switch to a privileged event merely to obtain an accepted check.[2]

If the error names an unexpected app, have the repository administrator verify the required and observed producer. If names collide, have the CI maintainer distinguish the workflows and check/status identities through normal reviewed configuration work. Neither problem is resolved by finding an unrelated green badge.[1][2]

If the repository uses a merge queue, this ordinary PR procedure is not the whole check. GitHub requires the separate merge_group event as an additional trigger for required Actions checks in that queue. The CI owner must verify the queue-specific execution too; an ordinary PR pass alone does not complete that procedure.[2]

Close the execution claim, not the entire review

A useful review conclusion names the suite, applicable revision and decisive execution evidence, or records a specific hold with its repair owner. Keep GitHub's merge-eligibility result separate from that conclusion. Even verified execution leaves open whether the tests covered the change and whether the PR meets the team's other acceptance requirements.

This guide interprets current official documentation, not a measured CI experiment or a new feature announcement. It does not verify your account's enforcement, repository configuration or GitHub Enterprise Server version. Recheck the linked documentation and actual repository requirement when applying the procedure.