Loading page...Загружаем страницу...正在加载页面...
AtlasRepo

Our release workflow tagged three versions that were never published

Description and use

Three SDK releases were tagged and announced but never published to npm, preventing users from installing them. The issue stemmed from using GITHUB_TOKEN, which does not trigger new workflows. Replacing it with a GitHub App token and adding a publish step to the main workflow resolved the problem.

Problem

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

Outcome

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.

Workflow

  • 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.

Evidence

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

Source

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

Source

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

Source

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.

Source

  • Record date: 2026-10-14T08:41:29.730Z