GeezerVison

Fixes #3783

The publish job now publishes a canary only when its commit comes after the commit of the canary already on npm, and canary publishes run one at a time.

Changes

All in the publish job of .github/workflows/test.yml.

• New step, "Skip a canary that is not newer than npm's". It runs for canary versions only, without the npm token.
  • It reads the current canary from npm's dist-tags endpoint, which is not CDN-cached. The package data that npm view reads is cached for 5 minutes.
  • It clones the repository's commit history with git clone --bare --filter=tree:0, which takes about half a second, and finds the commit named at the end of that canary's version.
  • Then it decides:
    • This build's commit comes after that commit: publish.
    • Same commit and same version: skip with a notice.
    • Same commit under a different version: publish. This can't happen today. It will after fix(build): name canaries above every published release of their major #3780, when the scheduled run rebuilds an unchanged main after a release.
    • This build's commit comes before that commit: skip with a warning.
    • Neither commit comes before the other, or the canary's commit can't be found: fail the job.
• concurrency on the job. Canary publishes share the group canary-publish with cancel-in-progress: false and queue: max, so they run one at a time and a waiting one is not replaced. Each release run gets a group of its own.
• The Publish step runs unless the new step asked to skip.
• Releases and release candidates publish exactly as before.

Behavior to be aware of

• The weekday scheduled run stops failing. On an unchanged main its publish fails with E403 today, as it did on 2026-09-30 and 2026-10-02. It now skips with a notice.
• A failed check stays failed. If the canary dist-tag is missing, or points at a build from a commit that is not on main, the step fails and so does every later canary publish. The error message says so and names the fix: someone with publish rights runs npm dist-tag add @angular/fire@<version of a build from main> canary.
• queue: max is recent. GitHub added it on 2026-05-07 (changelog). actionlint 1.7.12 does not know the key yet (Actionlint does not know about queue: key for concurrency rhysd/actionlint#657) and reports it as its only finding on this file.
• Runs from before this change are not covered. A re-run uses the original run's commit, so I expect it to publish without the check.
• The check trusts npm's answer. If npm returned the previous canary a few seconds after a publish, an older build queued right behind it would still publish. I have not measured whether npm lags like that.

Verification

I ran the new step's script, taken from the YAML, with bash -e against stand-in built packages. It cloned from GitHub and read npm for real, except where a case needed a different canary on npm.

• A build of an earlier commit on main is skipped with a warning, also when its version is higher.
• The same commit and version is skipped with a notice.
• The same commit under a higher version publishes.
• A build of a later commit publishes, also when npm's canary has the old 21.0.0-canary.a2662fe name.
• A build from a commit that is not on main, a canary on npm from a commit that is not on main, an unknown hash, and an npm reply without canary each fail the job.
• 21.0.0 and 21.0.0-rc.2 publish without the check.
• A failing curl or git clone fails the job, and nothing publishes.
• The clone holds only this repository's branches and tags, and after cloning the check needs no network.
• npm publish --dry-run packs the same files, with the same checksum, with and without the clone in the workspace.

The concurrency queue can't be run locally. This PR's CI shows whether GitHub accepts the workflow file. The publish job itself only runs on main and on releases.