4 GitHub Actions-patronen voor Monorepo ETL
Het draaien van drie sites vanuit één monorepo zorgt voor problemen. Je krijgt te maken met drie afzonderlijke ETL-jobs, drie content-rebuilds en drie deployment-pipelines. Als je deze niet coördineert, botsen ze met elkaar.
Ik heb zes weken besteed aan het testen van schema's om deze opzet te stabiliseren. Hier zijn de vier patronen die ik gebruik.
- Gebruik tijdverschuivingen voor Cron-jobs
Het tegelijkertijd draaien van alle ETL-jobs veroorzaakt fouten. Jobs concurreren om API-rate limits. Wanneer HuggingFace of GitHub een 429-fout teruggeeft, mislukt de run.
Ik gebruik verschuivingen van 30 minuten om dit te voorkomen.
- Job één start om 02:00
- Job twee start om 02:30
- Job drie start om 03:00
Dertig minuten is genoeg tijd om een zware pull af te ronden voordat de volgende job start. Dit houdt je logs schoon en voorkomt API-botsingen.
- Gebruik skip-flags om onnodige rebuilds te stoppen
Elke ETL-job eindigt met een Vercel-deployment. Er ontstaat een probleem wanneer commits van artikelen ook rebuilds triggeren. Zonder plan dwingt elke artikelupdate alle drie de sites om opnieuw te builden. Dit verspilt build-minuten.
Ik gebruik een [skip publish-articles] tag in ETL-commitberichten.
Ik heb een stap in mijn workflow toegevoegd om deze flag te controleren. Als de tag bestaat, slaat de workflow de build- en deploy-stap over. Dit houdt ETL-pipelines gescheiden van artikel-pipelines.
- Gebruik path-filters om specifieke sites te targeten
Je wilt niet dat een update van de ene site drie deployments triggert. Ik configureer de workflow van elke site om alleen de eigen map en de map met gedeelde packages te bewaken.
Voorbeeld-logica:
- AI tools-site bewaakt alleen apps/ai-tools/
- OSS-site bewaakt alleen apps/oss-alternatives/
Als je code wijzigt in de gedeelde directory, zullen alle sites opnieuw builden. Ik accepteer deze trade-off omdat wijzigingen in gedeelde code zeldzaam zijn.
- Voeg manual dispatch toe voor controle
Cron regelt de dagelijkse routine. Manual dispatch regelt de rest. Ik gebruik workflow_dispatch zodat ik het volgende kan doen:
- Een mislukte ETL-job opnieuw draaien
- Een refresh forceren na het toevoegen van data
- Een dry run uitvoeren om data te testen zonder naar de database te schrijven
De GitHub UI toont een dropdownmenu voor deze keuzes. Dit voorkomt typefouten en maakt debuggen eenvoudig.
Samenvatting
Deze patronen zijn niet complex. Ze zijn expliciet. Ik houd een eenvoudig markdown-bestand bij in mijn repository om deze regels te documenteren. Dit zorgt ervoor dat ik het systeem niet kapot maak wanneer ik nieuwe workflows toevoeg.