Commit d80d4e6
committed
fix(ci): advance @next dist-tag on stable publish
Regression: after a stable release, npm publish --tag latest correctly
advances latest, but @next stays pinned to whichever pre-release we cut
last. Consumers tracking `aiwg@next` resolve to stale code (e.g. after
2026.5.3 GA, @next still pointed at 2026.5.3-rc.1).
Add a post-publish step that runs `npm dist-tag add aiwg@$VERSION next`
when the release is stable. Step is gated on `steps.version.outputs.prerelease == 'false'`
so pre-releases (which legitimately update @next via --tag next) are
unaffected. Reuses the workflow's OIDC token — no long-lived auth.
Verified locally:
before: latest=2026.5.3 next=2026.5.3-rc.1
after: latest=2026.5.3 next=2026.5.3 (target state)
Force-retag v2026.5.3 to run the workflow with the new step. The publish
step's idempotency (already-published path) handles the re-fire cleanly;
only the new dist-tag step actually performs work on this run.
Refs: #1278 (post-Track A regression)1 parent 41e563b commit d80d4e6
1 file changed
Lines changed: 25 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
349 | 349 | | |
350 | 350 | | |
351 | 351 | | |
| 352 | + | |
| 353 | + | |
| 354 | + | |
| 355 | + | |
| 356 | + | |
| 357 | + | |
| 358 | + | |
| 359 | + | |
| 360 | + | |
| 361 | + | |
| 362 | + | |
| 363 | + | |
| 364 | + | |
| 365 | + | |
| 366 | + | |
| 367 | + | |
| 368 | + | |
| 369 | + | |
| 370 | + | |
| 371 | + | |
| 372 | + | |
| 373 | + | |
| 374 | + | |
| 375 | + | |
| 376 | + | |
352 | 377 | | |
353 | 378 | | |
354 | 379 | | |
| |||
0 commit comments