generated from eblume/project-template
All checks were successful
Build / validate (pull_request) Successful in 5m23s
Kick off the C2 Mikado chain for an opt-in (default-off) hephd
self-update mode (forge-poll -> cargo install from tag -> self-restart).
Goal card plus eight prerequisite cards, indexed from how-to.md:
release-poll-version-check, self-update-opt-in-flag (leaves)
-> self-update-poll-loop (notify-only core)
service-env-forge-access (leaf, the cargo/forge blocker)
+ self-update-poll-loop -> cargo-install-from-tag
service-respawn-on-clean-exit (leaf, systemd Restart=always)
+ cargo-install-from-tag -> self-restart-after-update
verify-hub-dropout-resilience (leaf, lock in the base-case guarantee)
Grounded in research of hephd's sync loop, daemon lifecycle, the
launchd/systemd service templates, and the forge releases API.
Captured from Hephaestus task 01KTA2NSNRYT902HC3VRW00S1J.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
| title | modified | tags | status | branch | requires | |||
|---|---|---|---|---|---|---|---|---|
| hephd self-update | 2026-06-04 |
|
active | mikado/hephd-self-update |
|
hephd self-update
Goal (desired end state). An opt-in, default-off mode where hephd
periodically polls the forge for a newer release and, when one exists,
rebuilds via cargo install from the release tag and restarts itself onto the
new binary — unattended.
End state
- A new daemon flag (
--self-update, default off) plus a poll interval. When off, behaviour is unchanged. See self-update-opt-in-flag. - A background task (modelled on the existing spoke sync loop,
crates/hephd/src/server.rsspawn_sync_loop) that on each tick fetches the latest release and compares it toheph_core::VERSION. See self-update-poll-loop and release-poll-version-check. - On a newer release: run
cargo install --locked --git ssh://… --tag vX.Y.Zfor all workspace binaries (cargo-install-from-tag), then exit cleanly so the OS service manager respawns the new binary (self-restart-after-update, service-respawn-on-clean-exit). - Running
cargo installfrom inside the service requires the daemon's environment to have cargo + forge SSH access — the known blocker tracked in service-env-forge-access.
Design decisions (owner)
- Default off, opt-in only. Never self-update silently by default.
- Delivery is
cargo installfrom the tag for now (prebuilt release binaries are a possible future, pending a cargo/forge canonical-host fix). - Hub can disappear at any moment — that resilience is the base case, not a special guard. The sync loop already tolerates an unreachable hub; we lock that in rather than add update-specific guards. See verify-hub-dropout-resilience.
Scope notes
Captured from task 01KTA2NSNRYT902HC3VRW00S1J in the Hephaestus project.
Possible later refinements (own cards if pursued): checksum/signature
verification of the built binary, prebuilt release-binary delivery, and a
notify-only sub-mode.