Repository navigation
ci(mcpx): restore the policy-listed PR test tier trigger #4533
Description
Problem
.github/ci-policy.md lists mcpx test as a PR-tier workflow (init, unit, lint, six static e2e shards, and ci-ok), but .github/workflows/mcpx-test.yml currently triggers only on pushes to main and workflow_dispatch; it has no pull_request trigger.
This was observed while verifying PR #4417, which changes pkgs/mcpx/**: the PR check rollup has only CodeRabbit (neutral/skipping), and gh run list --branch queue/6157-4282-mcpx-mcpclient-bound-read returns no GitHub Actions runs. The exact-head targeted test go test ./internal/mcpclient/ -count=1 passed locally; that does not substitute for the policy-listed PR tier.
Expected
Align the workflow trigger with the documented PR tier, then verify a non-draft mcpx PR receives the documented jobs. Until then, report the coverage gap rather than treating absent checks as green.
Acceptance criteria
-
.github/workflows/mcpx-test.ymltriggers onpull_requestin addition to push-to-main and workflow_dispatch, matching the PR tier documented in.github/ci-policy.md. - A non-draft PR touching
pkgs/mcpx/**receives the documented jobs (init, unit, lint, six static e2e shards, ci-ok) — verified on a real PR after the change. - Until the trigger lands, the coverage gap is reported rather than absent checks being treated as green.
Activity
dezren39 commentedon Nov 2, 2026
Intake review
Filed from a queue-worker run (agent note on the issue) after PR #4417 showed no mcpx PR-tier runs. Related: issue #4282, PR #4417. Risks: PR-tier cost/time on every mcpx PR — that is the documented policy, so the workflow should match the policy or the policy should be amended deliberately, not drift. Suggested approach: add the
pull_requesttrigger with the same path filters the policy implies, then verify on the next mcpx PR.— fleet monitor intake pass, 2026-11-02. Labels normalized (kind/source/status/priority/effort) and acceptance criteria appended to the body; original body preserved above the new section.
dezren39 commentedon Nov 3, 2026
Fresh evidence (2026-11-03, queue task 3275 while verifying PR #2714 stage 1):
d7759395(pushed 2026-11-03T07:05Z, touchespkgs/mcpx/internal/cli/**) has exactly one check run: CodeRabbit (success). Nomcpxrun exists for any head after 2026-10-30T22:51Z (/actions/runs?branch=queue/3275-1980-cli-runshows 21 runs, the lastmcpxone from 2026-10-30).main.github/workflows/mcpx.ymltriggers only onpush: [main],schedule,workflow_dispatch.nix-ci.yml(which owns the policy contextbasic: proxy port fallbacks) likewise has nopull_requestormerge_grouptrigger — its onlypull_requeststring is a job-levelif:.pull_requesttrigger —opencode-config-guardandproduction-line-guard.branches/main/protectionreportsrequired_status_checks: null, which is why PRs still merge: the gate the policy describes cannot fire.So the practical effect is not just "mcpx PR tests are missing": no PR in the repo can currently earn
basic: proxy port fallbacks. Worth deciding in the restoration PR whether to restorepull_request(+merge_group, for the queue) onnix-cias well asmcpx, and whether branch protection should re-require the context once it can actually be produced.developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged
queue: repo-health-code-pilot
task: 8412 (completed, outcome
triaged)by: openchamber-scheduled-lane (repo-worker-code, lane bf419306)
at: 2026-11-03T19:44Z
Triage at current main: still live.
.github/workflows/mcpx-test.ymltriggers only onpush: branches: [main]andworkflow_dispatch, with nopull_request..github/ci-policy.mdstill lists mcpx test (init + unit + lint + six e2e shards + ci-ok) as PR tier for non-draft PRs. No open PR changes this trigger (#4804 is an e2e env-allowlist change and does not touch the trigger).Ordering / blocker: adding the trigger alone would make every non-draft mcpx PR red, because the suite is already failing on clean main (#3813 records unit plus all e2e shards plus ci-ok failing). Blockers are #2534 (main-broken basic: test), #2716 and #2846 (settings and conformance red on clean main), all OPEN. Fix order: (1) green mcpx-test on main via #2534/#2716/#2846, then (2) add
pull_requestto the trigger and verify a non-draft mcpx PR gets the documented jobs. Doing (2) first would surface the red tier on every PR.No fix PR opened from triage. Acceptance item 3 (report the gap, do not treat absent checks as green) is met by this comment.
Labels: removed
queue/queuedandstatus/needs-triage; addedstatus/triagedandstatus/blocked(blocked on #2534/#2716/#2846).docs(ci): describe the dispatch/schedule trigger model (#5501)
dezren39 commentedon Nov 4, 2026
Superseded by the 2026-11-04 owner ruling recorded in #5501: repo-wide, there is no commit- or PR-triggered CI.
push/pull_requesttriggers were removed from every workflow, so "restore the policy-listed PR test tier" is no longer the intended state and this issue's acceptance cannot be met..github/ci-policy.mdis being reconciled in #5511, which records dispatch/schedule/merge_group as the model and lists the inert PR-only jobs left inmcpx-test.yml/mcpx.ymlfor a reviewed cleanup. The mcpx suite-health blockers (#2534/#2716) are unaffected by this closure. Reopen only if the ruling changes.docs(ci): align policy with dispatch-only CI after #5501