Closed github-actions[bot] closed 3 years ago
Note: as there is no release
workflow yet, merging this will do nothing, the release will still have to be done manually.
Note: as there is no
release
workflow yet, merging this will do nothing, the release will still have to be done manually.
Try #49! I don't have time to debug it this afternoon, but in theory it should work.
@luke-hill
All of these commits have been done by yourself though? I'm still a bit confused (Sorry if being an idiot).
All of these commits have been done by yourself though? I'm still a bit confused (Sorry if being an idiot).
I'm not sure I understand.
This PR contains all the commits since the last release. When I merged the PR into the release/v6.1.0
branch, that triggered another workflow to build and release the gem as of the last of these commits.
Does that help?
I have spotted the auto-tag here: https://github.com/cucumber/cucumber-ruby-wire/releases/tag/v6.1.0 (Although the notes on that are very weird).
Did that then also push the rubygem?
I have spotted the auto-tag here: https://github.com/cucumber/cucumber-ruby-wire/releases/tag/v6.1.0 (Although the notes on that are very weird).
Did that then also push the rubygem?
There's a release
workflow that kicks in when the PR is merged into the release/*
branch: https://github.com/cucumber/cucumber-ruby-wire/blob/main/.github/workflows/release.yaml
That script does two things:
1) Build and publish the gem 2) Create a GitHub Release
You're right about the release notes looking weird. There was a bug with the script that scrubbed out any text in the release notes that was in backticks. I've fixed that in 58f36b08d61777f6533bfe81e11e85fc4707c8f5
Should those 2 things be reversed? i.e. first make a release then build and publish the gem?
Good question @luke-hill, I'm not sure.
My thinking was that the gem publishing step was more likely to fail (e.g. if RubyGems was down, or the API key was invalid) and that if that happened, we wouldn't want to create a Release.
What was your thought about swapping them around?
That's traditionally the way releases are done (You cut the release version then release it), otherwise you're releasing a checkpoint that isn't set. It's the way I do it in all other repos, but I suppose it's not a big deal.
If that fails then you just try again logically right? It shouldn't be down for long?
Auto-generated by the pre-release.yaml workflow, because the CHANGELOG.md file contains a header for v6.1.0.
The latest git tag is v6.0.1, so it looks like a release is needed.
Review this PR carefully. When it's merged, the v6.1.0 release will happen automatically.
If you need to make changes to this release, just push more commits to the
main
branch and this PR will be automatically updated.