fix: release please configs - #36
Closed
Stromweld wants to merge 6 commits into
Closed
Conversation
Signed-off-by: Corey Hemminger <hemminger@hotmail.com>
Signed-off-by: Corey Hemminger <hemminger@hotmail.com>
Stromweld
marked this pull request as draft
July 1, 2024 21:54
tas50
added a commit
that referenced
this pull request
Aug 22, 2026
Releases were entirely manual, and 1.0.0 -- which makes the driver work with modern Test Kitchen again -- is sitting unreleased on main while RubyGems still serves the broken 0.24.0. This adopts the same release-please setup the other test-kitchen drivers use, so merges to main open a release PR and merging that one tags the release and publishes the gem to RubyGems and GitHub Packages. The required PORTER_GITHUB_TOKEN, OWNER and RUBYGEMS_API_KEY secrets are already available to this repository at the organisation level. Taken from Corey Hemminger's earlier work in #36, with the action versions brought up to what kitchen-ec2 currently runs (release-please-action v5 and checkout v7 rather than v4). Two changes from the version kitchen-ec2 runs, both to avoid handing publishing credentials to code that can change underneath us: - Actions are pinned to commit SHAs rather than tags or branches. The two actionshub publish actions were referenced as @main, so whoever can push to those branches could change what runs with RUBYGEMS_API_KEY at any time. The version each SHA corresponds to is kept in a trailing comment, which is what Renovate reads to update them. - The workflow declares explicit permissions. This repository defaults workflow tokens to write, so without a permissions block the publish steps would run with a broadly scoped GITHUB_TOKEN. The manifest starts at 0.24.0, the last version actually published, and the Release-As footer below tells release-please to cut the next release as 1.0.0 to match the version already committed in cloudstack_version.rb and CHANGELOG.md. Release-As: 1.0.0 Co-authored-by: Corey Hemminger <hemminger@hotmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
tas50
added a commit
that referenced
this pull request
Aug 22, 2026
Releases were entirely manual, and 1.0.0 -- which makes the driver work with modern Test Kitchen again -- is sitting unreleased on main while RubyGems still serves the broken 0.24.0. This adopts the same release-please setup the other test-kitchen drivers use, so merges to main open a release PR and merging that one tags the release and publishes the gem to RubyGems and GitHub Packages. The required PORTER_GITHUB_TOKEN, OWNER and RUBYGEMS_API_KEY secrets are already available to this repository at the organisation level. Taken from Corey Hemminger's earlier work in #36, with the action versions brought up to what kitchen-ec2 currently runs (release-please-action v5 and checkout v7 rather than v4). Two changes from the version kitchen-ec2 runs, both to avoid handing publishing credentials to code that can change underneath us: - Actions are pinned to commit SHAs rather than tags or branches. The two actionshub publish actions were referenced as @main, so whoever can push to those branches could change what runs with RUBYGEMS_API_KEY at any time. The version each SHA corresponds to is kept in a trailing comment, which is what Renovate reads to update them. - The workflow declares explicit permissions. This repository defaults workflow tokens to write, so without a permissions block the publish steps would run with a broadly scoped GITHUB_TOKEN. The manifest starts at 0.24.0, the last version actually published, and the Release-As footer below tells release-please to cut the next release as 1.0.0 to match the version already committed in cloudstack_version.rb and CHANGELOG.md. Release-As: 1.0.0 Co-authored-by: Corey Hemminger <hemminger@hotmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
|
I picked this up in #47 rather than rebasing here, since main moved on with #44 and #46 and this branch had gone into conflict. #47 is your config and workflow, with the action versions bumped to what kitchen-ec2 runs now (v5 and v7 rather than v4) and pinned to SHAs after a security review flagged the two actionshub Thanks for setting this up, it is what is getting 1.0.0 out. |
This file contains hidden or 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
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.
Description
add release please configs to support the latest version
Issues Resolved
List any existing issues this PR resolves, or any Discourse or
StackOverflow discussions that are relevant
Type of Change
Our release process assumes you are using Conventional Commit messages.
The most important prefixes you should have in mind are:
_fix_: which represents bug fixes, and correlates to a SemVer patch._feat_: which represents a new feature, and correlates to a SemVer minor._feat!_:, orfix!:,refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a major version change.If you have not included a conventional commit message this can be fixed on merge.
Check List