GRM-48: refactor: consolidate CI workflows to eliminate redundant runs

This commit is contained in:
emil
2026-06-22 00:01:58 +00:00
parent 5b4aaffa3b
commit d8d025789b
7 changed files with 154 additions and 167 deletions
+33 -20
View File
@@ -132,8 +132,8 @@ Then add the `ready-to-merge` label. The auto-merge workflow will:
> **IMPORTANT**: Never manually merge PRs via the API. Always use the auto-merge
> workflow by adding the `ready-to-merge` label. Manual merges bypass the
> `GRM-N <conventional>` format enforcement, producing incorrectly named commits.
> The CI `validate-merge` job checks every push to master and will fail if a
> commit message doesn't match `GRM-N <type>: <description>` or `release: vX.Y.Z`.
> The auto-merge script validates the PR title matches the Vikunja task ID
> and conventional commit format before merging.
### CI Path Filtering
@@ -159,27 +159,40 @@ then to a default of 3.
### Automated Release Pipeline
After a PR is merged to master, the release pipeline runs automatically:
After a PR is merged to master, the **post-merge workflow**
(`.gitea/workflows/post-merge.yml`) runs automatically. This single
workflow consolidates release, wiki sync, badge generation, and
Vikunja task updates:
1. **Release workflow** (`.gitea/workflows/release.yml`):
- Triggers on push to master
- Sets up full dev environment (`make setup`) so lint and tests can run
- Runs `scripts/ci/release.py` which:
- **Checks for user-facing changes** via `scripts/ci/classify_changes.py` — if only
workflow/infrastructure files changed (`.gitea/`, `scripts/`, `docs/`, `tests/`,
`AGENTS.md`, `Makefile`, etc.), the release is **skipped entirely** — no version
bump, no tag, no publish. This prevents unnecessary releases for CI/docs-only changes.
- Uses **git-cliff** to calculate the next semver version from conventional commits
- Updates `__version__` in `src/gitea_runner_manager/__init__.py` (single source of truth)
- Updates `CHANGELOG.md` with the new version section
- **Runs `make lint-ruff` and `make pytest-cov`** to verify the release is healthy
- If lint or tests fail, **aborts immediately** — no commit, no tag
- Commits with `release: vX.Y.Z` prefix (cleaner than `chore(release):`)
- Creates an annotated tag `vX.Y.Z` on the release commit
- Pushes both the commit and tag to master
1. **detect-type** — Checks if the commit is a regular merge or a
release commit (`release: vX.Y.Z`). All subsequent jobs skip for
release commits (the `[skip ci]` tag also prevents re-triggering).
2. **release** — Runs `scripts/ci/release.py` which:
- **Checks for user-facing changes** via `scripts/ci/classify_changes.py` — if only
workflow/infrastructure files changed (`.gitea/`, `scripts/`, `docs/`, `tests/`,
`AGENTS.md`, `Makefile`, etc.), the release is **skipped entirely** — no version
bump, no tag, no publish. This prevents unnecessary releases for CI/docs-only changes.
- Uses **git-cliff** to calculate the next semver version from conventional commits
- Updates `__version__` in `src/gitea_runner_manager/__init__.py` (single source of truth)
- Updates `CHANGELOG.md` with the new version section
- **Runs `make lint-ruff` and `make pytest-cov`** to verify the release is healthy
- If lint or tests fail, **aborts immediately** — no commit, no tag
- Commits with `release: vX.Y.Z [skip ci]` prefix (the `[skip ci]` prevents
re-triggering post-merge on the release commit)
- Creates an annotated tag `vX.Y.Z` on the release commit
- Pushes both the commit and tag to master
- `--skip-tests` flag bypasses test verification (emergency use only, not recommended)
- Loops are prevented by `has_unreleased_changes` — after a release commit is tagged, the next run finds no unreleased changes and exits
- On failure, creates a Gitea issue via `scripts/ci/notify_failure.py`
3. **sync-wiki** — Syncs documentation to the Gitea wiki.
4. **badges** — Generates and pushes quality badge SVGs to the `badges` branch.
5. **vikunja** — Marks the corresponding Vikunja task as done.
The tag push triggers the **publish workflow** (`.gitea/workflows/publish.yml`)
which builds and publishes the package to PyPI.
### Smart CI: User-Facing vs Workflow-Only Changes