mirror of
https://github.com/EveryInc/compound-engineering-plugin.git
synced 2026-11-02 23:11:29 +01:00
Trevin Chow
7b2b6380c1
Codex review (P1) caught that the stale-pin check would block the very release
the pins exist to create. release-please bumps .release-please-manifest.json
*inside* the generated release PR, and ci.yml runs release:validate on every PR.
So on the release PR the working-tree manifest already reads 1.0.3 / 1.0.2 while
the pins are still 1.0.3 / 1.0.2 -- pin == manifest -> "stale" -> CI fails, and
the marketplace release can never merge.
The release-PR state (manifest already bumped) and a genuinely-stale leftover pin
are indistinguishable from the working tree alone, so compare against the version
released on the base branch instead:
- validate.ts reads the manifest from origin/main (git show) and passes that as
the released baseline; the working-tree manifest is still used for the metadata
sync. If origin/main is unreachable it returns {} so the check no-ops rather
than risk a false block.
- config.ts: a pin is stale only when a released baseline is known AND the pin is
at-or-below it. Unknown baseline -> allow. (Drops the earlier "no manifest
entry -> error" branch, which would have mis-fired on the fail-open path.)
- ci.yml: the test job now checks out full history (fetch-depth: 0) so
origin/main is available to compare against.
Walks through correctly: fresh-pin PR (base 1.0.2, pin 1.0.3 -> allow);
release PR (base still 1.0.2 until it merges, pin 1.0.3 -> allow); after the
release ships (base 1.0.3, pin 1.0.3 -> stale -> next PR fails until pins are
removed). Verified by simulating the release-PR manifest locally: no stale error.