88 lines
3.7 KiB
Markdown
88 lines
3.7 KiB
Markdown
# 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.
|