Custom tag format
Using a non-default tagFormat pattern.
Full config for a repo that tags releases as release/v1.2.0 instead of the default v1.2.0. Swap the pattern for any shape you like — see Tag formats for the {prefix} and {version} placeholder reference.
.releasejet.yml
provider:
type: github
source: issues
tagFormat: "release/v{version}"
categories:
feature: "New Features"
bug: "Bug Fixes"
improvement: "Improvements"
breaking-change: "Breaking Changes"
uncategorized: lenienttagFormat must contain {version}. {prefix} is optional and only used for multi-client repos.
GitHub Actions
.github/workflows/release-notes.yml:
name: Release Notes
on:
push:
tags:
- 'release/v*'
jobs:
release-notes:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm i -g @makispps/releasejet
- run: releasejet generate --tag "${{ github.ref_name }}" --publish
env:
RELEASEJET_TOKEN: ${{ secrets.RELEASEJET_TOKEN }}Match the on.push.tags glob to your pattern — release/v* for the example above.
Workflow
- Label issues as they close (
feature,bug, ...). - Tag the release:
git tag release/v1.2.0 && git push origin release/v1.2.0. - The workflow runs, matching
release/v*, and publishes the release.
Migrating to a new format
If you change tagFormat on a repo that already has tags in the old format, list the previous pattern under legacyTagFormats so those tags are still recognised as full releases (since 1.25.0). Without it, the next generate aborts with an actionable error — ReleaseJet detects the orphan tag and suggests --since. See Migrating to a new tag format for the full flow.
Tips
- The glob in your CI trigger and
tagFormatmust agree. A pattern like{version}with triggerv*won't fire for a tag like1.2.0becausev*expects thevprefix. - Prefer patterns that include a non-version segment (
release/v{version},{prefix}@{version}) — they avoid confusion with raw semver tags sometimes created by tooling.