Fetch git tags before running gem release

[ytkg]

Adds a git fetch --tags step to ensure that tags are fetched before running the bundle exec rake release task.

This step is necessary to avoid errors when trying to push a tag that already exists remote. Without fetching the tags, the release process can fail with an error like:

Run bundle exec rake release
komeda 0.4.0 built to pkg/komeda-0.4.0.gem.
Tagged v0.4.0.
Untagging v0.4.0 due to error.
rake aborted!
Running `git push origin refs/tags/v0.4.0` failed with the following output:

To https://github.com/ytkg/komeda
 ! [rejected]        v0.4.0 -> v0.4.0 (already exists)
error: failed to push some refs to 'https://github.com/ytkg/komeda'
hint: Updates were rejected because the tag already exists in the remote.

This change ensures that the action fetches the latest tags from the remote repository, preventing conflicts when tags already exist, and allows the release process to continue smoothly.

[segiddins]

Is this better served by setting the fetch-depth when cloning, before invoking this action?

[ytkg]

@segiddins Thanks for the feedback!

I considered that, but I wanted to avoid requiring the user to configure fetch-depth: 0 explicitly in their workflow. Since this action depends on tags for the release process, missing them (e.g. in default shallow clones) can result in errors like tag push conflicts.

By adding git fetch --tags in the action itself, the release becomes more robust and user-friendly — it "just works" without requiring extra setup on the user side.

That said, if the preference is to have users set fetch-depth: 0 instead, I can document that requirement clearly in the README and remove the fetch step.

Let me know what you'd prefer!

[segiddins]

Maybe we git fetch origin refs/tags/$TAG:refs/tags/$TAG to limit it to just the one? Or use the GitHub cli/api to check whether the tag exists? Being able to avoid a full checkout is a huge speedup when possible

[ytkg]

@segiddins Thanks for the suggestion!

I initially tried using git fetch origin refs/tags/$TAG:refs/tags/$TAG, but it turns out that internally this still fetches all tags — so it didn’t help reduce the fetch size in practice.

Instead, I found that git fetch --depth 1 works well for this case. It retrieves only the latest commit and its associated tags, which is sufficient for the release process and avoids the overhead of fetching the full history.

Would you be open to using git fetch --depth 1 instead?

[k0va1]

+1 for automatic fetching tags. I've bumped into the same error and couldn't understand what was wrong. I added fetch-tags: true to the checkout step to solve it

- uses: actions/checkout@v4
  with:
  fetch-tags: true

But it would be nice to make this workflow idempotent

[kulturbande]

To everybody who stumble accross that PR. A possible workaround would be to use another tagging pattern. Instead of x.y.z I used vx.y.z(e.g. v0.2.0 instead of 0.2.0). This fixed the Github action for me.

A successful release: https://github.com/sitediver/alchemy-mission_control-jobs/actions/runs/19404149753