forked from molecule-ai/molecule-core
e22a56d351
Supersedes PR #2321's two-jobs-sharing-a-name approach, which didn't actually clear branch-protection's required-check evaluation. Live test on PR #2314: GraphQL `isRequired` confirmed BOTH check runs under "Canvas (Next.js)" name (one SUCCESS via no-op, one SKIPPED via real job) registered, and the SKIPPED one kept mergeStateStatus = BLOCKED despite the SUCCESS sibling. Branch protection's "set of matching contexts" semantic is stricter than the durable feedback memory documented — at least one passing isn't enough; SKIPPED counts as not-passed regardless. Real fix: ONE job that always runs (no job-level `if:`), with all real work gated on the path filter via per-step `if:`. Produces exactly one "Canvas (Next.js)" check run per commit, always SUCCEEDS, regardless of which paths changed. Costs ~10s of always-on CI runtime per PR — negligible vs. the manual-merge cost when the BLOCKED state catches us. This same anti-pattern probably affects Platform (Go) (`platform` filter), Python Lint & Test (`python` filter), and Shellcheck (E2E scripts) (`scripts` filter) — all required, all path-gated. PR-A and PR-2321 merged because they happened to trigger every filter; PR-B only missed canvas. File a follow-up issue to apply the same single-job-conditional-steps pattern across those required jobs to remove the latent merge-blocker. Updates feedback memory: branch_protection_check_name_parity is wrong about "two jobs sharing name + at-least-one-success works." Need to correct the note. |
||
|---|---|---|
| .. | ||
| scripts | ||
| workflows | ||
| CODEOWNERS | ||
| dependabot.yml | ||