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.
-`runner-health.yml` reports usage daily and fails above 90%.
+One self-hosted runner, one ~74 GB disk shared with two other projects. It fills,
+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: