celilo/bna-yard-sale
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bump to 0.3.1, and stop pr-validate passing the publish gate blindly #4

Merged
forgejo-admin merged 1 commit from fix/publish-readiness into main 2026-09-09 02:52:17 +00:00
Conversation 0 Commits 1 Files changed 3 +9 -3
forgejo-admin commented 2026-09-09 02:38:35 +00:00
Owner
Copy link

What happened

Merging #3 triggered the release, and it failed in celilo module check — before publish — on the git publish-readiness gate:

✗ stale-version drift
    src commits past last manifest.yml change
src commit:          1e16f02ad906
manifest.yml commit: 0e0fc462de85

That is a correct refusal. Three commits after the last manifest change touched shipped content (README.md and package.json are both in the package), so publishing would have put changed bytes on the registry under an unchanged 0.3.0. Nothing was published; the registry is unchanged.

The version

0.3.0 → 0.3.1. Nothing has ever been published, so this is not a revision of something a consumer holds — it records that the artifact changed after 0.3.0 was set. The tool's other option is to touch manifest.yml and let auto-revision pick 0.3.0+1, which reads oddly for a module's first release. package.json moves with it, which manifest.test.ts already enforces.

Happy to switch to the touch/+1 form if you prefer that convention.

The part worth reading: the gate could never have caught this

pr-validate checked out with --depth 1. checkModuleStale compares the last commit touching manifest.yml against the last commit touching shipped source. With one commit of history there is no commit on either side, so it returns "not stale" and the check passes vacuously.

So the gate that blocks the release was invisible on every PR, and could only ever fire after merge — the most expensive moment for it to fail, and exactly what happened.

release.yml already fetched full history and says why in its checkout step ("publish reads git for versioning"). pr-validate simply did not match it. It does now.

Verified, not assumed

Cloned the identical failing sha 1e16f02 with --depth 1 and ran the same command:

commits visible: 1
Publish readiness (git):
  ✓ stale-version drift
      manifest.yml is current with respect to module src

The precise opposite of what the release job reported on identical content. With full history this branch now reports 8 ok, 0 warn, 0 fail.

This PR is therefore the first one whose module check is actually meaningful.

Gates

gate exit
bun run check (5 gates) 0 — 56 pass, 0 fail
celilo module check . 0 — 8 ok, 0 warn, 0 fail

e2e not re-run: this changes a version string and a CI fetch depth, neither of which the deploy suite exercises. It was green on 1e16f02 at ten stages, 142s.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Qbb67pVLEyTPKMo9T8Pee

## What happened Merging #3 triggered the release, and it failed in `celilo module check` — before publish — on the git publish-readiness gate: ``` ✗ stale-version drift src commits past last manifest.yml change src commit: 1e16f02ad906 manifest.yml commit: 0e0fc462de85 ``` That is a correct refusal. Three commits after the last manifest change touched shipped content (`README.md` and `package.json` are both in the package), so publishing would have put changed bytes on the registry under an unchanged `0.3.0`. Nothing was published; the registry is unchanged. ## The version `0.3.0` → `0.3.1`. Nothing has ever been published, so this is not a revision of something a consumer holds — it records that the artifact changed after `0.3.0` was set. The tool's other option is to touch `manifest.yml` and let auto-revision pick `0.3.0+1`, which reads oddly for a module's first release. `package.json` moves with it, which `manifest.test.ts` already enforces. Happy to switch to the touch/`+1` form if you prefer that convention. ## The part worth reading: the gate could never have caught this `pr-validate` checked out with `--depth 1`. `checkModuleStale` compares the last commit touching `manifest.yml` against the last commit touching shipped source. With one commit of history there is no commit on **either** side, so it returns "not stale" and the check passes vacuously. So the gate that blocks the release was invisible on every PR, and could only ever fire after merge — the most expensive moment for it to fail, and exactly what happened. `release.yml` already fetched full history and says why in its checkout step ("publish reads git for versioning"). `pr-validate` simply did not match it. It does now. ## Verified, not assumed Cloned the identical failing sha `1e16f02` with `--depth 1` and ran the same command: ``` commits visible: 1 Publish readiness (git): ✓ stale-version drift manifest.yml is current with respect to module src ``` The precise opposite of what the release job reported on identical content. With full history this branch now reports `8 ok, 0 warn, 0 fail`. This PR is therefore the first one whose `module check` is actually meaningful. ## Gates | gate | exit | | --- | --- | | `bun run check` (5 gates) | 0 — 56 pass, 0 fail | | `celilo module check .` | 0 — 8 ok, 0 warn, 0 fail | e2e not re-run: this changes a version string and a CI fetch depth, neither of which the deploy suite exercises. It was green on `1e16f02` at ten stages, 142s. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018Qbb67pVLEyTPKMo9T8Pee
fix(ci): bump to 0.3.1, and stop pr-validate passing the publish gate blindly
All checks were successful
pr-validate / validate (pull_request) Successful in 20s
Details
daa24709d0 
Run 10 (the release triggered by merging #3) failed in `celilo module check`,
before publish, on the git publish-readiness gate:

    ✗ stale-version drift
        src commits past last manifest.yml change
    src commit:          1e16f02ad9
    manifest.yml commit: 0e0fc462de

Correct refusal. Three commits after the last manifest change touched shipped
content (README.md and package.json are both in the package), so publishing
would have put changed bytes on the registry under an unchanged 0.3.0.

Two fixes.

**0.3.0 -> 0.3.1.** Nothing has ever been published, so this is not a revision
of anything a consumer holds; it just records that the artifact changed after
0.3.0 was set. The alternative the tool offers is touching manifest.yml and
letting auto-revision pick 0.3.0+1, which reads oddly for a module's first
release. package.json moves with it, which manifest.test.ts already enforces.

**pr-validate now fetches full history.** This is the part worth reading. It
used `--depth 1`, and `checkModuleStale` compares the last commit touching
manifest.yml against the last commit touching shipped source. With one commit
of history there is no commit on either side, so it returns "not stale" and the
check passes VACUOUSLY. The gate that blocks the release was therefore
invisible on every PR and could only ever fail after merge, which is the most
expensive moment for it to fail and exactly what happened.

Verified, not assumed: cloned the same failing sha 1e16f02 with `--depth 1` and
ran the same command. It reports `✓ stale-version drift — manifest.yml is
current with respect to module src`, the precise opposite of what the release
job saw on identical content. With full history the branch now reports
8 ok, 0 warn, 0 fail.

release.yml already fetched full history and says why in its checkout step.
pr-validate simply did not match it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Qbb67pVLEyTPKMo9T8Pee
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
celilo/bna-yard-sale!4
No description provided.