search

cucumber / cucumber-ruby-wire

Wire protocol plugin for Cucumber
MIT License
7 stars 11 forks source link

Release v6.1.0 #48

Closed github-actions[bot] closed 3 years ago

github-actions[bot] commented 3 years ago

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.

aurelien-reeves commented 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.

mattwynne commented 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.

Try #49! I don't have time to debug it this afternoon, but in theory it should work.

mattwynne commented 3 years ago

@luke-hill

luke-hill commented 3 years ago

All of these commits have been done by yourself though? I'm still a bit confused (Sorry if being an idiot).

mattwynne commented 3 years ago

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?

luke-hill commented 3 years ago

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?

mattwynne commented 3 years ago

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

luke-hill commented 3 years ago

Should those 2 things be reversed? i.e. first make a release then build and publish the gem?

mattwynne commented 3 years ago

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?

luke-hill commented 3 years ago

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?