Release v6.1.0 #48
Merged
Release v6.1.0 #48
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
* Update dependencies to work with dedicated branch of cucumber * Add the registry in the AfterConfiguration hook * Update features to load cucumber/wire as part of the tests * Allow usage with future version of cucumber-ruby
Finally, the deprecation will happen in a cucumber v8.0.0 and removed in v9.0.0 due to breaking changes.
|
Note: as there is no |
Try #49! I don't have time to debug it this afternoon, but in theory it should work. |
* Add release workflow for automating releases of the gem * Use bare metal `gem` commands to publish Why? * reduced security exposure * let the `gh release` command create the tag * simpler * Narrow scope of GITHUB_TOKEN * Simplfy how we handle the version number to be released * Use environment variable to pass API key to `gem push` See https://guides.rubygems.org/command-reference/ * Ping the core team to review a release PR * Update docs about how to release
|
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 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? |
mattwynne
added a commit
that referenced
this pull request
Aug 13, 2021
* Release v6.1.0 (#48) * Remove cucumber dependency to wire (#46) * Update dependencies to work with dedicated branch of cucumber * Add the registry in the AfterConfiguration hook * Update features to load cucumber/wire as part of the tests * Allow usage with future version of cucumber-ruby * Emphase 'built-in' in UPGRADING documentation * Setup github workflow * Remove windows from GH Workflow * Remove jruby from GH Workflow * Schedule GH workflow at 5am every day * [skip ci]Rename GH workflow * Use quotes with ruby 3.0 * Make the changelog more parseable * Remove circle-ci (#47) * Add pre-release workflow * Prepare release 6.1.0 * Reformat CHANGELOG.md to match `changelog` tool format See https://github.com/rcmachado/changelog * Move changelog-action to cucumber-actions org * Delegate to cucumber-actions/get-released-version * Simplifyy We don't have "v"s in CHANGELOG headers to no need to clean up * Fix release label for cucumber-actions/get-released-version * Update UPGRADING.md Finally, the deprecation will happen in a cucumber v8.0.0 and removed in v9.0.0 due to breaking changes. * Update GH Workflow to reduce chances of flaky jobs * Fix GH Workflow * Add release workflow for automating releases of the gem (#49) * Add release workflow for automating releases of the gem * Use bare metal `gem` commands to publish Why? * reduced security exposure * let the `gh release` command create the tag * simpler * Narrow scope of GITHUB_TOKEN * Simplfy how we handle the version number to be released * Use environment variable to pass API key to `gem push` See https://guides.rubygems.org/command-reference/ * Ping the core team to review a release PR * Update docs about how to release Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com> Co-authored-by: Matt Wynne <matt@cucumber.io> * See if this helps the release workflow to trigger I don't see the difference, but it's what we have in the one on cucumber/build * Separate gem build and gem push Try adding specific gem name to gem build command * Create GitHub Release after gem push has succeeded * Use a newer Ruby In the hope that it will install a newer version of RubyGems that respects the GEM_HOST_API_KEY env var * Create title for GH Release Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com>
There's a That script does two things: 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 58f36b0 |
|
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? |
aurelien-reeves
added a commit
that referenced
this pull request
Aug 27, 2021
* Final iterations on release script (#51) * Release v6.1.0 (#48) * Remove cucumber dependency to wire (#46) * Update dependencies to work with dedicated branch of cucumber * Add the registry in the AfterConfiguration hook * Update features to load cucumber/wire as part of the tests * Allow usage with future version of cucumber-ruby * Emphase 'built-in' in UPGRADING documentation * Setup github workflow * Remove windows from GH Workflow * Remove jruby from GH Workflow * Schedule GH workflow at 5am every day * [skip ci]Rename GH workflow * Use quotes with ruby 3.0 * Make the changelog more parseable * Remove circle-ci (#47) * Add pre-release workflow * Prepare release 6.1.0 * Reformat CHANGELOG.md to match `changelog` tool format See https://github.com/rcmachado/changelog * Move changelog-action to cucumber-actions org * Delegate to cucumber-actions/get-released-version * Simplifyy We don't have "v"s in CHANGELOG headers to no need to clean up * Fix release label for cucumber-actions/get-released-version * Update UPGRADING.md Finally, the deprecation will happen in a cucumber v8.0.0 and removed in v9.0.0 due to breaking changes. * Update GH Workflow to reduce chances of flaky jobs * Fix GH Workflow * Add release workflow for automating releases of the gem (#49) * Add release workflow for automating releases of the gem * Use bare metal `gem` commands to publish Why? * reduced security exposure * let the `gh release` command create the tag * simpler * Narrow scope of GITHUB_TOKEN * Simplfy how we handle the version number to be released * Use environment variable to pass API key to `gem push` See https://guides.rubygems.org/command-reference/ * Ping the core team to review a release PR * Update docs about how to release Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com> Co-authored-by: Matt Wynne <matt@cucumber.io> * See if this helps the release workflow to trigger I don't see the difference, but it's what we have in the one on cucumber/build * Separate gem build and gem push Try adding specific gem name to gem build command * Create GitHub Release after gem push has succeeded * Use a newer Ruby In the hope that it will install a newer version of RubyGems that respects the GEM_HOST_API_KEY env var * Create title for GH Release Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com> * CI: Refer to cucumber-actions/ Action (#50) I learned that the repo had been transferred from the mattwynne/ prefix to the cucumber-actions/ one. This change makes the usage uniform in this YAML file. Co-authored-by: Matt Wynne <matt@cucumber.io> * Ensure release notes can contain backticks * Upgrade release script to use the new publish-rubygem action * Upgrade pre-release script to use new create-release-pr action * Ensure we tag the right commit when we release * CI: Fix comment typo * Use IntallPlugin rathern than AfterConfiguration hook (#52) * Use IntallPlugin rathern than AfterConfiguration * Avoid usage of InstallPlugin if it is not defined * Release 6.1.1 * Fix pre-release workflow Co-authored-by: Matt Wynne <matt@cucumber.io> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
aurelien-reeves
added a commit
that referenced
this pull request
Aug 27, 2021
* Final iterations on release script (#51) * Release v6.1.0 (#48) * Remove cucumber dependency to wire (#46) * Update dependencies to work with dedicated branch of cucumber * Add the registry in the AfterConfiguration hook * Update features to load cucumber/wire as part of the tests * Allow usage with future version of cucumber-ruby * Emphase 'built-in' in UPGRADING documentation * Setup github workflow * Remove windows from GH Workflow * Remove jruby from GH Workflow * Schedule GH workflow at 5am every day * [skip ci]Rename GH workflow * Use quotes with ruby 3.0 * Make the changelog more parseable * Remove circle-ci (#47) * Add pre-release workflow * Prepare release 6.1.0 * Reformat CHANGELOG.md to match `changelog` tool format See https://github.com/rcmachado/changelog * Move changelog-action to cucumber-actions org * Delegate to cucumber-actions/get-released-version * Simplifyy We don't have "v"s in CHANGELOG headers to no need to clean up * Fix release label for cucumber-actions/get-released-version * Update UPGRADING.md Finally, the deprecation will happen in a cucumber v8.0.0 and removed in v9.0.0 due to breaking changes. * Update GH Workflow to reduce chances of flaky jobs * Fix GH Workflow * Add release workflow for automating releases of the gem (#49) * Add release workflow for automating releases of the gem * Use bare metal `gem` commands to publish Why? * reduced security exposure * let the `gh release` command create the tag * simpler * Narrow scope of GITHUB_TOKEN * Simplfy how we handle the version number to be released * Use environment variable to pass API key to `gem push` See https://guides.rubygems.org/command-reference/ * Ping the core team to review a release PR * Update docs about how to release Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com> Co-authored-by: Matt Wynne <matt@cucumber.io> * See if this helps the release workflow to trigger I don't see the difference, but it's what we have in the one on cucumber/build * Separate gem build and gem push Try adding specific gem name to gem build command * Create GitHub Release after gem push has succeeded * Use a newer Ruby In the hope that it will install a newer version of RubyGems that respects the GEM_HOST_API_KEY env var * Create title for GH Release Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Aurélien Reeves <aurelien.reeves@smartbear.com> * CI: Refer to cucumber-actions/ Action (#50) I learned that the repo had been transferred from the mattwynne/ prefix to the cucumber-actions/ one. This change makes the usage uniform in this YAML file. Co-authored-by: Matt Wynne <matt@cucumber.io> * Ensure release notes can contain backticks * Upgrade release script to use the new publish-rubygem action * Upgrade pre-release script to use new create-release-pr action * Ensure we tag the right commit when we release * CI: Fix comment typo * Use IntallPlugin rathern than AfterConfiguration hook (#52) * Use IntallPlugin rathern than AfterConfiguration * Avoid usage of InstallPlugin if it is not defined * Release 6.1.1 * Fix pre-release workflow Co-authored-by: Matt Wynne <matt@cucumber.io> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
mainbranch and this PR will be automatically updated.