eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

CI: use Gitea 1.27 job summaries for richer step reports (mutation, frontend, unit, e2e, verify-stack) #136

New Issue
Closed
opened 2026-07-24 11:41:40 +00:00 by not · 0 comments
not commented 2026-07-24 11:41:40 +00:00
Contributor
Copy Link
Copy Source

Context

Gitea 1.27 + act_runner 2.0.0 now support the standard $GITHUB_STEP_SUMMARY file: markdown a step appends there renders on the run page, next to the logs, with no artifact download. The runner only uploads it when the server advertises support and silently skips otherwise, so it is safe to adopt. Guard every write with [ -n "$GITHUB_STEP_SUMMARY" ] so local/older-runner runs don't error on an unset var.

All items below are reporting-only — no gating/exit-code changes — so they're low risk and TDD-neutral.

Depends on #134/#135 (verify-stack must dispatch again before we bolt summary steps onto it).

Scope (quick wins)

1. Mutation scores

Add Markdown to reporters in each services/*/stryker-config.json (Stryker.NET 4.15 supports it → writes reports/mutation-report.md). In the mutation job, an if: always() step concatenates each service's StrykerOutput/*/reports/mutation-report.md into the summary. Bonus: since make mutation stops at the first ratchet break, the summary also shows exactly where it stopped.

2. Frontend tests labelled per frontend

The frontend job runs make frontend (nx run-many lint+test+build across all projects). The summary should break results down per project — self-service, openbaar, behandel, beheer, and the libs (auth, ui, api-client) — so it's obvious which frontend failed. Likely approach: a per-project vitest reporter (JSON) or parsing nx's per-project output into a table (project → pass/fail/count).

3. Unit test reports per service

The unit job runs make unit (dotnet test on the solution). Emit a per-service table (acl, domain, event-subscriber, bff, projection-api, acceptance) with passed/failed/skipped + duration. Likely approach: dotnet test --logger trx + parse each project's TRX, or a summary logger, appended to the summary.

4. verify-stack e2e results

Playwright per-spec pass/fail in the summary. The e2e runs inside a container (infra/run-e2e-check.sh via docker cp), so a results file (Playwright JSON/markdown reporter) must be copied back out to the runner and appended. Would have made today's catalogus.spec failure a one-glance read instead of a 3,400-line log dive.

5. verify-stack check table

A table of each live-stack check — observability, acl, nrc, projection, domain, bff, tracing, metrics, e2e — with pass/fail, so a red verify-stack shows which check failed at a glance. Approach: capture each step's outcome (step ids + a final if: always() summary step), or have each make verify-* emit a status line.

Definition of Done

  • Each item writes to $GITHUB_STEP_SUMMARY (guarded), renders on the run page.
  • No change to any job's pass/fail gating (reporting-only).
  • Conventional Commits referencing this issue.
  • CI green; summaries visible on the run.
  • docs/runbooks/gitea-actions-gotchas.md / ci.md note the $GITHUB_STEP_SUMMARY pattern + version requirement (Gitea >=1.27, runner >=2.0).
  • Closed by the merging PR.

Notes

Can be split per item if it grows past 1-2 days (CLAUDE.md §13); items 1 and 3/2 are the cheapest, 4/5 need more plumbing. Do not start until signalled.

## Context Gitea 1.27 + act_runner 2.0.0 now support the standard `$GITHUB_STEP_SUMMARY` file: markdown a step appends there renders on the run page, next to the logs, with no artifact download. The runner only uploads it when the server advertises support and silently skips otherwise, so it is safe to adopt. Guard every write with `[ -n "$GITHUB_STEP_SUMMARY" ]` so local/older-runner runs don't error on an unset var. All items below are **reporting-only** — no gating/exit-code changes — so they're low risk and TDD-neutral. **Depends on #134/#135** (verify-stack must dispatch again before we bolt summary steps onto it). ## Scope (quick wins) ### 1. Mutation scores Add `Markdown` to `reporters` in each `services/*/stryker-config.json` (Stryker.NET 4.15 supports it → writes `reports/mutation-report.md`). In the `mutation` job, an `if: always()` step concatenates each service's `StrykerOutput/*/reports/mutation-report.md` into the summary. Bonus: since `make mutation` stops at the first ratchet break, the summary also shows exactly where it stopped. ### 2. Frontend tests labelled per frontend The `frontend` job runs `make frontend` (nx `run-many` lint+test+build across all projects). The summary should break results down **per project** — `self-service`, `openbaar`, `behandel`, `beheer`, and the libs (`auth`, `ui`, `api-client`) — so it's obvious which frontend failed. Likely approach: a per-project vitest reporter (JSON) or parsing nx's per-project output into a table (project → pass/fail/count). ### 3. Unit test reports per service The `unit` job runs `make unit` (`dotnet test` on the solution). Emit a per-**service** table (acl, domain, event-subscriber, bff, projection-api, acceptance) with passed/failed/skipped + duration. Likely approach: `dotnet test --logger trx` + parse each project's TRX, or a summary logger, appended to the summary. ### 4. verify-stack e2e results Playwright per-spec pass/fail in the summary. The e2e runs inside a container (`infra/run-e2e-check.sh` via `docker cp`), so a results file (Playwright JSON/markdown reporter) must be copied back out to the runner and appended. Would have made today's `catalogus.spec` failure a one-glance read instead of a 3,400-line log dive. ### 5. verify-stack check table A table of each live-stack check — observability, acl, nrc, projection, domain, bff, tracing, metrics, e2e — with pass/fail, so a red `verify-stack` shows *which* check failed at a glance. Approach: capture each step's outcome (step `id`s + a final `if: always()` summary step), or have each `make verify-*` emit a status line. ## Definition of Done - [ ] Each item writes to `$GITHUB_STEP_SUMMARY` (guarded), renders on the run page. - [ ] No change to any job's pass/fail gating (reporting-only). - [ ] Conventional Commits referencing this issue. - [ ] CI green; summaries visible on the run. - [ ] `docs/runbooks/gitea-actions-gotchas.md` / `ci.md` note the `$GITHUB_STEP_SUMMARY` pattern + version requirement (Gitea >=1.27, runner >=2.0). - [ ] Closed by the merging PR. ## Notes Can be split per item if it grows past 1-2 days (CLAUDE.md §13); items 1 and 3/2 are the cheapest, 4/5 need more plumbing. **Do not start until signalled.**
not added the type:chorearea:infra labels 2026-07-24 11:41:40 +00:00
not closed this issue 2026-07-24 13:27:55 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No labels area:infra type:chore
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#136