chadtmiller.com/knotless

Switch repository

Loading…

What changes

Main's deploy deploys the runner host too. A last step of deploy.yml, runner host, runs deploy/runner-host/deploy.sh with KNOTLESS_RUNNER_IMAGE_FROM set to the main host. The runner host's settings (KNOTLESS_RUNNER_*: its domain, account, --queue --pulls-only … arguments, jobs, CPUs and memory) move into the workflow from deploy/local.env, with the same values.

It restarts the runner host only when its runner changed. Given an image source, deploy/runner-host/deploy.sh compares the runner fingerprint in both hosts' knotless:current images (/etc/knotless-run.fingerprint, as the main host's deploy does). It copies the image only when they differ, and docker compose up -d then leaves the runner running when neither its image nor its settings changed.

A key of its own. The step reaches the host with RUNNER_HOST_SSH_KEY, a secret granted to pushes to main. Root on the runner host accepts it only from the main host's addresses (from="178.104.222.99,2a01:4f8:c015:4df4::/64"). setup.sh installs it given KNOTLESS_RUNNER_DEPLOY_KEY and KNOTLESS_RUNNER_DEPLOY_FROM. With the secret absent, the step says so and passes.

Why

runner.knotless.dev lands the merge queue of repositories that name it, pds.js among them, but it was deployed only by hand and ran a build from before today's gates. It ejected https://knotless.dev/chadtmiller.com/pds.js/pull/did:plc:bcgltzqazw5tb6k2g3ttenbj/3mzgrkfqtskgg with what this version does not know: gates; update knotless, though main's rule (reviews.gates) is what current knotless writes. The ejection record is the runner host's (by: did:plc:4bocpkn5…). The main host's runner restarted at 18:37 UTC with gates.

How it was checked

bash -n on both scripts. The runner host was redeployed by hand from main at 4955bc71 to unblock pds.js. The workflow step runs only on a push to main, so its first real run is this pull's deploy. Its log should say its runner is … too: keeping its image, or copy the image once.

Shortcomings

• The runner host's bots service (serve, for the runner's bot login) runs the same image, so it is updated only when the runner's build changes.
• Copying the image streams it from the main host through the deploy job to the runner host, a gigabyte or so, whenever the runner changes.
• Before this works, someone has to authorize the key on the runner host and seal RUNNER_HOST_SSH_KEY. Until then the step passes, saying so.

🤖 Generated with Claude Code

This makes main's deploy end with a runner host step. It reaches the runner host with its own key, RUNNER_HOST_SSH_KEY. deploy/runner-host/deploy.sh now copies the main host's knotless:current only when the runner fingerprints differ, and docker compose up -d leaves an unchanged runner running. I read all four changed files and the workflow around the new step, and found nothing that needs changing.

• Tooling: the step's tools are in place. The tools step installs bash, so [[ =~ ]] works, and ssh and scp are already used by the existing deploy.
• Missing secret: the step guards on the same ~/.moved and ~/.up markers as image. It exits 0 when RUNNER_HOST_SSH_KEY is absent, as the body says.
• Fingerprint check: it copies the image whenever either fingerprint is missing or malformed (the [[ $NEW =~ ^[0-9a-f]{64}$ ]] test). That is the safe direction.
• Setup: setup.sh installs the key idempotently and refuses KNOTLESS_RUNNER_DEPLOY_KEY without KNOTLESS_RUNNER_DEPLOY_FROM.

Three things I could not check from the diff:

• Whether the deploy job's outbound address really falls in the from= list (178.104.222.99 or 2a01:4f8:c015:4df4::/64). If it doesn't, the first real run fails at the fingerprint ssh. OLD comes back empty, so the step then tries the copy and fails there.
• That the KNOTLESS_RUNNER_* values in the workflow match your deploy/local.env, which isn't in the repo. The README example at deploy/runner-host/README.md:165 lists one --unmetered and one --trust DID. The workflow lists two of each (the second is did:plc:e7rftrdy…).
• Whether a failure in the new last step turns a deploy red after main is already up. It would be a late failure, and I assume you accept that.

The first run on this pull's own deploy will show whether the fingerprint path works.

Carried forward: the change this pull makes at 9663117a8c50da09ea18b7f5188c4206ce69a9f9 is the one reviewed at 6e8a12519ce97b99e0d6df7563cfc1c1111d43be, so that review stands. What is new comes from its base.