k3nnyandClaude Opus 5.5
e28434a030
- .github/workflows/ci.yml: same vet/staticcheck/test/build checks as Gitea CI - .github/workflows/release.yml: same five binaries and build flags as the Gitea release workflow, published with gh release create - docs: mention the GitHub mirror and both release pages; GitHub Actions example downloads from GitHub releases using RUNNER_OS/RUNNER_ARCH - docs: fix broken latest/download URL, clone URL and Go version requirement Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
1.4 KiB
1.4 KiB
title
| title |
|---|
| releaser |
CI-friendly release automation for GitFlow workflows using Conventional Commits.
Source code · Releases · GitHub mirror
Standard tools like semantic-release are designed for trunk-based development. In a GitFlow setup with versioned release branches (release/1.1, release/1.2), they either fail to respect the branch's version range or require brittle configuration.
releaser is built for this exact workflow: it reads the branch name to pin the major.minor, parses Conventional Commits to determine the patch increment, and handles everything from pom.xml / package.json update to GitLab/GitHub tag and release creation.
How it works
release/1.2 branch
└─ last tag: 1.2.3 (or none → start at 1.2.0)
└─ commits since tag → Conventional Commits analysis
└─ next version: 1.2.4
- Branch parsing — extracts
major.minorfrom branch name (release/1.2→1.2) - Tag discovery — finds the latest tag matching
major.minor.*on the current branch - Commit analysis — parses Conventional Commits between last tag and HEAD
- Version bump — increments patch (or minor, if configured via
bump_rules) - Release — updates
pom.xml/package.json, commits, tags, creates GitLab or GitHub release