Add automated RubyGems/crates.io publishing

[gjtorikian]

This PR is an attempt to make publishing to RubyGems and crates.io simpler and more secure.

Ultiamtely, both RubyGems and crates.io support Trusted Publishing. The idea is that rather than one individual using their own auth token to publish updates, the GitHub Actions workflow can request a short lived token from the provider, and use that to issue updates. This should make it simpler for newly merged PRs to be released across RubyGems, crates.io, and Dockerhub.

In the new release.yml here, I propose:

• a workflow dispatch with two inputs, prepare, and release.
• once a new version is ready to be released, one would go to the GitHub Actions UI and toggle the workflow with prepare: true
• this examines the new version number defined in gem/lib/rb_sys/version.rb, generates a CHANGELOG entry, and opens a PR
• the PR can be modified and merged at will

Afterwards:

• the same workflow is run with release: true
• this creates a new tag, pushes it, and publishes a GitHub release with that tag
• docker.yml recognizes the new tag, and pushes the images to Dockerhub
• as well, the publish_crates job triggers after the new release is made. this pushes rb-sys-build, waits for it to be indexed, then pushes rb-sys, to crates.io using OIDC
• once the crates are pushed, publish_gem publishes the gem using OIDC

There needs to be some configuration on the RubyGems and crates.io UI settings to "recognize" this workflow as the source of truth, but that ought to be it. This. brings along an audit trail for releases (via the GitHub Actions logs), credential rotation via OIDC, and supply chain security.

[ianks]

Cool with this in theory, i assume i need to input credentials somewhere?

[gjtorikian]

Yeah, the only credential needed is: role-to-assume: ${{ secrets.RUBYGEMS_OIDC_ROLE }}

You actually don't need to set this as a secret, RubyGems says it's fine to expose publicly.

[gjtorikian]

FWIW there are UI settings for both RubyGems and crates.io that you would need to configure (since you're the owner of those published packages); the links above provide more documentation on what to do there.

[gjtorikian]

bumping this!

[gjtorikian]

@ianks another bump.

even without setting up OIDC, you can store your rubygems key as a secret in this repo. point is, I think some sort of deploy automation is warranted.