4 modèles de GitHub Actions pour l'ETL en monorepo
Gérer trois sites à partir d'un seul monorepo pose problème. Vous faites face à trois jobs ETL distincts, trois reconstructions de contenu et trois pipelines de déploiement. Si vous ne les coordonnez pas, ils entrent en collision.
J'ai passé six semaines à tester des calendriers pour stabiliser cette configuration. Voici les quatre modèles que j'utilise.
- Utiliser des décalages temporels pour les tâches Cron
Lancer tous les jobs ETL en même temps provoque des échecs. Les jobs se disputent les limites de taux (rate limits) des API. Lorsque HuggingFace ou GitHub renvoie une erreur 429, l'exécution échoue.
J'utilise des décalages de 30 minutes pour éviter cela.
- Le premier job commence à 02:00
- Le deuxième job commence à 02:30
- Le troisième job commence à 03:00
Trente minutes sont suffisantes pour terminer un pull volumineux avant que le job suivant ne commence. Cela permet de garder vos logs propres et d'éviter les collisions d'API.
- Utiliser des drapeaux d'exclusion (skip flags) pour arrêter les reconstructions inutiles
Chaque job ETL se termine par un déploiement Vercel. Un problème survient lorsque les commits d'articles déclenchent également des reconstructions. Sans plan, chaque mise à jour d'article force la reconstruction des trois sites. Cela gaspille des minutes de build.
J'utilise une balise [skip publish-articles] dans les messages de commit ETL.
J'ai ajouté une étape dans mon workflow pour vérifier la présence de ce drapeau. Si la balise existe, le workflow ignore l'étape de build et de déploiement. Cela permet de séparer les pipelines ETL des pipelines d'articles.
- Utiliser des filtres de chemin pour cibler des sites spécifiques
Vous ne voulez pas qu'une mise à jour d'un site déclenche trois déploiements. Je configure le workflow de chaque site pour qu'il surveille uniquement son propre dossier et le dossier des packages partagés.
Logique d'exemple :
- Le site des outils IA surveille uniquement
apps/ai-tools/ - Le site OSS surveille uniquement
apps/oss-alternatives/
Si vous modifiez le code dans le répertoire partagé, tous les sites seront reconstruits. J'accepte ce compromis car les changements de code partagé sont rares.
- Ajouter un déclenchement manuel (manual dispatch) pour plus de contrôle
Cron gère la routine quotidienne. Le déclenchement manuel gère tout le reste. J'utilise workflow_dispatch pour pouvoir :
- Relancer un job ETL ayant échoué
- Forcer un rafraîchissement après l'ajout de données
- Effectuer un test à blanc (dry run) pour tester les données sans écrire dans la base de données
L'interface utilisateur de GitHub affiche un menu déroulant pour ces choix. Cela évite les fautes de frappe et facilite le débogage.
Résumé
Ces modèles ne sont pas complexes. Ils sont explicites. Je garde un simple fichier markdown dans mon dépôt pour documenter ces règles. Cela garantit que je ne casse pas le système lorsque j'ajoute de nouveaux workflows.