ci: gate the npm publish on lint, typecheck, tests and a tag/VERSION match - #32
Merged
Conversation
…match publish.yml triggers on a GitHub Release and ran nothing but a build before uploading to npm. That is how 3.13.1 shipped: it bumped package.json and src/version.ts but left VERSION on 3.13.0 with no changelog entry, and the version-consistency suite that catches both never ran until the push-triggered CI job afterwards — by which point npm had the broken tree and npm, like PyPI, does not allow replacing a published version. Adds the same gate the Python SDK's publish workflow has had since 1.8.1 died the same way: verify the release tag matches VERSION, then lint, typecheck and the unit suite, all before build/pack/publish. Simulated against the real tags: v3.13.1 fails the tag check (VERSION said 3.13.0), v3.13.2 passes. This is ci.yml's 22 leg, not full CI — 20 and 24 still run only on push, so a version-incompatible API is caught there. brand-numbers is deliberately left out: it compares marketing counts in the docs, and a stale model number is not a reason to block a bugfix or security release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
publish.ymltriggers on a GitHub Release and ran nothing but a build before uploading to npm.That is how 3.13.1 shipped broken: it bumped
package.jsonandsrc/version.tsbut leftVERSIONon 3.13.0 with no changelog entry.test/unit/version-consistency.test.tscatches both — but it only ran on the push-triggered CI job after the release, by which point npm already had the tree. npm, like PyPI, does not allow replacing a published version.What this adds
Between
pnpm installandpnpm run build:VERSION— a tag that disagrees with the package version means the wrong tree is being published. The existing "already published" check would stop a duplicate, but only after the release is cut.pnpm run lintpnpm run typecheckpnpm run test --run— which is what coversVERSION↔package.json↔src/version.tsand the changelog entry.Same shape as the Python SDK's
publish.yml, which grew this gate after 1.8.1 died the same way.Verified
Simulated the tag check against the real tags:
The gate commands run clean on this branch: lint pass, typecheck pass, 265 tests passed / 12 skipped. YAML parses and the steps sit in the intended order (gate → build → pack → publish).
The workflow itself cannot be exercised until the next release — release-triggered workflows only run on a real release. It fails closed, so the failure mode of a mistake here is a blocked publish, not a bad one.
Deliberate omissions
brand-numbersis not a gate. It compares marketing counts in the docs; a stale model number is not a reason to block a bugfix or security release.