Repository navigation
fix(source-control): review-venue misses review lanes that call pr-review-cli.yml #9601
Description
Problem
/source-control:pull-request review-venue reports both CI review lanes absent in this repository, though both run on every pull request. So ready, and prep where it applies, run a local code and security review that duplicates the CI lanes on every PR.
Observed 2026-10-24 ~05:1xZ on #9595:
code-review local absent: no recent pull_request run calls the code-review lane
security-review local absent: no recent pull_request run calls the security-review lane
Over the same night, pr-review-hosted.yml and pr-review-security-hosted.yml each completed about 20 successful pull_request runs (Actions API, runs since 01:30Z).
Cause
plugins/source-control/skills/pull-request/scripts/review-venue.sh:64-69 finds a lane by the reusable workflow its caller references: ci-workflows/.github/workflows/pr-review.yml (code) or pr-review-security.yml (security). Since the owner's Q39 decision (one key-first launcher per lane), both callers reference melodic-software/ci-workflows/.github/workflows/pr-review-cli.yml@<sha>. That holds on the newest pr-review-hosted pull_request run's referenced_workflows, so neither regex matches.
Fix
Recognize pr-review-cli.yml and tell the two lanes apart by something that differs between them, for example the caller workflow path (pr-review-hosted.yml vs pr-review-security-hosted.yml) or the lane input the caller passes. Keep the old paths for consumers still on them. Add a test with a pr-review-cli.yml reference for each lane.
Impact
Each ready run spends two fresh-context model reviews that CI already does, and an unattended caller cannot skip them (--skip is refused unattended). That is friction against the owner's "lowest friction, highest throughput" direction.
Activity
github-actions commentedon Oct 24, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; a maintainer confirms or changes it.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood:
review-venuereports both CI review lanes as absent because both callers now referencepr-review-cli.yml, which the script did not recognize. A later comment says main already handles this (#9307, #9348) and closed the issue. The 2026-10-24 observation most likely came from an older installed plugin. If an up-to-date install still reports a lane absent, please reopen with its output. No likely duplicates found in the open issues.Automated triage. A maintainer reviews it.
melodic-automation-lanes commentedon Oct 24, 2026
Not admitted to the issue lane: it has no
- [ ]task list to check. A recorded decision does not change these rules (.github/actions/resolve-config/admission-rules.json); a person who wants it worked addsagent-ready.kyle-sexton commentedon Oct 25, 2026
Closing as completed.
review-venue.shon main recognizespr-review-cli.ymland tells the lanes apart by the caller's path (plugins/source-control/skills/pull-request/scripts/review-venue.sh:72-75), with tests (review-venue.test.sh:324-335). It landed in #9307 (5f8c010, 2026-10-23 05:51Z) and #9348 (0aca16f, 06:21Z), before the 2026-10-24 observation here, so that run most likely used an installed plugin older than main (not verified). A read-only run of main's script on 2026-10-25 reported both lanes as CI. If an up-to-date install still reports a lane absent, reopen with its output.kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.