Skip to content

fix: remove redundant tag push in release workflow#4

Merged
slowdini merged 1 commit into
devfrom
fix/release-tag-double-push
Jun 21, 2026
Merged

fix: remove redundant tag push in release workflow#4
slowdini merged 1 commit into
devfrom
fix/release-tag-double-push

Conversation

@slowdini

Copy link
Copy Markdown
Owner

Problem

The release workflow (.github/workflows/release.yml) failed on the Create and push tag step when merging the release PR into main:

Run git config user.name "github-actions[bot]"
To https://github.com/slowdini/synthpunk
 ! [rejected]        v0.1.1 -> v0.1.1 (already exists)
error: failed to push some refs to 'https://github.com/slowdini/synthpunk'

Root cause

The tag is created twice within a single workflow run, not by two separate runs:

  1. Create GitHub release runs gh release create "vX.Y.Z" .... Per gh release create --help:

    If a matching git tag does not yet exist, one will automatically get created from the latest state of the default branch.

    So this one command creates both the GitHub release and the vX.Y.Z tag on the remote.

  2. Create and push tag then ran git tag vX.Y.Z + git push origin vX.Y.Z. The push was rejected because the tag already existed on the remote — created by step 1.

The idempotency check (Check if tag already exists) didn't catch this because it only inspects the local clone before gh release create runs. At that point the tag has never existed locally, so is_release=true and both steps executed.

Fix

Delete the redundant Create and push tag step. gh release create already creates the tag at the latest commit on main (which is exactly what the workflow is reacting to), so the manual git tag + git push was duplicate work.

Downstream jobs (build-artifacts, publish-zed, publish-neovim) already check out ref: ${{ needs.tag-and-release.outputs.tag }} and continue to work — the tag is created by gh release create before those jobs run.

This also makes the workflow more robust, not just shorter: previously, if gh release create succeeded but the tag push failed, the release existed without a recoverable state. Now the release and tag are created atomically by a single command, and a failure leaves both absent so the next run retries cleanly.

Verification

  • bun run check — clean (51 files, no fixes)
  • bun test — 91 pass, 0 fail
  • YAML structure validated; gh release create step preserved, downstream job refs intact
  • Confirmed gh release create auto-creates tags per gh release create --help

Note: full end-to-end verification requires the next release run on main. The fix is a pure deletion of a step whose behavior was already being performed by the preceding step.

gh release create already creates the git tag on the remote when it
doesn't yet exist (per gh release create --help). The separate 'Create
and push tag' step that followed it therefore attempted to push a tag
that already existed, which git rejected with:

  ! [rejected] v0.1.1 -> v0.1.1 (already exists)

Removing the redundant step lets gh release create own both the release
and the tag atomically. Downstream jobs (build-artifacts, publish-zed,
publish-neovim) already checkout ref: ${{ needs.tag-and-release.outputs.tag }}
and continue to work since the tag is created before they run.
@slowdini slowdini merged commit 4bd8475 into dev Jun 21, 2026
1 check passed
@slowdini slowdini deleted the fix/release-tag-double-push branch June 21, 2026 21:13
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.

1 participant