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.
This commit is contained in:
Vendored
+15
-3
@@ -15,7 +15,6 @@ GitHub.
|
|||||||
| [traceability-check.yml](../../.gitea/workflows/traceability-check.yml) | push/PR | Requirement coverage ratchet, dangling IDs |
|
| [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 |
|
| [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 |
|
| [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
|
## 🔴 CI installs no system tools
|
||||||
|
|
||||||
@@ -121,8 +120,21 @@ was in for its whole history before this was set up.
|
|||||||
|
|
||||||
## The runner
|
## 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:
|
When it does fill:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user