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)

[aurelien-reeves]

Some feedback after having released cucumber-ruby-core, cucumber-ruby-wire and cucumber-ruby using the new release process, the one with a single push on a dedicated release/vX.Y.Z branch.

First of all, it worked as expected. It was pretty smooth 🤩

In short:

• we prepare the release as usual (preparation of the changelog, update of the gemspec, ...)
• push a "Release" commit to main
• then we can push the main branch to a dedicated release/vX.Y.Z branch. That will trigger a dedicated workflow which will release the new version.

The workflow has been copied from cucumber-expressions, and it has been tweaked:

• I have added a check to make sure what we were about to release was pushed on main before (https://github.com/cucumber/cucumber-ruby/blob/main/.github/workflows/release.yml#L10)
• I have added the execution of the tests before publishing the gem (https://github.com/cucumber/cucumber-ruby/blob/main/.github/workflows/release.yml#L22). That may slow-down the process, but it make it far more safer.

Also, as the repos have a single implementation, there was a single release workflow with the publication of the ruby gem, then the creation of the release on github. That may not be as simple with repos with multiple languages.

As an attempt of factorization, I have created an action to execute the tests, and use that action as part of the test workflow and the release workflow.

I don't know how far we could factorize the process. There are some redundancy across the repositories, but I am not sure this is because of duplication. We could maybe create a precheck action, but other jobs are already pretty well factorized into their own dedicated actions. What we have to take care of is: if we tweak the release for a repository, we may have to update it for other repositories as well.

Also as @aslakhellesoy pointed out, the RELEASING.md document could be standardized.

I am pretty confident with that process. BUT, there is a point we have to be extra careful: the security of the process rely on github settings: the protection of release/* branches, and the associated "Release" environment. If an option in those settings is missed, some secrets could be compromised.

[aslakhellesoy]

@mattwynne @aurelien-reeves can we close this now and have smaller tickets for the remaining projects?

[mattwynne]

Tracking continued progress at https://github.com/orgs/cucumber/projects/13