Add tap-writer Forgejo runner + tap-bump token provisioning #194

Closed
opened 2026-06-04 01:04:15 +00:00 by coilysiren · 0 comments
Owner

Stand up a dedicated Forgejo Actions runner whose only job is cross-repo Homebrew formula bumps into the coilyco-flight-deck tap(s). Companion to coilyco-flight-deck/ward#46. Implemented in PR #195.

Why a separate runner, not an Actions secret

Each Forgejo Actions job runs in an ephemeral container and only gets the auto-issued token, which is scoped to the running repo. A bump writes to a different repo (the tap), so it needs a real credential with tap write. Rather than put that token in Forgejo's Actions secret store, the runner carries it from SSM and hands it to git only through a credential helper at push time. The token never enters a job environment and never appears in logs. Isolating it on a labelled runner (tap-writer) means a token this broad is not exposed to every repo's CI the way the instance build runner's jobs would be.

This is reusable infra: one tap-writer runner and one org-scoped write token serve all of the ~8 planned taps.

Why host executor (no DinD)

A formula bump is just git + awk, no container builds. The host executor runs job steps directly in the runner container, so none of the DinD bridge churn that pins the build runner to kai-desktop-tower-wsl (#151 / #163) applies. Trade-off: the host executor has no node, so bump jobs must be pure-shell run: steps with no JS uses: actions. ward#46 is written that way.

Credential model

  • SSM /forgejo/tap-bump-token holds a write:repository-scoped Forgejo token (owning user can write every coilyco-flight-deck repo, so one token covers all taps).
  • external-secrets projects it into the runner pod.
  • A git credential helper on the runner emits it only on git credential get. Jobs never see it in env.

Deliverables

  • deploy/forgejo-runner-tap-writer.yml - host-executor act_runner, label tap-writer, no DinD sidecar, token mounted read-only + credential helper.
  • scripts/provision-tap-bump-token.sh - mint the write:repository token via the Forgejo API, store at SSM (no --overwrite, never echoes the value).
  • docs/FEATURES.md entry.

Prerequisite

Before apply, the SSM param must exist. Run on a machine with Forgejo basic-auth creds, AWS creds for us-east-1, and coily:

FORGEJO_USER=<u> FORGEJO_PASS=<p> ./scripts/provision-tap-bump-token.sh

Run order

  1. ./scripts/provision-tap-bump-token.sh (above).
  2. sudo k3s kubectl apply -f deploy/forgejo-runner-tap-writer.yml
  3. Confirm the runner registers tap-writer:host and picks up a job.
  4. Merge ward#46 last (its bump job waits on the tap-writer label existing).

Verify points

  • Host executor may be gated. Some forgejo/runner builds disable the host executor for safety. If the runner will not run tap-writer:host jobs, fall back to a docker://node:20-bookworm label (reintroduces a dockerd dependency).
  • Token file uid. Host executor runs the job as the runner uid (root in this image), so the 0400 mount is readable. If the runner is switched to non-root, adjust the mount perms.

closes #194 via #195

Stand up a dedicated Forgejo Actions runner whose only job is cross-repo Homebrew formula bumps into the coilyco-flight-deck tap(s). Companion to coilyco-flight-deck/ward#46. Implemented in PR #195. ## Why a separate runner, not an Actions secret Each Forgejo Actions job runs in an ephemeral container and only gets the auto-issued token, which is scoped to the running repo. A bump writes to a different repo (the tap), so it needs a real credential with tap write. Rather than put that token in Forgejo's Actions secret store, the runner carries it from SSM and hands it to git only through a credential helper at push time. The token never enters a job environment and never appears in logs. Isolating it on a labelled runner (`tap-writer`) means a token this broad is not exposed to every repo's CI the way the instance build runner's jobs would be. This is reusable infra: one tap-writer runner and one org-scoped write token serve all of the ~8 planned taps. ## Why host executor (no DinD) A formula bump is just git + awk, no container builds. The host executor runs job steps directly in the runner container, so none of the DinD bridge churn that pins the build runner to kai-desktop-tower-wsl (#151 / #163) applies. Trade-off: the host executor has no node, so bump jobs must be pure-shell `run:` steps with no JS `uses:` actions. ward#46 is written that way. ## Credential model - SSM `/forgejo/tap-bump-token` holds a `write:repository`-scoped Forgejo token (owning user can write every coilyco-flight-deck repo, so one token covers all taps). - external-secrets projects it into the runner pod. - A git credential helper on the runner emits it only on `git credential get`. Jobs never see it in env. ## Deliverables - [ ] `deploy/forgejo-runner-tap-writer.yml` - host-executor act_runner, label `tap-writer`, no DinD sidecar, token mounted read-only + credential helper. - [ ] `scripts/provision-tap-bump-token.sh` - mint the `write:repository` token via the Forgejo API, store at SSM (no `--overwrite`, never echoes the value). - [ ] `docs/FEATURES.md` entry. ## Prerequisite Before apply, the SSM param must exist. Run on a machine with Forgejo basic-auth creds, AWS creds for us-east-1, and coily: FORGEJO_USER=<u> FORGEJO_PASS=<p> ./scripts/provision-tap-bump-token.sh ## Run order 1. `./scripts/provision-tap-bump-token.sh` (above). 2. `sudo k3s kubectl apply -f deploy/forgejo-runner-tap-writer.yml` 3. Confirm the runner registers `tap-writer:host` and picks up a job. 4. Merge ward#46 last (its bump job waits on the `tap-writer` label existing). ## Verify points - **Host executor may be gated.** Some `forgejo/runner` builds disable the host executor for safety. If the runner will not run `tap-writer:host` jobs, fall back to a `docker://node:20-bookworm` label (reintroduces a dockerd dependency). - **Token file uid.** Host executor runs the job as the runner uid (root in this image), so the 0400 mount is readable. If the runner is switched to non-root, adjust the mount perms. closes #194 via #195
coilysiren 2026-06-04 05:31:31 +00:00
  • closed this issue
  • added the
    P3
    label
Sign in to join this conversation.
No description provided.