Skip to content

ci(deploy): auto-deploy releases via self-hosted runners#130

Merged
obcode merged 1 commit into
mainfrom
ci/auto-deploy-runners
Jul 20, 2026
Merged

ci(deploy): auto-deploy releases via self-hosted runners#130
obcode merged 1 commit into
mainfrom
ci/auto-deploy-runners

Conversation

@obcode

@obcode obcode commented Jul 20, 2026

Copy link
Copy Markdown
Owner

Nachzug zu Milestone F: Auto-Deploy wie bei plexams. Die Images bauen auf GitHub-hosted Runnern (docker.yml), aber der Deploy-Host ist VPN-intern — GitHub kommt nicht rein. Lösung: ein self-hosted Runner auf dem Host pollt ausgehend und rollt jeden Release lokal aus.

Betrifft beide Repos; das ist der glabs-Teil (Backend-Deploy + Runner-Services + Doku). Der glabs.gui-Deploy-Job folgt separat in dem Repo.

Inhalt

  • docker.yml — neuer, gated deploy-Job (needs: build-and-push-image, if: vars.AUTO_DEPLOY == 'true', runs-on: [self-hosted, glabs-deploy]): synct nicht-geheime Infra (docker-compose.yml + Caddyfile) nach $DEPLOY_DIR, pinnt GLABS_WEB_TAG in .env, docker compose pull glabs-web + up -d, Caddy nur bei geändertem Caddyfile force-recreate. Secrets (.env, .glabs-web.yaml) + caddy-data-Volume bleiben unangetastet.
  • deploy/docker-compose.yml — zwei gh-runner-Services unter profiles: [runner] (je Repo einer — persönlicher Account → repo-scoped; gemeinsames Label glabs-deploy). Das Profil hält sie aus dem Default-up -d raus → ein Deploy startet den Runner nie mitten im eigenen Job neu.
  • .env.exampleDEPLOY_DIR + GH_RUNNER_PAT. README — Abschnitt „Automatischer Deploy" (einmaliges Host-Setup, AUTO_DEPLOY-Gate, Rollback).

Verifikation

  • docker compose config: Default-Stack ohne Runner (5 Services), Profil runner fügt gh-runner+gh-runner-gui hinzu; DEPLOY_DIR-Bind-Mount auf beiden Seiten identisch (/home/glabs/glabs/deploy).
  • actionlint: nur die erwartete Info „unbekanntes self-hosted-Label glabs-deploy" (Custom-Label, wie plexams' plexams-deploy) — kein Fehler.
  • Der Deploy-Pfad selbst ist erst am Zielhost mit registriertem Runner + AUTO_DEPLOY=true fahrbar (per Design).

ci:-Titel → kein Release-Bump.

🤖 Generated with Claude Code

The images build on GitHub-hosted runners, but the deploy host is
VPN-internal — GitHub cannot push in. Mirror the plexams pattern: a
self-hosted runner ON the host polls GitHub outbound and rolls out each
release locally.

- docker.yml gains a gated `deploy` job (needs the build job, `if:
  vars.AUTO_DEPLOY == 'true'`, runs-on [self-hosted, glabs-deploy]): syncs
  the non-secret infra (docker-compose.yml + Caddyfile) into $DEPLOY_DIR,
  pins GLABS_WEB_TAG in .env, `docker compose pull glabs-web` + `up -d`,
  force-recreates caddy only if the Caddyfile changed. Secrets (.env,
  .glabs-web.yaml) and the caddy-data volume are never touched.
- deploy/docker-compose.yml gains two gh-runner services under `profiles:
  [runner]` (one per repo — obcode is a personal account, so runners are
  repo-scoped; shared label glabs-deploy). The profile keeps them out of
  the default `up -d`, so a deploy never restarts the runner mid-job.
- .env.example: DEPLOY_DIR + GH_RUNNER_PAT. README: "Automatischer Deploy"
  (one-time host setup, the AUTO_DEPLOY gate, rollback).

The glabs.gui deploy job follows in that repo. Until AUTO_DEPLOY=true the
image is still built & pushed; the deploy job is simply skipped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@obcode
obcode merged commit 5c710b7 into main Jul 20, 2026
8 checks passed
@obcode
obcode deleted the ci/auto-deploy-runners branch July 20, 2026 12:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant