pr-verify: stop firing workflow_run runs that only skip (~426 a day)

Problem

pr-verify ran 902 times between 2026-10-19 17:30Z and 2026-10-20 ~17:30Z, all on workflow_run. 470 succeeded, 426 skipped, 4 failed and 2 were cancelled (count from the GitHub Support hub's run listing). Almost half the runs start only to skip. They use runner minutes and API budget, and they push pr-verify's daily run listing past 500 entries, which broke the lost-run reconciler's listing (#8685 and its follow-up).

Options

Narrow on.workflow_run.workflows or types in .github/workflows/pr-verify.yml so only the upstream completions that can lead to a judgment trigger a run.
Or move the job-level skip condition into the trigger where the event allows it.

Constraints

This is a trigger change to a lane workflow, so it needs Security & Cost's pass and the owner's merge.
Bundle it with the pending pr-require-checks label/edit trigger trim, per the GitHub Support hub.
Keep test(pr-pipeline): add the planted-defect replay harness for pr-verify #8681's parity test in step with any change to pr-verify.yml.

Acceptance

Skipped pr-verify runs drop to near zero per day.
Every PR head that pr-verify judges today still gets judged.

Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.

Size: Small
Complexity: Low
Uncertainty: Knowable
Flags: none
Blocked by: none

Decision recorded. The owner answered in the Issue Triage session (2026-10-25), accepting the recommended answers below:

go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

AND whatever is aligned with my overall goal of lowest friction, highest throughput (within our environmental, github, rate limit, etc. constraints)

[quote truncated; the full decision is at the link]

#8695 (comment)

This decision settles the open questions. The work is to add a branches-ignore filter (main, gh-readonly-queue/**) to pr-verify's workflow_run trigger. The job-level if and pr-require-checks' pull_request types stay as they are. A test should confirm feature-branch PR runs are still judged, and #8681's parity test must still pass. One point to check during the work: whether workflow_run honors branches-ignore against the triggering run's head branch, which the decision marks as unverified.

_{Automated triage, applied by the lanes App.}

Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.

To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.

Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).

The latest triage verdict holds nothing: the issue is at status: ready.

Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.

Intended outcome: Cut pr-verify's skip-only workflow_run runs by trimming the upstream pr-require-checks runs that cannot lead to a judgment, keeping the job-level filter and updating the parity test.

Dependencies

Bundled with the pending pr-require-checks label/edit trigger trim, per the issue
Needs Security & Cost's pass and the owner's merge, since it is a lane trigger change
Keep #8681's parity test in step with any change to pr-verify.yml

Related work

perf(ci): stop lane workflows from firing on events that do no work #8258 (related): Open perf issue on lane workflows firing on events that do no work; same theme, may cover the pr-require-checks trim.
ci: run the pr-verify package tests when pr-verify.yml changes #9640 (related): Merged PR that runs the pr-verify package tests when pr-verify.yml changes; applies to this edit.
fix(pr-pipeline): stop pr-merge's workflow_run wake-ups from overflowing its queue #7634 (related): Earlier merged fix for the same kind of problem, pr-merge workflow_run wake-ups.

Open questions

workflow_run takes only workflows, types and branch filters, so it cannot filter on the upstream event or conclusion. The skips come from the job-level if (conclusion success, event pull_request, same repo). Is it acceptable that the trigger itself cannot reach near zero skips and the cut comes only from upstream trims?
RECOMMENDED: Yes. Keep the job-level if as the safety net, trim upstream runs that cannot lead to a judgment, and restate the acceptance as a measured drop, for example under 50 skipped runs a day. Basis: .github/workflows/pr-verify.yml:39-43,64-68
Which upstream pr-require-checks runs should stop? It fires on dispatch, a twice-daily schedule, pull_request (including edited, labeled, unlabeled) and merge_group; the first, second and last never lead to a judgment but cannot be excluded by event in workflow_run.
RECOMMENDED: Trim the edited, labeled and unlabeled pull_request types as the pending trim intends, if the contract-only answers can be obtained another way; leave schedule, dispatch and merge_group alone because the merge queue needs them. Basis: .github/workflows/pr-require-checks.yml:3-68
Is the acceptance that every PR head judged today is still judged checkable unattended?
RECOMMENDED: Yes, as a test: replay a set of recorded upstream runs through the old and new triggers and assert the same heads are judged, via the parity test. Basis: .github/scripts/pr-verify/probe/parity.test.mjs

Sources read

.github/workflows/pr-verify.yml:39-43: on.workflow_run workflows [pr-require-checks], types [completed]
.github/workflows/pr-verify.yml:64-68: job runs only on main, upstream event pull_request, conclusion success, same-repo head
.github/workflows/pr-require-checks.yml:3-68: triggers are workflow_dispatch, schedule, pull_request (opened, synchronize, reopened, ready_for_review, edited, labeled, unlabeled), merge_group

_{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}

Decision recorded. The owner answered in the Issue Triage session (2026-10-25), accepting the recommended answers below:

go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

AND whatever is aligned with my overall goal of lowest friction, highest throughput (within our environmental, github, rate limit, etc. constraints)

Question asked: Cut the skip-only runs with a branches-ignore filter on pr-verify's workflow_run trigger (main and gh-readonly-queue/**), keeping pr-require-checks' edited/labeled/unlabeled types and the job-level if?

(intake Q1) The trigger cannot filter on upstream event or conclusion, so the job-level if stays. Is a measured drop, not zero, acceptable?
Accepted: Yes. Keep the job-level if as the safety net. Skips from failed or cancelled upstream PR runs remain and are few (4 failed, 2 cancelled in the body's day). Basis: kept; .github/workflows/pr-verify.yml:41-43,64-68 on origin/main. This is a lane trigger change, so the body's Security & Cost pass and owner merge apply.
(intake Q2) Which upstream runs should stop reaching pr-verify?
Accepted: The dispatch, schedule and merge_group runs, filtered at pr-verify's trigger with branches-ignore: their head branch is main or gh-readonly-queue/main/..., never a PR branch. Do not trim edited/labeled/unlabeled: those runs are pull_request successes that reach check-intent rather than skip, and they carry the required check's pr-title, do-not-merge and linkage answers. Basis: corrected. .github/workflows/pr-require-checks.yml:34-50 (edited/labeled/unlabeled are load-bearing); .github/scripts/maintenance-monitor-signals/collect.test.mjs:99 (merge-group runs of pr-require-checks carry head_branch gh-readonly-queue/main/...); that workflow_run honors branches/branches-ignore on the triggering run's head branch is judgment, UNVERIFIED against GitHub's events docs this session.
(intake Q3) Can "every PR head judged today is still judged" be checked unattended?
Accepted: Yes, as a workflow test that asserts the trigger and the check-intent if still admit pull_request runs from any non-main, non-queue branch. test(pr-pipeline): add the planted-defect replay harness for pr-verify #8681's parity test does not cover this: it checks the judge step and model route against replay.mjs, not which heads are judged. Basis: corrected; .github/scripts/pr-verify/probe/parity.test.mjs:1-6.

Acceptance criteria:

pr-verify.yml's workflow_run trigger ignores the head branches main and gh-readonly-queue/**; the check-intent job-level if is unchanged.
pr-require-checks.yml keeps its pull_request types, including edited, labeled and unlabeled.
A test asserts that a same-repository pull_request upstream run on a feature branch still passes the trigger and the check-intent if.
test(pr-pipeline): add the planted-defect replay harness for pr-verify #8681's parity test passes with the changed pr-verify.yml.

Checks a person runs:

Skipped pr-verify runs drop to near zero per day (body's Acceptance, measured over a day of runs after merge).

Navigation Menu

Repository navigation

pr-verify: stop firing workflow_run runs that only skip (~426 a day) #8695

Problem

Options

Constraints

Acceptance

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

pr-verify: stop firing workflow_run runs that only skip (~426 a day) #8695

Description

Problem

Options

Constraints

Acceptance

Activity

github-actions commented on Oct 20, 2026

kyle-sexton commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

kyle-sexton commented on Oct 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions