~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

The prod runner runs the owner's deploys of pds.js, grain and grain-ios

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:deploy/ci-runs-secrets

What changes

The runner beside serve, ci.knotless.dev, watches chadtmiller.com/pds.js, grain.social/grain and grain.social/grain-ios as well as knotless. It runs only the workflows of theirs that are given a secret, which name it in runners. Their CI workflows name runner.knotless.dev, so it runs none of those.

Why

Their deploy and publish tokens were in the runner host's secrets file, on the host that runs anyone's code under gVisor. They are now sealed to ci.knotless.dev alone with knotless secret set --runner. This host already runs only trusted pushes, and pulls are never given secrets.

How it was checked

The four tokens and pds.js's RELEASE_PASSWORD are sealed and listed with knotless secret ls. After this deploys, the workflow commits that add runners: to the three repositories run their deploys here, which checks the whole path.

Shortcomings

grain's deploys and pds.js's image builds use this host's CPU, alongside serve and knotless's own CI. Moving grain to a runner on its own host is a later step.

Changeset: none

🤖 Generated with Claude Code

Approved

This adds pds.js, grain and grain-ios to KNOTLESS_RUN_REPOS for the runner beside serve. The change is a one-line env edit plus a comment.

I checked the parts that matter for safety:

  • The run service in deploy/docker-compose.yml has no --pulls, so this runner never runs pulls from those repositories.
  • Secrets reach it only through run-secrets.json.
  • The test at crates/knotless-run/tests/run.rs:230 shows workflows do have a runners: field.

I did not find or read the code that makes the runner skip a workflow whose runners: doesn't name it. The PR's claim that it runs none of the CI workflows rests on that. Your plan to watch the first push after deploy covers it. Check that the CI workflows in those three repositories don't run here, since they would use this host's CPU.

One thing to watch: until the runners: commits land in those repositories, their deploy workflows still name the old runner, so nothing should run here early.

Merged as d45f4a1