Automate releases

[mattwynne]

Using this issue to bring together the efforts scattered across other repos.

The goal is to have all releases to RubyGems, NPM, Maven etc. made by GitHub Actions workflows. We'll use GitHub Environments to secure the secrets used to publish packages.

• cucumber/build Automate releases build#42
• cucumber/cucumber-ruby-wire Add release workflow for automating releases of the gem cucumber-ruby-wire#49
• factor out a publish-rubygem action
• factor out a versions action to read the changelog latest and tagged release versions
• factor out a create-release action. WIP in https://github.com/cucumber-actions/create-release
• review all instances of release workflows and ensure they're using the latest versions of our actions
• archive get-released-version action which is superseded by the new versions action.
• cucumber/cucumber-expressions Automate releases #1688
• cucumber-ruby-core: Add release workflow cucumber-ruby-core#224
• cucumber-ruby: Add a release workflow cucumber-ruby#1567
• cucumber-parent: Automate releases cucumber-parent#32
• create a publish-go action
• create a check-release-commit-is-on-main action (see here
• factor out RELEASING.md to try having a single one compatible with all the repos
  • script or automate the bump of the version numbers into package descriptors
  • extract update of gemspec of the release process, or document it as a generic process as part of the release one

[mattwynne]

Today I factored out a https://github.com/cucumber-actions/create-release-pr/ action which will cut a lot of the boilerplate out of adding a pre-release.yaml workflow to a new project.

[mattwynne]

The current strategy to mark the commit to be released with a temporary pre-release/* branch is a bit fragile as, if that branch is deleted before the release is made, we don't know what commit to tag.

Maybe the pre-release script needs to make a "Draft" Release (and a tag), then we can just publish that Release when we make the actual release.

[mattwynne]

We can pull out the sha of the commit being released like this:

url=$(gh pr list --state closed --base release/v0.8.0 --json url | jq -r '.[0].url')
sha=$(gh pr view $url --json commits --jq '.commits[-1].oid')

That should work even if the pre-release/* branch has been deleted.

[mattwynne]

I've sketched out a repo for a create-release action where we can properly test the different scenarios around tagging release commits. It's not finished yet. https://github.com/cucumber-actions/create-release

[aslakhellesoy]

We now have a working GitHub Actions release workflow in cucumber/cucumber-expressions

Preparing a release is still a bit too manual for my liking. Things I'd like to improve:

• Make it easier for people to install the changelog tool. We can improve the existing goreleaser config so that people can install it with various package managers.
• Provide a scripts/prepare-release script that runs changelog release ..., updates the package descriptors and pushes to github.

Now that we're splitting up common into more and more repos, I think each repo will need a RELEASING.md file and a scripts/prerelease script. I also think they will be the same. So we should look into a solution where we can maintain common files in a single repo and easily sync them to select repos.

[aurelien-reeves]

I must say that once it is working, I find the release process pretty smooth. I like it a lot.

I see two things we could improve:

• we could very easily push the release commit only on the release branch and never on the main branch: maybe we could make sure the commit we are about to release exists on the main branch
• also we could very easily release a non working module. I think we should run the tests before the publication of the modules, even if tests have already been executed on the main branch. Actually nothing prevent us to push non working stuff on the release branch right now

[mattwynne]

* Provide a `scripts/prepare-release` script that runs `changelog release ...`, updates the package descriptors and pushes to github.

gh lets us trigger workflow_dispatch events to run arbitrary workflows with parameters, so we could probably bundle this script as a GH action and then use something like this to trigger it:

gh workflow run pre-release.yaml -f next-version=2.0.0

WDYT?

[aurelien-reeves]

What would be the value to use a workflow over a local script?

[aslakhellesoy]

The main benefit would be that we don’t have to install the changelog script locally.

we also wouldn’t have to copy-paste the pre-release script across multiple repos (but we’d still have to enable the action for each repo)

[aurelien-reeves]

I have added some TODOs following the comments here: cucumber/cucumber-ruby-core#224 (comment)