joerglohrer
/
joerglohrerde
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
joerglohrerde/docs/github-ci-setup.md

3.7 KiB
Raw Blame History

GitHub-CI-Setup für die Publish-Pipeline

Kontext: Das primäre Repo liegt in Forgejo (self-hosted). Für CI nutzen wir GitHub als Push-Mirror-Ziel, weil Forgejo keine Woodpecker-Integration hat. GitHub Actions triggert automatisch bei Push auf main mit Änderungen unter content/posts/**.

Setup-Schritte

1. Forgejo → GitHub Push-Mirror

In Forgejo:

  • Repo → Settings → Mirrors → Push Mirror hinzufügen
  • Ziel-URL: das entsprechende GitHub-Repo (z. B. https://github.com/<user>/joerglohrerde.git)
  • Authentifizierung: GitHub-Personal-Access-Token (repo-Scope)
  • Intervall: nach Belieben (z. B. alle 8 Stunden, oder „bei jedem Push")

2. GitHub-Repository-Secrets

In GitHub, Repo → Settings → Secrets and variables → Actions:

Vier Repository-Secrets anlegen (nicht Environment-Secrets — wir haben keine Environments):

Name Wert Quelle
BUNKER_URL bunker://<hex>?relay=wss://...&secret=... aus .env.local
AUTHOR_PUBKEY_HEX 4fa5d1c413e2b45e10d40bf3562ab701a5331206e359c90baae0e99bfd6c6e41 aus .env.local
BOOTSTRAP_RELAY wss://relay.primal.net aus .env.local
CLIENT_SECRET_HEX 929f0cd946fd5266e63ccdb066ce7a0cc93391133bfce6098fe633fc72e03e96 aus .env.local

Wichtig:

  • Alle vier müssen gesetzt sein, sonst schlägt der Workflow fehl.
  • Der CLIENT_SECRET_HEX ist identisch mit dem in .env.local — damit sich CI-Runner und lokaler Rechner bei Amber mit derselben Client-Identität anmelden. Die Permissions in Amber gelten dann für beide.

3. Workflow-Datei

Liegt in .github/workflows/publish.yml. Triggert auf:

  • push auf main mit Änderungen unter content/posts/**
  • workflow_dispatch (manuelles Triggern über das GitHub-UI, optional mit force_all=true)

4. Secrets rotieren

Wenn der Bunker-Pairing-Secret mal kompromittiert wird oder Amber neu eingerichtet wird:

  1. In Amber neue Bunker-URL erzeugen
  2. Lokale .env.local aktualisieren
  3. GitHub-Secret BUNKER_URL ebenfalls aktualisieren (Settings → Secrets → edit)
  4. In Amber für die neue App wieder "Allow + Always" für get_public_key + sign_event setzen

Der CLIENT_SECRET_HEX muss in der Regel nicht rotiert werden — nur wenn du die App in Amber komplett neu pairen willst. Wenn du ihn doch änderst, muss Amber die App neu registrieren (siehe Setup).

Monitoring

  • Workflow-Runs: GitHub → Actions → "Publish Nostr Events"
  • Logs pro Run: pro Run ein Artefakt publish-log mit der publish-*.json, 30 Tage Aufbewahrung
  • Lokal laufen bleibt möglich via cd publish && deno task publish … — CI ist eine zusätzliche Automatisierung, kein Zwang.

Bekannte Einschränkungen

  • Amber muss online sein während CI-Runs, sonst scheitert die Bunker- Signatur. Wenn das Handy tot ist: Workflow failed → einfach neu triggern, sobald Amber wieder erreichbar.
  • relay.damus.io antwortet gelegentlich nicht mit OK; das ist ein bekanntes Damus-Verhalten und wird von MIN_RELAY_ACKS=2 toleriert.
  • Staging-Subdomain (staging.joerg-lohrer.de) hat nichts mit dieser Pipeline zu tun — sie gehört zum SPA-Deploy. Die Publish-Pipeline nutzt ausschließlich Blossom für Bild-Hosting.

Migration weg von GitHub (später)

Wenn Woodpecker oder ein anderer self-hosted Runner aufgesetzt wird, bleibt der Deno-Workflow derselbe — nur die CI-Konfiguration ändert sich:

  • .github/workflows/publish.yml → .woodpecker.yaml (oder .gitea/workflows/)
  • Secrets in Woodpecker statt GitHub
  • Trigger-Bedingungen analog (push main + path filter)

Der Pipeline-Code selbst (publish/src/**) ist CI-agnostisch und braucht keine Änderung.