Repository navigation
fix(nightly): skip a superseded publish, and stamp the version from the commit - #476
Merged
Merged
Conversation
…he commit A nightly run held in `waiting` on npm-autopublish could be released after a newer commit's nightly published, and its `--tag latest` would roll installers back to older code. The publish step now asks npm, immediately before publishing, whether a nightly with a later timestamp exists, and skips if so. That check is only sound with a commit-date stamp: the old stamp read the clock after the environment wait, so a stalled run would have minted the newest timestamp on npm. `--print-version` now requires `--date` (the committer date); `main` is rebase-merge only, so stamps follow the order of `main`. The breadcrumb job is gated on the new `published` output, and labels the stamp as the commit time.
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.
A nightly run can be held in
waitingon thenpm-autopublishenvironment while a newer commit lands. On 2026-10-06 the run fore8b2153sat there for 19 minutes with nothing anyone could approve, andde43cf6landed during the wait. If GitHub had released it, it would have published with--tag latestafter the newer nightly, andnpm i @taskless/cli-nightlywould have installed older code.What changes
npm publish, the run reads the published versions and skips if any nightly has a later timestamp, since the newer nightly already contains this commit. Only timestamps are compared, becausen.m.kcan go down when a changeset is removed. If npm can't be read, the step fails instead of assuming there is nothing newer. The check sits here and not in the gate job because the gate answers before the environment wait, which is when the newer commit arrived.--print-versionnow requires--date(git log -1 --format=%cI). Sincemainis rebase-merge only, stamps follow the order ofmain. Re-running a commit now produces the same version.publishedoutput. Its label changes from "Built at" to "Committed at". Its existing ordering check now orders by commit as well.nightly-superseded-skip, archived. It adds "A superseded nightly is not published" and restates the version, gate, and announcement requirements in full. I dry-ran the archive first: every prior scenario survives and six are added.There's still no concurrency group: one with
cancel-in-progresscould cancel a running publish. A stalled run still shows aswaitinguntil GitHub releases it, but it then publishes nothing, so nobody has to cancel it by hand.Verification
pnpm test:scripts(508 pass),pnpm typecheck,pnpm lint.published=false, a future stamp would have published.hasNewerNightlyreads all 180 currently published versions without throwing.No changeset: CI only.
Fixes #474