Unclear what release workflow changes to if using bundler's `rake release`

[technicalpickles]

I'm used to using rake release on the main branch when going to release. That handles the git tag and gem push.

If I do rake release first, it would end up pushing a tag, and then publishing. If I'm using the v* tag to push to gem, wouldn't it end up trying to push a gem that exists?

[technicalpickles]

Here's what happened after using a dispatch workflow after rake release:

Run bundle exec rake release
singed 0.2.2 built to pkg/singed-0.2.2.gem.
Tagged v0.2.2.
Pushed git commits and release tag.
Pushing gem to https://rubygems.org.../
Repushing of gem versions is not allowed.
Please bump the version number and push a new different release.
See also `gem yank` if you want to unpublish the bad release.

I am wondering if rake release should just be triggering a github action to git tag and push the gem?

[technicalpickles]

I looked at the output more closely, and the github action is eventually doing rake release 😅 Seems is possible to gh workflows run push_gem.yml, as the way to trigger it locally.

[hlascelles]

I'm in exactly the same boat as you, this was unclear.

In the end, I have added a slightly modified workflow to my gems which detects a change to the version.rb and performs both gem creation and push, and GitHub Actions Release create.

So my flow is now:

1. Create a feature branch, get it passing, merge to master.
2. Create a PR which is just "cut gem v1.2.3" which changes version.rb, merge to master.

That's it, everything else is auto.

If you are pretty confident about a change, you can do feature change and version bump in one PR.

My workflow is here: https://github.com/hlascelles/dememoize/blob/master/.github/workflows/push_gem.yml
Example pushed gem: https://rubygems.org/gems/dememoize/versions/0.1.2 (notice the Provenance)
Example GitHub Actions release: https://github.com/hlascelles/dememoize/releases/tag/untagged-70fb41bb77cc158791f4