2026-08-21 17:33:54 +00:00
1 changed files with 15 additions and 3 deletions
@@ -15,7 +15,6 @@ GitHub.
 | [traceability-check.yml](../../.gitea/workflows/traceability-check.yml) | push/PR | Requirement coverage ratchet, dangling IDs |
 | [build-release.yml](../../.gitea/workflows/build-release.yml) | tag `v*` | Builds, signs, publishes, and writes the update manifest |
 | [publish-docs.yml](../../.gitea/workflows/publish-docs.yml) | push to `master` | Docs site on the `gitea-pages` branch |
 | [runner-health.yml](../../.gitea/workflows/runner-health.yml) | daily 07:00 UTC | Runner disk before it fills |
 ## 🔴 CI installs no system tools
@@ -121,8 +120,21 @@ was in for its whole history before this was set up.
 ## The runner
-One self-hosted runner, one ~74 GB disk shared with two other projects. It fills.
+One self-hosted runner, one ~74 GB disk shared with two other projects. It fills,
-`runner-health.yml` reports usage daily and fails above 90%.
+and when it does the symptoms are misleading: cargo dying mid-link, docker
 refusing to pull, `actions/cache` quietly not saving — anything except an obvious
 out-of-space error. Check the disk first.
 There is deliberately no scheduled job watching this. On a single-slot runner a
 daily job occupies the slot and pulls the builder image to run `df`, and `df`
 inside a container does not reliably describe the host's disk anyway — it would
 cost real build capacity to report a number that might be wrong. Check it by hand
 on the runner:
 ```bash
 df -h /
 docker system df -v
 ```
 When it does fill: