mirror of
https://github.com/softprops/action-gh-release.git
synced 2026-03-16 10:09:07 +08:00
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# Release Workflow
|
|
|
|
Use this checklist when cutting a new `action-gh-release` release.
|
|
|
|
## Inputs
|
|
|
|
- Decide the semantic version bump first: `major`, `minor`, or `patch`.
|
|
- Review recent merged PRs and labels before drafting the changelog entry.
|
|
- Make sure `master` is current and the worktree is clean before starting.
|
|
|
|
## Checklist
|
|
|
|
1. Update [package.json](package.json) to the new version.
|
|
2. Add the new entry at the top of [CHANGELOG.md](CHANGELOG.md).
|
|
- Summarize the release in 1 short paragraph.
|
|
- Prefer user-facing fixes and features over internal churn.
|
|
- Keep the merged PR list aligned with `.github/release.yml` categories.
|
|
3. Run `npm i` to refresh [package-lock.json](package-lock.json).
|
|
4. Run the full local verification set:
|
|
- `npm run fmtcheck`
|
|
- `npm run typecheck`
|
|
- `npm run build`
|
|
- `npm test`
|
|
5. Commit the release prep.
|
|
- Use a plain release commit message like `release 2.5.4`.
|
|
6. Create the annotated tag for the release commit.
|
|
- Example: `git tag -a v2.5.4 -m "v2.5.4"`
|
|
7. Push the commit and tag.
|
|
- Example: `git push origin master && git push origin v2.5.4`
|
|
8. Move the floating major tag to the new release tag.
|
|
- For the current major line, either run `npm run updatetag` or update the script first if the major ever changes.
|
|
- Verify the floating tag points at the same commit as the new full tag.
|
|
9. Create the GitHub release from the new tag.
|
|
- Prefer the release body from [CHANGELOG.md](CHANGELOG.md), then let GitHub append generated notes only if they add value.
|
|
- Verify the release shows the expected tag, title, notes, and attached artifacts.
|
|
|
|
## Notes
|
|
|
|
- Behavior changes should already have matching updates in [README.md](README.md), [action.yml](action.yml), tests, and `dist/index.js` before release prep begins.
|
|
- Docs-only releases still need an intentional changelog entry and version bump decision.
|
|
- If a release is mainly bug fixes, keep the title and summary patch-oriented; do not bury the actual fixes under dependency noise.
|