copier-release is a compact Copier template for GitHub repositories that want a conventional-commit release loop without carrying release workflow boilerplate by hand.

• 🚀 Release PRs from main: calculates the next semantic version with git-cliff, writes CHANGELOG.md, bumps package.json when present, and opens a signed release-please/* pull request.
• 🏷️ GitHub Releases after merge: watches merged release PRs, creates the version tag, and publishes the GitHub Release from the PR body.
• 📌 Pinned release configuration: renders release-pr.yaml with a raw cliff.toml URL tied to the Copier-selected template revision.
• 🧹 Legacy cleanup: removes superseded release-please config and older release workflow names during generation.
• 🧩 Narrow responsibility: handles changelogs, tags, and GitHub Releases while leaving package publishing, artifacts, and deployment to the consuming repository.

copier copy --trust gh:liblaf/copier-release .

Generated repositories receive:

Generated repositories keep release-template answers in .config/copier/.copier-answers.release.yaml.

copier recopy --force --skip-answered --trust --answers-file '.config/copier/.copier-answers.release.yaml'

Repositories that also use copier-shared can update every configured template with the shared task:

mise run copier-update --skip-answered --trust --force

Create a GitHub Actions environment named release-please, then configure these repository or environment values:

• vars.APP_CLIENT_ID: the GitHub App Client ID from the app settings.
• secrets.APP_PRIVATE_KEY: a private key for the same GitHub App.

Those credentials are passed to liblaf/actions/auth so the workflows can open release PRs, push tags, and create GitHub Releases as a GitHub App. If a repository was configured for the older v1 workflow inputs, replace the numeric vars.APP_ID value with the app's Client ID in vars.APP_CLIENT_ID, and move or recreate secrets.PRIVATE_KEY as secrets.APP_PRIVATE_KEY before applying this template update.

1. Push Conventional Commits to main, such as feat:, fix:, docs:, or ci:.
2. release-pr.yaml calculates the next version and opens release-please/main when a release is needed.
3. Review and merge the release PR after CI is green.
4. release-publish.yaml tags the merged release commit and creates the GitHub Release.
5. Run project-specific publish, artifact, or deploy workflows from the consuming repository.

Use Conventional Commits for predictable version bumps and changelog grouping.

Ideas, fixes, and improvements are welcome. Open an issue or pull request if you want to refine the template, release workflow, or generated changelog format.

• Shared - shared automation for code quality, maintenance, and repository hygiene
• Python - a modern Python project template with tooling, docs, and CI
• Rust - a Rust template with cross-compilation, CI, and release automation
• TypeScript - a TypeScript template built around modern tooling and GitHub automation

Copyright © 2024 liblaf.
This project is MIT licensed.