Create GitHub Release and Slack still key off `published == 'true'`, so they can announce a half-shipped release that is not on npm yet
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 84/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- github-actions, javascript
调研方向
从 .github/workflows/release.yml 开始，跟踪 Verify every package version on this commit is on npm 步骤，以及 Create GitHub Release 和 Post release notes to Slack 的条件。检查 scripts/check-published.mjs 和 scripts/generate-release-slack-payload.mjs，了解现有的验证行为。完成的标准是：只有在 registry 验证成功后，两个通知才会运行，同时 Slack token 失败仍然不会阻塞流程。
由索引模型根据 Issue 内容生成。
描述
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 publishruns onepnpm publishper package and one failure leaves the release half-shipped, withworkflowpossibly pointing at a@workflow/corethat 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 publishexits 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/webstaged 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/webstayed staged for about a day. - 5.0.0-beta.49: just over 5m for
@workflow/webto 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.
- 主要语言
- TypeScript
- 星标
- 2.5k
- 派生
- 401
- 平均合并
- 2 天 36 分钟
- 30 天内合并 PR
- 150
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
vercel/workflow 的其他 Issue
-
node-module-esbuild-plugin: getImportedIdentifier only checks the first named import when locating a violation可能已有人在做 @div-cowboy 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
vercel/workflow#5057 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
code-transform.mdx §ID Generation omits the package-shipped `name@version` ID form可能已有人在做 @Mohith26 于 109 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 90/100
维护者通常 1 天内回复
-
world-postgres: LISTEN clients lose non-enumerable pg password credentials可能已有人在做 @vishalrajofficial 今天认领。 未关闭
难度 3/5 半天 新手友好度 25/100
维护者通常 1 天内回复
-
[world-local] SQLite never uses events_by_correlation, so hook_created writes scan the whole run未关闭
难度 3/5 1-2 天 新手友好度 55/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
AykutSarac/jsoncrack.com#616 ·
-
nip27: long hashtag swallows the rest of the content, lone # gives an empty hashtag可能已有人在做 @bardrop 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
nbd-wtf/nostr-tools#578 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
backnotprop/plannotator#3427 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
microsoft/Power-CAT-Copilot-Studio-Kit#942 ·
维护者通常 1 天内回复
-
[BUG]: Duplicate preposition in heading and unformatted feedback text on Strengthen Argument page未关闭bug
难度 2/5 1-3 小时 新手友好度 72/100
AOSSIE-Org/DebateAI#801 · 1 条评论 ·
维护者通常 1 天内回复