Separate published from activated in the ledger, unblocking the npm payload refresh - #241
Merged
Merged
Conversation
…ng the npm payload refresh The v0.6.0 npm payload refresh could not be made, and the cause was a fault introduced by the previous release-flow work. test_action.py was repointed at packages/npm/ethos-pdf/vendor/manifest.json on the reasoning that it is "the record of the published CLI". It is not. A payload refresh moves that manifest to the next release before that release is published, so it tracks the activated version. The Action's URL meanwhile followed docs/release-state.json's release.version, which the activation gate holds at the published version until publication. Once the payload moved, the only state satisfying both assertions was a v0.5.0 URL carrying v0.6.0 digests: install_cli.py downloads the v0.5.0 archive and checks it against the v0.6.0 digest, so the Action fails on every run. ci.yml's released-cli-action-dogfood executes it twice, so this was a real break rather than an assertion artifact. Reproduced by simulating the refreshed manifest before changing anything, and reproduced as passing afterwards. The fix is to stop overloading one field. docs/release-state.json gains release.activated, and release.published_cli carrying the published archive and binary digests for both targets. The Action's digests now come from published_cli, next to the version its URL already used, so both halves derive from one published record and move together at publication. check_release_state.py validates the new keys: activated must be semver and not behind version, and every published_cli digest must be lowercase 64-hex. Separately, prepare-vendor.js now runs the vendored binary with --version and requires `ethos <manifest.cli_version>`. Every existing check compared the manifest against itself — the digests prove the manifest and the bytes agree with each other, never that the bytes are the version claimed. That is precisely the hole 1d23604 fell into: a package labelled 0.6.0 whose vendored CLI reported ethos 0.5.0, with the full suite green. Verified against the real vendored 0.5.0 binary, which a 0.6.0 manifest now rejects. The vendor-assembly fixtures answer --version accordingly, because a fake that cannot report its version does not model a real one. light-check, registry-surface-check, release-live-state-check, ethos-verify-action-contract, the npm package suite, and make release-gates all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: docushell-dev <hello@docushell.com>
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.
The v0.6.0 npm payload refresh could not be made. The cause is a fault I introduced in #239.
The deadlock
#239 repointed
actions/verify/tests/test_action.pyatpackages/npm/ethos-pdf/vendor/manifest.json, on the reasoning that it is "the record of the published CLI". It is not. A payload refresh moves that manifest to the next release before that release is published, so it tracks the activated version.Meanwhile the Action's URL followed
release-state.json'srelease.version, which the activation gate holds at the published version until publication.Once the payload moves, the only state satisfying both assertions is a v0.5.0 URL carrying v0.6.0 digests —
install_cli.pydownloads one archive and checks it against another's digest, failing at install on every run.ci.yml'sreleased-cli-action-dogfoodexecutes the Action twice, so this breaks for real, not just in an assertion.Reproduced by simulating the refreshed manifest before changing anything, and reproduced as passing afterwards.
The fix
Stop overloading one field.
release.versionrelease.activatedrelease.published_cliThe Action's digests now come from
published_cli, next to the version its URL already used. Both halves derive from one published record and move together at publication.check_release_state.pyvalidates the new keys:activatedmust be semver and not behindversion; every digest lowercase 64-hex.A vendored binary must report the version the manifest claims
prepare-vendor.jsnow runs the binary with--versionand requiresethos <manifest.cli_version>.Every existing check compared the manifest against itself — digests prove the manifest and the bytes agree with each other, never that the bytes are the version claimed. That is exactly the hole
1d23604fell into: a package labelled 0.6.0 whose vendored CLI reportedethos 0.5.0, full suite green.Verified against the real vendored 0.5.0 binary — a 0.6.0 manifest is now rejected.
Verification
light-check,registry-surface-check,release-live-state-check,ethos-verify-action-contract, the npm package suite, andmake release-gatesall pass.🤖 Generated with Claude Code