Add instructions on how to release a gem in MAINTAINING.md

[willnet]

I released a new gem myself and confirmed that bundle exec rake release works, so I added that to MAINTAINING.md.
I’m not sure what exactly should go in this TODO section, so for now I only wrote what I could.

[brendon]

Looks good. I didn't realise GitHub releases was a manual process. I assume there are ways to automate this along with the gem release task?

[brendon]

There is this as an option too: https://github.com/rubygems/release-gem

[joshbuker]

@willnet I think the todo was for stuff like how to push with MFA enabled on rubygems, and maybe switching to a CI style release pattern like @brendon suggested with the release-gem GitHub action.

Ideally, I'd like to have CI confirm that everything is set correctly (Sorcery::VERSION, primarily), then auto push the gem when creating a new release via GitHub releases.

[brendon]

Hopefully we all have MFA enabled on the rubygems side? I use the fingerprint sensor which does require following a link from the command line but it's not that bad.

[joshbuker]

Yes, I'm pretty MFA is required for all Sorcery maintainers on RubyGems. I was referring more to the step of actually passing the MFA code while pushing the gem via CLI.

[brendon]

Yes, I'm pretty MFA is required for all Sorcery maintainers on RubyGems. I was referring more to the step of actually passing the MFA code while pushing the gem via CLI.

True, I think it's probably pretty self explanatory as the CLI makes it pretty clear what it wants. At least for the key url, from memory the OTC request is a bit more terse.

[willnet]

@joshbuker @brendon I tried introducing rubygems/release-gem in a few gems that I maintain, and it’s really convenient. If you make a workflow like ci_logger/.github/workflows/push_gem.yml at main · willnet/ci_logger, you can release to rubygems.org and create a GitHub Release at the same time through it. I’d like to apply this setup to Sorcery as well.

However, if we use this workflow as-is, anyone who can run the workflow will also be able to release. So compared to now, the number of people who can release will probably increase. And if more people can release, the takeover risk goes up as well.

As a way to reduce the risk, we can use GitHub’s built-in feature called environment. By creating an environment, we can add restrictions like requiring approval before the workflow can proceed.

In my personal opinion, it would be good to switch to releasing via release-gem, and require one approval from someone other than the person who started the workflow for releases. What do you think? I’d like to hear your opinions.

[brendon]

That sounds promising @willnet. I'm happy with that approach provided the settings aren't able to be accidentally changed in the future without someone realising the consequences? I'll defer to @joshbuker.

[joshbuker]

Considering the low volume of releases, and relative ease using the manual process, I don't think the risk of automating releases is worth removing the minor work of manually pushing the gem.

Personally, I would stick with manual releases and avoid a whole host of security risks.