GitHub Actions and automated release

[Pat Brisbin]

We should migrate from Circle to GitHub Actions. I've been doing this across all of my projects and have been very happy. I can go into the things I like about it if necessary, but really it's just all around better.

Once in Actions, we will have more options for automating release. A GitHub Action can easily make and push more commits, tag, etc. We could certainly do this in Circle, but it'd be much more cumbersome.

There are a few auto-release strategies to choose from:

• Release on tag

  When main is ready for a new release, someone must push a tag matching v*. An Action can react to this and do everything required to make and publish a release with that version. We can decide which activities must be done ahead of time (e.g. locale stuff), and we may start with lots of activities still done ahead of time, but we should seek to move those activities to the Action itself. Ultimately, we want to handle the interesting stuff, the actual code changes, and leave everything else to the automation.

• Release on version-bump commit to main

  I do this in my Haskell libraries. Basically something in the code denotes a version. In Haskell it's in package.yaml, in this repository I guess it's a variable in the source itself. When you're ready to release you do everything you need to and then change that version in a PR, get review and merge. The Action will see that and check for existence of a tag by that version. If one doesn't exist, it creates it, then does everything required publish the release. This way, you control when releases happen and to what version, but you still only have to push a "version bump" to main to trigger things. This works well when a version-bump PR should also include other things worth reviewing, such as a hand-written CHANGELOG.

• Release on every commit to main

  This is the most automated, you just work and work, and releases happen without you even realizing. The problem is you have to buy into making Conventional Commits: "fix: this", "feature: that". That way, the automation can use the commit log to decide how to increment the version, and does so, on every push to main.

  I'm not doing this personally on any projects. I'm a little put off by having to reword my commit messages (something I care about doing well) to satisfy tooling. However, I am intrigued and would be happy to try it if others on the project want to.

/cc @atreyasha

[Atreya Shankar]

Thanks for suggesting and summarizing this. I have not used GitHub actions in my projects before, but I am open to learning and seeing how/if they will improve our workflows. Given the three strategies, I would be more comfortable with the first two; just because they comply well with our general release cycle and style.

However, I do have some qualms for which I would like to get your opinions:

1. Based on our PR Template, most of the actions required for PR's and releases are IMO not fully automatable. Most, if not, all tasks require some kind of manual intervention; so I don't see how GitHub actions can be used for these. Also I would not be comfortable delegating these tasks to a service, i.e. I would like to have full control of these tasks.

2. The only fully automatable task that I can see if the release to AUR. But even this has issues. For one, each AUR account can only host one SSH public key. This would mean that we would either need to share our private SSH key with the GitHub service (eek), or create a new dedicated AUR account for the GitHub service (ugh).

Sorry for my pessimism on this. I am just starting to get comfortable with our release workflow, and am a bit reluctant towards a major change.

[Pat Brisbin]

Sorry for my pessimism on this. I am just starting to get comfortable with our release workflow, and am a bit reluctant towards a major change.

No need to apologize. I consider this more and more your project, so I fully respect this position. Let's just start with a direct translation of what's happening in Circle to GitHub Actions. Then we can take small steps from there, if you want.

[Atreya Shankar]

Let's just start with a direct translation of what's happening in Circle to GitHub Actions. Then we can take small steps from there, if you want.

Sounds good :)