build: add release-please action for releasing to RubyGems #14
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.
In this commit we set up the google-github-actions/release-please-action, which uses googleapis/release-please under the hood.
This enables automatic deployment and versioning, and all you have to do is have good commit messages 😉
All jokes aside, the real power of this action can be achieved when you use conventional commits. Luckily there are only 2 important prefixes (3 if you want consistency)
feat:
: commit messages prefixed withfeat:
will cause the action to create a minor version release PR for you to review.fix:
: prefixing withfix:
will create a patch upgradechore:
is the same as not doing any prefix. It is basically a way to say it does not affect the core library code.Lastly, if you add a
!
forfeat!:
, and same withfix
, it is seen as a breaking change and will create a major version release.To be clear, you don't actually have to change your commit message patterns to use this. There are other ways to tell the action what version it should be bumping to but this won't generate a good changelog for you, and it may lead to not adhering as strictly to SEMVER.
To release with a different version than the one the PR is currently for, you can add a commit with the following in the Body:
source
If you wanted to get the Changelog correct, you also have the option to modify old commit message bodies with a special block of text that the action will see and update your changelog accordingly.
Once you understand it, you will likely never have to change it again. A little behavior change upfront is imo an amazing tradeoff for never having to remember how to release the gem 2 odd years later.
BUT it's not for everyone so 🔥burn it with fire🔥 if it doesn't work for you 🙂