Description
If a workflow runs on pull_request and also on a push with no branch filter, every required context appears twice on a PR head: once from the push suite and once from the pull_request suite. The merge gate then resolves each required name to whichever of the two runs it finds (kindspec/rowspec#43). The audit reads only the pull_request trigger, so it passes this case.
Reproduction. Before kindspec/kindkit#26, kindkit's main had on: [push, pull_request]. On kindkit#25's head 79d194a, this command:
gh api repos/kindspec/kindkit/commits/79d194a/check-runs --jq '.check_runs[]|"\(.name)\t\(.check_suite.id)"'
lists check and kind / conformance under both suite 102179455195 (push) and suite 102179470311 (pull_request). Even so, the audit reported 0 finding(s) and exited 0.
Offline: a snapshot whose workflow is on: [push, pull_request] with a single job check, where check is required, also evaluates to exit 0.
Proposed finding. No collection change is needed, because every snapshot already stores the workflow text verbatim. Flag it when a workflow produces a required context on pull_request and its push trigger admits some branch other than the default one. That covers:
- no
branchesfilter; - a
branches-ignorethat does not exclude every non-default branch; branchespatterns that match anything besides the default branch.
A tags-only push does not count. The rule must also apply to expanded called-workflow contexts. It needs a red case for each form, plus mutants.
kindkit#26 has fixed the live instance. This issue is about the audit catching the next one.
Refs #3
Activity
docs(state): record that the required-checks audit passes on the org
ci: run the required-checks audit daily (#12)
feat: flag a required check that push also produces on a pr branch (#17)
feat: flag a required check that another workflow produces on push (#19)