Automate releases with Conventional Commit Messages.
-
If you haven't already done so, create a
.github/workflows
folder in your repository (this is where your actions will live). -
Now create a
.github/workflows/release-please.yml
file with these contents:on: push: branches: - main name: release-please jobs: release-please: runs-on: ubuntu-latest steps: - uses: GoogleCloudPlatform/release-please-action@v2.0.0 with: token: ${{ secrets.GITHUB_TOKEN }} release-type: node package-name: release-please-action
-
Merge the above action into your repository and make sure new commits follow the Conventional Commits convention, release-please will start creating Release PRs for you.
input | description |
---|---|
token |
A GitHub secret token, you will most likely want to use the special secrets.GITHUB_TOKEN |
release-type |
What type of project is this a release for? Reference Release types supported; new types of releases can be added here |
package-name |
A name for the artifact releases are being created for (this might be the name field in a setup.py or package.json ) |
bump-minor-pre-major |
Should breaking changes before 1.0.0 produce minor bumps? Default No |
--path |
create a release from a path other than the repository's root |
--monorepo-tags |
add prefix to tags and branches, allowing multiple libraries to be released from the same repository. |
output | description |
---|---|
release_created |
true if the release was created, false otherwise |
upload_url |
Directly related to Create a release API |
tag_name |
Directly related to Create a release API |
Release Please automates releases for the following flavors of repositories:
Release Please automates CHANGELOG generation, the creation of GitHub releases, and version bumps for your projects. Release Please does so by parsing your git history, looking for Conventional Commit messages, and creating release PRs.
Rather than continuously releasing what's landed to your default branch, release-please maintains Release PRs:
These Release PRs are kept up-to-date as additional work is merged. When you're ready to tag a release, simply merge the release PR.
Release Please 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 SemVer major.
With a few additions, the Release Please action can be made to publish to npm when a Release PR is merged:
on:
push:
branches:
- main
name: release-please
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: GoogleCloudPlatform/release-please-action@v2.0.0
id: release
with:
token: ${{ secrets.GITHUB_TOKEN }}
release-type: node
package-name: test-release-please
# The logic below handles the npm publication:
- uses: actions/checkout@v2
# these if statements ensure that a publication only occurs when
# a new release is created:
if: ${{ steps.release.outputs.release_created }}
- uses: actions/setup-node@v1
with:
node-version: 12
registry-url: 'https://registry.npmjs.org'
if: ${{ steps.release.outputs.release_created }}
- run: npm ci
if: ${{ steps.release.outputs.release_created }}
- run: npm publish
env:
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}}
if: ${{ steps.release.outputs.release_created }}
So that you can keep 2FA enabled for npm publications, we recommend setting
registry-url
to your own Wombat Dressing Room deployment.
Apache Version 2.0