provisioning: stop deleting the pre-rename hook and subscription

Retiring gitea-events is a one-off migration, not something worth re-running
on every boot. Both units now only touch what they own: jupiter's creates or
updates its own hook and deletes nothing, and mars's removes only the route
it is about to re-subscribe, as the idempotency step for `subscribe`.

Keeping the deletes would have meant a redeploy could silently remove a hook
or route someone added deliberately -- a real risk now that sibling hooks
for other Hermes routes are the intended pattern.

README carries the manual commands, and the note that both hooks fire until
the old one is removed by hand, so events arrive twice in the meantime.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S94o42aQ8VkBmEWvDem5xa
This commit is contained in:
2026-08-23 06:57:58 +02:00
co-authored by Claude Opus 5
parent f982c6dc14
commit 3567591ecf
3 changed files with 31 additions and 18 deletions
+22
View File
@@ -53,6 +53,28 @@ is not tied to any one subscription: another Hermes route needs a
`/gitea/<name>`, and no relay change. Route names are validated against a
strict charset before being used in the outbound URL.
Neither provisioning unit deletes anything: Jupiter's only creates or updates
its own hook, and Mars's only removes the route it is about to re-subscribe.
Retiring the pre-rename `gitea-events` route is therefore a one-off, done by
hand after the first deploy of both hosts:
```
# on mars — drop the old subscription
sudo podman exec hermes-agent hermes webhook remove gitea-events
# on jupiter — delete the old hook (it posts to the relay's bare /gitea path)
api=http://127.0.0.1:3000/api/v1; repo=darman/homelab
tok="$(sudo cat /run/secrets/gitea_provisioning_token)"
old="$(curl -fsS -H "Authorization: token $tok" "$api/repos/$repo/hooks" \
| jq -r '.[] | select(.config.url == "http://mars.orbit.sol:8645/gitea") | .id')"
for id in $old; do
curl -fsS -H "Authorization: token $tok" -X DELETE "$api/repos/$repo/hooks/$id"
done
```
Check `hermes webhook list` and the repo's webhook page afterwards; until the
old hook is gone both it and the new one fire, so events arrive twice.
That one header copy is the entire reason the relay exists. Gitea signs every
webhook with `X-Hub-Signature-256` in GitHub's exact format, which Hermes
already accepts on any route — so authentication would work pointing Gitea