When a pgxntool PR has a paired pgxntool-test PR (same branch name) whose CI has already passed, check-test-pr sets run_tests=false and the test job is intentionally skipped — tests already ran once, in the paired pgxntool-test PR. This is correct by design (see .github/workflows/CLAUDE.md, "Normal CI flow"), but the PR checks UI just shows a bare CI / test (pull_request) — skipped, with nothing indicating why. Read cold, that looks like a suspicious or broken check rather than an intentional dedup.
Surfaced on PR #63: test showed skipped even though its paired PR #30 had already run the full matrix and passed — correct behavior, but confusing enough to prompt investigation.
Ideas (not prescriptive — pick what's simplest)
- Rename the
test job with a dynamic name: reflecting the reason, e.g. something like name: 🐘 PostgreSQL matrix (${{ needs.check-test-pr.outputs.run-tests == 'true' && 'running here' || 'see paired pgxntool-test PR' }}). Job-level name: can reference a prior job's needs.*.outputs.
- Have
check-test-pr post a short PR comment or check-run summary linking to the paired PR when it decides to skip.
- At minimum, rename the job from
test to something like test (skipped when a paired test PR covers it) so the skip reads as expected rather than alarming.
Low priority / no urgency — just noting it while it's fresh.
When a pgxntool PR has a paired pgxntool-test PR (same branch name) whose CI has already passed,
check-test-prsetsrun_tests=falseand thetestjob is intentionally skipped — tests already ran once, in the paired pgxntool-test PR. This is correct by design (see.github/workflows/CLAUDE.md, "Normal CI flow"), but the PR checks UI just shows a bareCI / test (pull_request) — skipped, with nothing indicating why. Read cold, that looks like a suspicious or broken check rather than an intentional dedup.Surfaced on PR #63:
testshowed skipped even though its paired PR #30 had already run the full matrix and passed — correct behavior, but confusing enough to prompt investigation.Ideas (not prescriptive — pick what's simplest)
testjob with a dynamicname:reflecting the reason, e.g. something likename: 🐘 PostgreSQL matrix (${{ needs.check-test-pr.outputs.run-tests == 'true' && 'running here' || 'see paired pgxntool-test PR' }}). Job-levelname:can reference a prior job'sneeds.*.outputs.check-test-prpost a short PR comment or check-run summary linking to the paired PR when it decides to skip.testto something liketest (skipped when a paired test PR covers it)so the skip reads as expected rather than alarming.Low priority / no urgency — just noting it while it's fresh.