Use Github Actions to release gems

In Voxpupuli we use this Github Action to release gems after a tag has been pushed:

I like this release because it makes it very easy to release. I’m proposing to apply the same to Foreman plugins where the owner is interested.

To deal with security, I’m proposing to create a new account on Rubygems (besides RubyGems.org | your community gem host) that is used only for this. Then we can opt-in. On this account we’ll create an API key and store it as a Github organization secret. Only repos that have opted in to it will be allowed to access the secret.

After it’s been set up, the workflow becomes:

  • Create a commit that bumps the version
  • Tag it
  • Push the tag
  • Github Actions starts and builds & releases the gem

On a technical level I can do all of this easily (I set it up in Voxpupuli) but do gem maintainers want this?

Technically we can also allow Katello to do the same (either with its own account or shared) but I don’t have permissions to set the org secret.

7 Likes

I can only speak for myself, but I want it.

1 Like

I would like this, but most of the repos I maintain have two gems inside and I don’t feel confident enough in my yaml+gh_actions-fu to ever trust that it would do the thing I want it to do. Still would be nice for the “regular” repos

It’s not too difficult to set up a matrix build for the release job. Granted, less trivial than copying an existing job but nothing special :slight_smile:

I haven’t forgotten about this. GitHub now has reusable workflows which should make this easier:

For an unrelated thing I already played with this (Reusable Github Actions) and I hope to get to this soon.

I’d really love this, tho there is still unresolved issue about MFA, as I’ve been reminded with a Rubocop rule Gemspec/RequireMFA, I’ve disabled it in https://github.com/theforeman/theforeman-rubocop/pull/6. Tho it’s another security compromise to be had for this.

But having a specialized account and hoping that plugin maintainers would use the MFA themselves would be good enough for me.

Do we have the releasing account yet? Or can I help setting it up? I’d love to set this up especially for less frequented releases, so I can give the power to release to the whole core team by tagging in the repository.

It took a while, but I’ve transferred my repository of reusable actions and added a release workflow:

I’d say it’s still experimental, hence the v0 version. Especially the Foreman workflows should be considered experimental.

Since it came up in the smart_proxy_dhcp_infoblox repo, I submitted it there first:

Rubygems allows creating an API key that can only push to a specific gem and I already set that up as a repository secret. This means that now effectively if you have git push access to that repository, you also have release access.

1 Like