Create GitHub Release and Slack still key off `published == 'true'`, so they can announce a half-shipped release that is not on npm yet

Aperta Adatta ai principianti
  • Qualcosa non va?
#4,148 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, javascript
Ambito
ci-cd, release

Direzione di ricerca

Inizia da .github/workflows/release.yml, seguendo il passaggio Verify every package version on this commit is on npm e le condizioni di Create GitHub Release e Post release notes to Slack. Esamina scripts/check-published.mjs e scripts/generate-release-slack-payload.mjs per il comportamento di verifica esistente. Il lavoro è completato quando entrambi gli annunci vengono eseguiti solo dopo che la verifica del registro ha esito positivo, mentre gli errori del token Slack rimangono non bloccanti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Workflow: .github/workflows/release.yml @ f5aeaa869c1c15b7604e14047354059b5bd1f5c5
Scripts: scripts/check-published.mjs, scripts/generate-release-slack-payload.mjs

What happens

The Release job already knows a publish can be left half-shipped. From the comment above Verify every package version on this commit is on npm:

changeset publish runs one pnpm publish per package and one failure leaves the release half-shipped, with workflow possibly pointing at a @workflow/core that is not on npm yet. 5.0.0-beta.48 shipped 7 of 21 packages on its first attempt…

check-published.mjs is the check that job runs after publishing, whatever the publish step's outcome. It GETs the registry and fails when a publishable version is NOT ON NPM, or when the branch dist-tag does not point at it. The script's own header:

npm does not commit a publish synchronously: pnpm publish exits 0 once the version is staged, and the version list and dist-tag catch up afterwards. The lag is minutes, not seconds… 5.0.0-beta.48 left @workflow/web staged for about a day, which no retry budget can wait out.

Create GitHub Release and Post release notes to Slack do not mention that check. Both still run under:

if: steps.changesets.outputs.published == 'true'

published is Changesets reporting the publish script, not the registry. Slack is fed PUBLISHED_PACKAGES so the payload “matches the exact set of packages published.” generate-release-slack-payload.mjs never GETs npm. The post is :rocket: New release: <release url>.

continue-on-error: true is only there so a broken Slack token must not turn a successful release red (token_expired, then invalid_auth). It is not a dependency on the verify step.

GitHub Actions fail-fast means those two steps are skipped today when Verify every package version on this commit is on npm exits 1. That is job order, not an if. The authorize condition is still published == 'true'.

Why this matters

The invariant check-published.mjs exists to keep trustworthy is “every non-private package … must have its manifest version in the registry's version list, and the branch's dist-tag must point at it.” Slack and the GitHub Release still speak from Changesets' list.

So the room can be told the ship happened while the script would print NOT ON NPM, or while a version is only staged. Installers then hit the half-ship the comments already name: workflow pointing at an @workflow/core that does not exist yet.

Evidence

You already measured this on your own releases (from check-published.mjs):

  • 5.0.0-beta.48 shipped 7 of 21 packages on its first attempt; @workflow/web stayed staged for about a day.
  • 5.0.0-beta.49: just over 5m for @workflow/web to appear in the registry.
  • 5.0.0-beta.50: 1m29s @workflow/astro, 3m03s @workflow/core (9.4MB), 4m11s @workflow/web (11.3MB).

On that window, Changesets can already have published == 'true' (pnpm publish exited 0 once staged). The Slack/Release if would be true. The verify step would still be retrying or exiting 1.

What we would like

Gate Create GitHub Release and Post release notes to Slack on the verify step succeeding — the same “whatever the publish step's outcome” rule you already wrote — not only on steps.changesets.outputs.published == 'true'.

Either:

if: steps.changesets.outputs.published == 'true' && steps.<verify>.outcome == 'success'

or make those two steps needs the registry check so the announce cannot outrun “NOT ON NPM.”

Optionally have generate-release-slack-payload.mjs refuse to post unless the versions in PUBLISHED_PACKAGES are visible and dist-tagged, so the payload cannot say “New release” for a version the registry will not serve.

Lingua principale
TypeScript
Stelle
2.5k
Fork
401
Merge medio
2g 36m
PR unite (30g)
150

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di vercel/workflow

Tutte le issue di vercel/workflow

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.