From fb72bf300523d8a2734ba8371a1254795177a820 Mon Sep 17 00:00:00 2001 From: Duncan Tourolle Date: Fri, 21 Aug 2026 18:58:39 +0200 Subject: [PATCH] docs(ci): drop the runner-health references the amend missed The commit that removed .gitea/workflows/runner-health.yml was amended with a git add whose pathspec named the already-deleted file, so the add aborted and only the deletion was staged -- leaving ci-operations.md still describing a scheduled job that no longer exists. The runner section now says what to check by hand and why there is no job: on a single-slot runner a daily job takes the slot and pulls the builder image to run df, and df inside a container does not reliably describe the host disk. --- docs/build/ci-operations.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/docs/build/ci-operations.md b/docs/build/ci-operations.md index 986f916b..94837c2d 100644 --- a/docs/build/ci-operations.md +++ b/docs/build/ci-operations.md @@ -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: