build(ci,deploy)!: the runner at home in a nightly window, deploys by hand (ADR 0039, D6, D13, D16)
Some checks failed
CI / check (push) Has been cancelled
Some checks failed
CI / check (push) Has been cancelled
The CI runner moves to halkyon.li's host at home and runs from 02:00 to 05:00 alone: a timer starts it, its unit's RuntimeMaxSec ends it, and night.sh rests the instance's heavy sidecars around it as deploy, while Caddy, PostgreSQL and the apps' servers keep serving. Jobs pushed during the day wait in Forgejo's queue. Its sandbox fits the new host: its folder on the HDD, the rest of /data hidden, containerd's store out of reach, no private IPv4 network and no IPv6 at all (the home network's IPv6 addresses are public ones under a changing prefix, on the internet's own interface), 5 GB of memory with swap beyond. The Sandbox step checks the tunnel, the home router and IPv6. BREAKING CHANGE: CI deploys nothing any more: the deploy job goes with learn.halkyon.eu's server, and halkyon.li deploys by hand with redeploy.sh once a commit's night's run passed. Jobs run on the runner labelled balthasar; sahaquiel's runner picks up none. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
This commit is contained in:
parent
2218695dcf
commit
c8d67b1eb7
1 changed files with 401 additions and 76 deletions
|
|
@ -1,12 +1,13 @@
|
|||
#!/bin/sh
|
||||
# Deploys learn.halkyon.eu from main. The only command deploy's keys may run: deploy's
|
||||
# ~/.ssh/authorized_keys on the server pins both to this script, CI's from the server itself:
|
||||
# Deploys the instance (halkyon.li, ADR 0039, D13; learn.halkyon.eu until November 2026)
|
||||
# from main, by hand, once the commit's night's CI run passed. The only command deploy's
|
||||
# keys may run: deploy's ~/.ssh/authorized_keys on the instance's host pins the
|
||||
# developer's key to this script:
|
||||
#
|
||||
# restrict,from="127.0.0.1,::1",command="/home/deploy/halkyon/deploy/redeploy.sh" ssh-ed25519 … (CI deploy trigger)
|
||||
# restrict,command="/home/deploy/halkyon/deploy/redeploy.sh" ssh-ed25519 … (manual deploys)
|
||||
# restrict,command="/home/deploy/halkyon/deploy/redeploy.sh" ssh-ed25519 … (deploys by hand)
|
||||
#
|
||||
# CI passes the commit it has checked. This deploys it only
|
||||
# - while it is still the tip of main (otherwise the CI run of the newer tip deploys),
|
||||
# The developer passes the commit. This deploys it only
|
||||
# - while it is still the tip of main (otherwise the newer tip is deployed instead),
|
||||
# - as a fast-forward of the deployed commit,
|
||||
# - if every new commit is signed by a key in deploy/allowed-signers, as the deployed
|
||||
# checkout lists them (so no commit can add its own key),
|
||||
|
|
@ -14,10 +15,10 @@
|
|||
# too where .env switches each on, compose.train.yaml, compose.todo.yaml,
|
||||
# compose.meditate.yaml), applies the migrations
|
||||
# before switching to the new server, starts it once more after a migration (see below),
|
||||
# and fails unless that server answers afterwards. A failure leaves the checkout at the deployed commit, so
|
||||
# running the CI job again retries. By hand, with your own key, which passes the commit as CI does:
|
||||
# and fails unless that server answers afterwards. A failure leaves the checkout at the
|
||||
# deployed commit, so running it again retries. From melchior, at home or through ramiel:
|
||||
#
|
||||
# ssh sahaquiel-deploy <commit>
|
||||
# ssh balthasar-deploy <commit>
|
||||
set -eu
|
||||
|
||||
main() {
|
||||
|
|
|
|||
Loading…
Reference in a new issue