Repository navigation
Let a started npm release finish after newer merges (WORK-9253) - #49
Merged
Merged
Conversation
The automatic release checked a second time, right before npm publish, that master still pointed at its source, and failed if another merge had landed during the build and checks. The workflow already runs the whole release in one concurrency group that never cancels a run in progress, so the newer merge waits and publishes next. Keep the check at the start, which still refuses a rerun of an older commit, and drop only the later comparison. Every other identity, registry and integrity check still runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.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
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.
Problem
The automatic npm release checked twice that master still pointed at its source: once at the start and again right before
npm publish. If another merge landed while it built, checked and packed both packages, the second check failed the run ("Source is no longer current master"), so a finished release never published.Change
scripts/release-auto.mjskeeps the master comparison at the start of publish mode and drops the one beforenpm publish. Every other check still runs: GitHub Actions only, the repository,GITHUB_REF,GITHUB_SHAequal to HEAD, push or dispatch only, a clean tree, the registry plan, the byte-integrity check of any version already published and the post-publish verification.This is safe because
publish-npm.ymlruns the whole job, from the first check through publishing and verifying both packages, in thecli-npm-releaseconcurrency group withcancel-in-progress: false. The run in progress always finishes, one run waits behind it, and a newer push replaces that waiting run, so the newer merge publishes next as a higher patch version. Push and manual dispatch both use that group. A rerun of an older commit is still refused at the start, and the existing release plan still refuses to movelatestbackward. The only path outside the group is the manualrelease:publishcommand, which the release guide already says not to run alongside the workflow. A comment on the workflow's concurrency setting now records that guarantee.docs/releases.mdnow describes this behavior.Checks
npm run check: typecheck, build, 16 test files with 103 tests passing, and the public artifact check.npm run test:package: both packed archives installed in a clean consumer.npm run release:auto:dry-runon this commit: passed; it would publish both packages as 0.5.4 (dry run only, nothing uploaded).node --check scripts/release-auto.mjs: passed.No new automated test:
release-auto.mjshas no tests, and a test of this change would have to fake the registry, the pack step and npm publish, so it would only mirror the code. The tested release plan and integrity checks are unchanged.What merging does
PRODUCTION_DEPLOY_ENABLEDistrueand thenpmenvironment has only a branch rule, no required reviewer. Merging starts Publish CLI to npm right away, and it publishes@dealmachine/clianddealmachineas the next patch, 0.5.4 unless another version lands first, with unchanged runtime code. After the merge, staging gets the usual master back-merge.Not yet verified
A real release where a merge lands mid-publish. That happens the next time two CLI merges overlap.
Ticket: WORK-9253 (https://factory.dealmachine.com/work/WORK-9253)
🤖 Generated with Claude Code