Closed mattwynne closed 3 years ago
It looks really promising to me :)
We may have to add some required checks on the release/*
branches to make sure tests have passed well
Looking at the code. A branch release/v3_1 would release a version 3.1? Or do we need some sanitizer to convert underscores to dots?
pre-release/*
and release/*
branches would be named properly by the workflows: pre-release/v3.1.0
and release/v3.1.0
.
And actually, the release version number would be read from the changelog file.
@luke-hill the pre-release workflow we added a couple of days ago (https://github.com/cucumber/cucumber-ruby-wire/blob/main/.github/workflows/pre-release.yml) creates those branches automatically.
It does assume we use a sensible version number in the CHANGELOG heading; there's currently no validation on that.
As part of this PR, could we update the release process documentation too?
Good point! Done.
I had to make a few more manual tweaks to get it to work, which I merged back into main
in fc5a1aa82a2e9a06e735019540f2724cb237217f
Hopefully we should be good for next time!
Cheers @mattwynne for explanation. Can you tag me in the first auto-pr.
I've added a
Release
environment with theRUBYGEMS_API
secret in it needed by this workflow. Access to run workflows in that environment is restricted to members of the @cucumber/cucumber-ruby team. Effectively, that means they are the only people who can make releases, and the only people who could leak this secret.I generated a new API token in rubygems specifically for this repo, and copied it directly into GitHub, so there is no copy of that secret anywhere else.
The CUKEBOT_GITHUB_TOKEN (needed by the Rubygems rake release task to push the new tag) is a copy of the one from Keybase.