Setting Up Release-Please
This skill guides you through setting up release-please in a repository.
Before You Start
Ask the user (if not clear from context):
- What language/framework? (determines
release-type) - Single package or monorepo?
- Current version of the package(s)?
Setup Steps
1. Create GitHub Actions Workflow
Create .github/workflows/release-please.yml:
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
name: release-please
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: googleapis/release-please-action@v4
with:
release-type: <type> # See references/release-types.mdUnified release-please + GoReleaser workflow (recommended when both are used)
If the project uses both release-please and GoReleaser, prefer a single workflow file. Run release-please first, then run GoReleaser only when release_created is true.
This avoids the common PAT workaround. You do not need a custom RELEASE_PLEASE_TOKEN just to trigger a second workflow for GoReleaser.
For the canonical recipe, see references/release-please-goreleaser-unified-workflow.md.
name: release-please
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
packages: write
jobs:
release-please:
runs-on: ubuntu-latest
outputs:
release_created: ${{ steps.release.outputs.release_created }}
tag_name: ${{ steps.release.outputs.tag_name }}
steps:
- id: release
uses: googleapis/release-please-action@v4
with:
release-type: <type>
goreleaser:
needs: release-please
if: ${{ needs.release-please.outputs.release_created == 'true' }}
runs-on: ubuntu-latest
permissions:
contents: write
packages: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
ref: ${{ needs.release-please.outputs.tag_name }}
- uses: actions/setup-go@v5
with:
go-version-file: go.mod
- uses: goreleaser/goreleaser-action@v6
with:
version: latest
args: release --clean
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}If the user needs CI to run on release PRs (common), they need a PAT for that PR-triggering behavior:
with:
token: ${{ secrets.RELEASE_PLEASE_TOKEN }}Do not use this PAT requirement as the default fix for release-please + GoReleaser integration. Prefer the unified single-workflow pattern above.
2. Create Config Files (for advanced setups)
For monorepos or custom config, create manifest files instead of using release-type input.
release-please-config.json:
{
"packages": {
".": {
"release-type": "<type>"
}
}
}.release-please-manifest.json:
{
".": "<current-version>"
}Then update the workflow to omit release-type:
- uses: googleapis/release-please-action@v4
with:
token: ${{ secrets.RELEASE_PLEASE_TOKEN }}3. Bootstrap Existing Repository
For repos with existing releases, set the current version in .release-please-manifest.json to match the latest release tag.
If there's extensive commit history, add bootstrap-sha to config to limit changelog scope:
{
"bootstrap-sha": "<commit-sha-before-first-desired-commit>",
"packages": { ... }
}Common Setup Patterns
Node.js Package
release-type: node- Updates
package.jsonandCHANGELOG.md
Python Package
release-type: python- Updates
pyproject.toml/setup.pyandCHANGELOG.md
Go Module
release-type: go- Updates
CHANGELOG.mdonly (version from tags)
Monorepo
- Use manifest config with multiple packages
- Consider
node-workspaceorcargo-workspaceplugins - See
references/manifest-config.md
Post-Setup Checklist
Tell the user:
- Commit and push the new files
- Start using conventional commits:
feat:,fix:,feat!: - Use squash-merge for PRs (cleaner changelogs)
- Release-please will create a Release PR after releasable commits
- Merge the Release PR to create the GitHub release
Reference Files
Read these for detailed options:
references/release-types.md- All supported languagesreferences/github-actions.md- Action inputs, outputs, examplesreferences/manifest-config.md- Full config options, plugins, monoreposreferences/release-please-goreleaser-unified-workflow.md- Canonical combined setup for release-please + GoReleaser