ci: fence the test recipes and rebuild the pipelines around the gate set
Test / test (push) Failing after 24s

Assisted-by: DeepSeek V4.1 Flash
This commit is contained in:
2026-10-04 21:15:21 +02:00
parent e3dda5e115
commit 9a1b922712
10 changed files with 165 additions and 263 deletions
+20 -17
View File
@@ -29,11 +29,11 @@ prints the same list.
| Recipe | What it does |
|---|---|
| `just gates` | the definition of done: build, format check, vet, the test suite with the coverage floor, and the race detector |
| `just build` | compiles `./cmd/interpres-decode` into `bin/interpres-decode` |
| `just test` | the suite with no cache, then the coverage floor of 80 percent from `coverage.out` |
| `just race` | the same suite under the race detector |
| `just unit ./... TestName` | a fast scoped run for iterating; the second argument is a `-run` pattern, `.*` by default |
| `just fuzz FuzzParse . 30s` | time-boxed fuzzing of one target in exactly one package; `go test -fuzz` rejects `./...`; never a gate |
| `just build` | compiles `./cmd/interpres-decode` into `bin/interpres-decode`, with `-trimpath -buildvcs=true` |
| `just test` | the suite with no cache, then the coverage floor of 80 percent from `coverage.out`, under the memory fence |
| `just race` | the same suite under the race detector, fenced too |
| `just unit ./... TestName` | a fast scoped run for iterating; the second argument is a `-run` pattern, `.*` by default, fenced |
| `just fuzz FuzzParse . 30s` | time-boxed fuzzing of one target in exactly one package; `go test -fuzz` rejects `./...`; never a gate, fenced |
| `just bench` | benchmarks, `-benchmem -count=5`, on an idle machine only |
| `just fmt` | `gofmt -w .`, format in place |
| `just fmt-check` | `gofmt -l .`, zero diff |
@@ -94,22 +94,25 @@ go build -gcflags='-S' ./... # what the compiler generated
## Continuous integration
Workflows live in `.gitea/workflows/` and run on the project's own runners.
They are written by hand rather than through `just`, but they enforce the same
set of gates, so a green `just gates` locally is the fastest way to a green
pipeline.
They are written by hand rather than through `just`, but between them they
carry the same set of gates, so a green `just gates` locally is the fastest
way to a green pipeline.
| Workflow | Trigger | What it does |
|---|---|---|
| `test.yml` | push or pull request to `development` | format check, vet, modernisation, build, the test suite with the 80 percent coverage floor, then the toml-test compliance suite |
| `race.yml` | `workflow_dispatch`, by hand | the suite under the race detector; the same race gate `just gates` runs locally |
| `fuzz.yml` | `workflow_dispatch`, by hand | a 30 second fuzz smoke per target over the seeds and the gathered corpus |
| `release.yml` | a `v*` tag | tag validation, then format, vet, modernisation, build and the test suite with the coverage floor, then the Gitea release from the CHANGELOG section. No race detector: race never runs on a push path, and the local `just gates` raced the tree before the tag was cut |
| `test.yml` | push or pull request to `development` | format check, vet, and the suite's short layer with the 80 percent coverage floor, inside the two-minute push budget |
| `suite.yml` | `workflow_dispatch`, by hand | the complete gate set minus race: build, format, vet, modernisation, the full suite and the coverage floor |
| `release.yml` | a `v*` tag | tag validation, then the Gitea release from the CHANGELOG section and nothing else. No gate runs at the tag: the tree was tested on every push, and a library ships no assets |
Race never runs in CI: it belongs to the local `just gates`, which races the
tree on the machine at the keyboard before the commit. The toml-test
compliance suite is a local recipe (`just toml-test`) and a development record
rather than a push gate.
## Releases
Releases are cut by merging `development` into `main` and tagging `vX.Y.Z`. The
tag drives the release workflow: it validates the tag, runs the static gates
and the test suite with the coverage floor, extracts the matching `## [X.Y.Z]`
section from `CHANGELOG.md`, and publishes the release with that section as its
body. A library ships no binaries, so the release carries the notes and nothing
else.
tag drives the release workflow: it validates the tag, extracts the matching
`## [X.Y.Z]` section from `CHANGELOG.md`, and publishes the release with that
section as its body. No gate runs at the tag; a library ships no binaries, so
the release carries the notes and nothing else.