first commit
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
Before running the checklist, run `git fetch origin`. If the current branch is behind `origin/master`, stop and rebase before proceeding.
|
||||
|
||||
Run the pre-commit checklist for this project:
|
||||
|
||||
1. Update `CHANGELOG.md` `[Unreleased]` section — add an entry under the appropriate subsection (Added / Changed / Fixed / Removed) describing the changes made, referencing the issue number.
|
||||
2. Run `dotnet build --configuration Release` — must succeed.
|
||||
3. Run `dotnet test --settings .runsettings` — all tests must pass.
|
||||
4. If `dotnet csharpier` is available, run `dotnet csharpier --check .` — must pass
|
||||
(run `dotnet csharpier .` to auto-fix). Skip this step with a note if not installed.
|
||||
5. If `coderabbit` CLI is installed, run `coderabbit review --type uncommitted --prompt-only`:
|
||||
- If actionable/serious findings are reported, stop and address them before proposing the commit.
|
||||
- If only nitpick-level findings, report them and continue to the commit proposal.
|
||||
- If `coderabbit` is not installed, skip this step with a note.
|
||||
|
||||
Run steps 1–4, report the results clearly, then run step 5 (CodeRabbit review) if available, then propose a branch name and commit message for my approval using the format `type(scope): description (#issue)` (max 80 chars; types: `feat` `fix` `chore` `docs` `test` `refactor` `ci` `perf`). Do not create the branch or commit until I explicitly confirm.
|
||||
@@ -0,0 +1,121 @@
|
||||
Run the pre-release checklist for this project. Work through all three phases
|
||||
in order, pausing for explicit confirmation at each decision point before
|
||||
proceeding. Never create a branch, commit, tag, or push without approval.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Determine next release
|
||||
|
||||
1. Run `git status` and confirm the working tree is clean and on `master`.
|
||||
If not, stop and report the problem.
|
||||
|
||||
2. Run `git tag --sort=-v:refname` to list existing tags. Identify the most
|
||||
recent tag matching `v*.*.*-*` and extract its stadium codename.
|
||||
|
||||
3. Read the A–Z stadium table from `CHANGELOG.md` to find the next stadium:
|
||||
- **No tags yet**: start at `A` (first stadium in the table).
|
||||
- **Normal case**: use the stadium that follows the last used codename
|
||||
alphabetically. If letters were skipped, pick the next after the
|
||||
highest existing codename — do not backfill gaps.
|
||||
- **Last codename is `Z`** (Zentralstadion): the list is finite. Stop and
|
||||
refer to ADR 0012 for guidance on extending or revisiting the convention.
|
||||
|
||||
4. Read the `[Unreleased]` section of `CHANGELOG.md` and infer the version
|
||||
bump using these rules (applied in order — first match wins):
|
||||
- Any entry contains the word **BREAKING** (case-insensitive), a
|
||||
`BREAKING CHANGE:` token in a commit footer, or a `!` suffix after
|
||||
the commit type/scope (e.g. `feat!:` or `feat(scope)!:`) → **major** bump
|
||||
- Any `### Added` subsection has entries → **minor** bump
|
||||
- Otherwise (only `### Changed`, `### Fixed`, `### Removed`) → **patch** bump
|
||||
|
||||
5. Compute the next version by applying the bump to the current latest tag's
|
||||
semver (e.g. `v2.1.0-dusseldorf` + minor → `2.2.0`).
|
||||
|
||||
6. Present a summary for confirmation before continuing:
|
||||
- Last tag and stadium
|
||||
- Next version and stadium codename
|
||||
- Bump type and the reasoning (what triggered it)
|
||||
- Proposed tag: `vX.Y.Z-{stadium}`
|
||||
- Proposed branch: `release/vX.Y.Z-{stadium}`
|
||||
|
||||
**Wait for explicit approval before proceeding to Phase 2.**
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Prepare release branch
|
||||
|
||||
1. Create branch `release/vX.Y.Z-{stadium}` from `master`.
|
||||
|
||||
2. Edit `CHANGELOG.md`:
|
||||
- Replace `## [Unreleased]` with `## [X.Y.Z - StadiumName] - YYYY-MM-DD`
|
||||
(use today's date; use the stadium's display name from the table, e.g.
|
||||
"Bernabeu", "Centenario").
|
||||
- Consolidate duplicate subsection headings (e.g. two `### Added` blocks
|
||||
should be merged into one).
|
||||
- Add a new empty `## [Unreleased]` section at the top (above the new
|
||||
versioned heading) with the standard subsections.
|
||||
- Update the compare links at the bottom of the file:
|
||||
- `[unreleased]` → `.../compare/vX.Y.Z-{stadium}...HEAD`
|
||||
- Add `[X.Y.Z - StadiumName]` → `.../compare/v{prev-tag}...vX.Y.Z-{stadium}`
|
||||
|
||||
3. Show the full diff of `CHANGELOG.md`.
|
||||
|
||||
4. If `coderabbit` CLI is installed, run `coderabbit review --type uncommitted --prompt-only`
|
||||
on the uncommitted CHANGELOG changes:
|
||||
- If actionable/serious findings are reported, stop and address them before proceeding.
|
||||
- If only nitpick-level findings, report them and continue.
|
||||
- If `coderabbit` is not installed, skip with a note.
|
||||
|
||||
5. Propose this commit message:
|
||||
|
||||
```text
|
||||
docs(changelog): prepare release notes for vX.Y.Z-{stadium} (#issue)
|
||||
```
|
||||
|
||||
**Wait for explicit approval before committing.**
|
||||
|
||||
6. Run `dotnet build --configuration Release` — must succeed.
|
||||
|
||||
7. Run `dotnet test --settings .runsettings` — all tests must pass.
|
||||
|
||||
8. If `dotnet csharpier` is available, run `dotnet csharpier --check .` — must pass
|
||||
(run `dotnet csharpier .` to auto-fix). Skip with a note if not installed.
|
||||
|
||||
9. Stage `CHANGELOG.md` and commit using the approved message from step 5.
|
||||
|
||||
10. Propose opening a PR from `release/vX.Y.Z-{stadium}` into `master`.
|
||||
**Wait for explicit approval before opening.**
|
||||
|
||||
11. Open the PR with:
|
||||
- Title: `docs(changelog): prepare release notes for vX.Y.Z-{stadium}`
|
||||
- Body summarising what is included in this release.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Tag and release
|
||||
|
||||
1. Wait — do not proceed until the user confirms:
|
||||
- CI is green
|
||||
- The PR has been merged into `master`
|
||||
|
||||
2. Once confirmed, run:
|
||||
```bash
|
||||
git checkout master && git pull origin master
|
||||
```
|
||||
and show the resulting `git log --oneline -3`.
|
||||
|
||||
3. Propose the annotated tag:
|
||||
```bash
|
||||
git tag -a vX.Y.Z-{stadium} -m "Release X.Y.Z - StadiumName"
|
||||
```
|
||||
|
||||
**Wait for explicit approval before creating the tag.**
|
||||
|
||||
4. Create the tag, then propose:
|
||||
```bash
|
||||
git push origin vX.Y.Z-{stadium}
|
||||
```
|
||||
|
||||
**Wait for explicit approval before pushing.** Remind the user that pushing
|
||||
the tag triggers the CD workflow which will build, publish the Docker image,
|
||||
and create the GitHub Release.
|
||||
Reference in New Issue
Block a user