4 GitHub Actions-Muster für Monorepo-ETL
Das Ausführen von drei Websites aus einem einzigen Monorepo heraus verursacht Probleme. Man sieht sich mit drei separaten ETL-Jobs, drei Content-Rebuilds und drei Deployment-Pipelines konfrontiert. Wenn man diese nicht koordiniert, kollidieren sie.
Ich habe sechs Wochen damit verbracht, Zeitpläne zu testen, um dieses Setup zu stabilisieren. Hier sind die vier Muster, die ich verwende.
1. Zeitversatz (Time Offsets) für Cron-Jobs verwenden
Das gleichzeitige Ausführen aller ETL-Jobs führt zu Fehlern. Die Jobs konkurrieren um die API-Rate-Limits. Wenn HuggingFace oder GitHub einen 429-Fehler zurückgibt, schlägt der Durchlauf fehl.
Ich verwende 30-minütige Zeitversätze, um dies zu verhindern.
- Job eins startet um 02:00 Uhr
- Job zwei startet um 02:30 Uhr
- Job drei startet um 03:00 Uhr
Dreißig Minuten sind genug Zeit, um einen umfangreichen Pull abzuschließen, bevor der nächste Job startet. Das hält die Logs sauber und verhindert API-Kollisionen.
2. Skip-Flags verwenden, um unnötige Rebuilds zu stoppen
Jeder ETL-Job endet mit einem Vercel-Deployment. Ein Problem entsteht, wenn Commits von Artikeln ebenfalls Rebuilds auslösen. Ohne einen Plan erzwingt jede Artikelaktualisierung einen Rebuild aller drei Websites. Das verschwendet Build-Minuten.
Ich verwende ein [skip publish-articles]-Tag in den ETL-Commit-Nachrichten.
Ich habe einen Schritt in meinem Workflow hinzugefügt, um nach diesem Flag zu suchen. Wenn das Tag existiert, überspringt der Workflow den Build- und Deploy-Schritt. So bleiben die ETL-Pipelines von den Artikel-Pipelines getrennt.
3. Pfadfilter (Path Filters) verwenden, um gezielt bestimmte Websites anzusprechen
Man möchte nicht, dass die Aktualisierung einer Website drei Deployments auslöst. Ich konfiguriere den Workflow jeder Website so, dass er nur seinen eigenen Ordner und den Ordner für gemeinsam genutzte Pakete (shared packages) überwacht.
Beispiel-Logik:
- Die AI-Tools-Website überwacht nur
apps/ai-tools/ - Die OSS-Website überwacht nur
apps/oss-alternatives/
Wenn Sie Code im gemeinsamen Verzeichnis ändern, werden alle Websites neu aufgebaut. Diesen Kompromiss akzeptiere ich, da Änderungen am gemeinsamen Code selten sind.
4. Manual Dispatch für mehr Kontrolle hinzufügen
Cron übernimmt die tägliche Routine. Manual Dispatch übernimmt alles andere. Ich verwende workflow_dispatch, damit ich Folgendes tun kann:
- Einen fehlgeschlagenen ETL-Job erneut ausführen
- Eine Aktualisierung nach dem Hinzufügen von Daten erzwingen
- Einen Dry Run durchführen, um Daten zu testen, ohne sie in die Datenbank zu schreiben
Die GitHub-Benutzeroberfläche zeigt ein Dropdown-Menü für diese Optionen an. Dies verhindert Tippfehler und erleichtert das Debugging.
Zusammenfassung
Diese Muster sind nicht komplex. Sie sind explizit. Ich führe eine einfache Markdown-Datei in meinem Repository, um diese Regeln zu dokumentieren. Dies stellt sicher, dass ich das System nicht beschädige, wenn ich neue Workflows hinzufüge.