Our release workflow tagged three versions that were never published

说明与用途

三版 SDK 被标记并宣布，但未发布到 npm，导致用户无法安装。问题源于使用 GITHUB_TOKEN，它不会触发新工作流。用 GitHub App 令牌替换并在主工作流中添加发布步骤后，问题得到解决。

问题

Three SDK releases were tagged and announced but never published to npm, leaving users unable to install them.

结果

The root cause was the use of a personal access token that authenticated as a person, allowing the release workflow to trigger the publish workflow. Switching to GITHUB_TOKEN prevented the second workflow from running. The fix involved adding the publish step to the first workflow, using a GitHub App token for cross‑workflow triggers, and implementing checks to ensure packages exist on npm.

工作流

• 1. Merge to main triggers first workflow. 2. First workflow calculates next version, tags repo, creates GitHub release. 3. Second workflow should trigger on release event, build package, publish to npm. 4. Issue: GITHUB_TOKEN does not trigger workflows, so second workflow never ran. 5. Manual publication of missing versions from tags. 6. Updated workflow: publish step added to first workflow with needs, uses short‑lived GitHub App token for cross‑workflow trigger. 7. Final step fetches version from npm and fails if absent. 8. Daily job compares tags with npm registry and opens issue for missing packages.

证据

The first workflow kept working. Tags appeared, releases appeared, the run was green. The second workflow never ran again, and nothing anywhere said so.

来源

GitHub documents this: events caused by the GITHUB_TOKEN do not start new workflow runs, with the exception of workflow_dispatch and repository_dispatch.

来源

We published the three versions by hand that afternoon, from their tags.

来源

Publishing is now a job in the same workflow as the release, joined with needs, so it cannot be skipped without the release run itself showing as failed.

来源