docs: record Gitea runner recovery
Some checks failed
pre-commit / pre-commit (push) Failing after 40s

This commit is contained in:
Hermes VM 2026-05-27 20:58:16 +00:00
parent 1f2eea8268
commit 3d5f369f3d

View File

@ -281,8 +281,9 @@ Effective `sshd -T` settings showed:
**Roadmap:**
- [ ] Decide whether the runner should be active or intentionally disabled.
- [ ] If active: restart and verify `gitea-act-runner.service`, runner labels, Docker access, and a smoke workflow.
- [x] Decide whether the runner should be active or intentionally disabled.
- [x] If active: restart and verify `gitea-act-runner.service`, runner labels, and Docker access.
- [ ] Run and record a dedicated Gitea Actions smoke workflow result.
- [ ] If disabled: disable the service and document the intentional state.
- [ ] Keep runner secrets separate from smoke/test workflows.
- [ ] Add a runner-health check to VM observability.
@ -398,7 +399,7 @@ Effective `sshd -T` settings showed:
- [ ] Fix/retire unhealthy containers.
- [x] Resolve `hermes-root-backup.service` failed state.
- [ ] Decide and document Gitea runner active/disabled state.
- [x] Decide and document Gitea runner active/disabled state.
- [ ] Add missing-script checks. Stale root cron path was fixed on 2026-05-27.
- [ ] Apply pending security/runtime updates in a maintenance window.
@ -476,6 +477,26 @@ Minimum post-checks for Phase 1:
- A restore drill is still required before the backup posture should be considered fully proven.
- The backup sync script is runtime-managed under `/root/.hermes/scripts/`; add a tracked installer or source-of-truth copy so this hardening does not depend on manual VM state.
### 2026-05-27 — Phase 2 Gitea runner state
**Changed:**
- Started `gitea-act-runner.service`; it was enabled but inactive.
- Treated the intended state as active because the service unit is enabled, historical journal entries show successful task execution, and restart declared the runner successfully.
**Verified:**
- `systemctl is-active gitea-act-runner.service` returned `active`.
- `systemctl status gitea-act-runner.service --no-pager` showed `bytelyst-host-runner` running as `gitea-runner`.
- Runner labels declared successfully: `ubuntu-latest`, `linux`, `bytelyst`, `hostinger`.
- Runner config uses Docker executor images and `privileged: false`; Docker socket access is granted through the `docker` group.
- Runner immediately picked up task `42` for `bytelyst/bytelyst-devops-tools`, proving it can talk to local Gitea.
**Residual risk:**
- Record a small dedicated smoke workflow that does not need production secrets, so runner health is proven by a controlled workflow rather than incidental queued work.
- Add runner health to VM observability so enabled-but-inactive drift is caught automatically.
## Do Not Start With
- Rootless Docker migration.