Skip to content

fix: dispatch release.yml explicitly since GITHUB_TOKEN tag pushes don't trigger it#4

Merged
shrey150 merged 1 commit into
mainfrom
shrey/fix-tag-release-trigger
Jul 16, 2026
Merged

fix: dispatch release.yml explicitly since GITHUB_TOKEN tag pushes don't trigger it#4
shrey150 merged 1 commit into
mainfrom
shrey/fix-tag-release-trigger

Conversation

@shrey150

@shrey150 shrey150 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What

Merging #3 pushed tag `v0.3.0` correctly (confirmed via `gh api repos/browserbase/browse-plugin/tags`), but `release.yml` never ran and no GitHub Release exists for it — confirmed zero workflow runs of any kind were queued for that tag push, not a failed run.

Why

Documented GitHub Actions behavior: a tag pushed using the default `GITHUB_TOKEN` from within a workflow run does not trigger other workflows' `push` events (loop prevention). `tag-release`'s tag push falls into exactly this case. The one documented exemption is `workflow_dispatch`, which `GITHUB_TOKEN` can trigger.

Fix

  • Added a `workflow_dispatch` trigger to `release.yml` with a required `tag` input.
  • `tag-release` now explicitly runs `gh workflow run release.yml -f tag="$TAG"` right after pushing the tag, instead of relying on the `push: tags` trigger.
  • `release.yml`'s `workflow_dispatch` only exists on `main`, not on the tag itself, and `softprops/action-gh-release` can't correctly infer the tag from a `workflow_dispatch` context (it falls back to `github.ref_name`, which would be `"main"`) — so the checkout step and the release step both explicitly use the `tag` input instead.

E2E Test Matrix

Command / flow Observed output Confidence / sufficiency
`actionlint .github/workflows/validate.yml .github/workflows/release.yml` No output (clean) Sufficient — both workflow files are syntactically valid.
`node scripts/validate-template.mjs` `Validation passed.` Sufficient — confirms nothing else regressed.
`gh api repos/browserbase/browse-plugin/actions/runs` before this fix Zero runs of any kind for the `v0.3.0` tag push Confirms the bug precisely: not a failed run, no run was ever queued.
`softprops/action-gh-release`'s own `action.yml` `tag_name` "Defaults to `github.ref_name`" Confirms the second gap this PR also fixes — an earlier version of this fix passed `--ref` without an explicit tag input, which would have released against the wrong ref.
Retroactive fix for `v0.3.0` Will run `gh workflow run release.yml -f tag=v0.3.0` manually once this merges, to cut the release the automation was supposed to produce Not yet run — doing this immediately after merge.

🤖 Generated with Claude Code

Confirmed live: merging PR #3 pushed tag v0.3.0 correctly, but
release.yml never ran and no GitHub Release was created. Root cause
is a documented GitHub Actions behavior -- a tag pushed using the
default GITHUB_TOKEN from within a workflow run does not trigger
other workflows' push events, to prevent infinite loops. That
exemption does not apply to workflow_dispatch, so tag-release now
explicitly dispatches release.yml instead of relying on push:tags.

release.yml's workflow_dispatch trigger only exists on main, not on
the tag itself, and softprops/action-gh-release can't infer the
right tag from a workflow_dispatch context (it falls back to
github.ref_name, which would be "main"). So the dispatch passes an
explicit tag input, and both the checkout step and the release step
use it to check out and tag the correct ref.
@shrey150
shrey150 force-pushed the shrey/fix-tag-release-trigger branch from 5de6d63 to 9e52847 Compare July 16, 2026 17:05
@shrey150
shrey150 merged commit f0a0d82 into main Jul 16, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants