- Frustrations autour de GitHub Actions
- L’équipe est composée d’environ 15 ingénieurs, et tout le monde pousse continuellement du code sur la branche
main
- Le code est organisé dans un monorepo découpé en plusieurs modules, avec des déploiements effectués plusieurs fois par jour via une approche de développement basée sur le trunk
- GitHub Actions peut être très utile dans certains cas, mais à partir d’une certaine échelle ou dans certains environnements, ses limites apparaissent clairement
Pull requests et vérifications obligatoires
- Le monorepo est divisé en plusieurs dossiers, et chaque dossier gère indépendamment ses tests, ses builds et ses déploiements
- La fonctionnalité
paths de GitHub Actions est utilisée pour ne déclencher un pipeline que lorsqu’un dossier donné est modifié
- Exiger que toutes les vérifications passent avant de fusionner une pull request est un bon principe, mais cela pose problème lorsqu’on le combine avec une structure en monorepo
- Exemple : un check nommé
web-app1 - Unit tests a été défini comme « obligatoire », mais s’il n’y a aucun changement dans le dossier web-app1, ce check ne s’exécute pas
- Résultat : même si un seul dossier est modifié, les tests liés aux autres dossiers ne s’exécutent pas non plus, ce qui peut rendre la fusion tout simplement impossible
- Si GitHub gérait cela non pas par le nom des checks obligatoires, mais avec une logique du type « la fusion est possible si tous les checks effectivement déclenchés ont réussi », le problème serait résolu ; il est regrettable qu’aucun changement n’ait eu lieu depuis 3 ans
- Les discussions GitHub associées, 1 et 2, montrent aussi l’ampleur de l’impact de ce problème
- Au final, contourner cela impose d’exécuter des pipelines supplémentaires ou d’en maintenir davantage, ce qui devient complexe et coûteux
Réutilisabilité et YAML
- Plus les pipelines grossissent, plus il devient difficile d’en assurer la gestion avec GitHub Actions
- On finit par accumuler beaucoup de conditions
if, et même en séparant les workflows, le nombre de fichiers à gérer augmente, ce qui nuit à la maintenabilité
- Même les appels qui devraient tenir en une ligne lorsqu’on réutilise des éléments nécessitent plusieurs lignes et des configurations dupliquées, au point que le dossier
.github contient déjà plus de 30 fichiers
- Avec la clause
needs, si un refactoring ne répercute pas la suppression d’un job, il peut s’écouler du temps avant que l’erreur soit repérée
- On ne peut pas exécuter GitHub Actions en local, ce qui complique le développement et les tests
- Il existe des outils comme
act, mais dans la pratique ils ont souvent de nombreuses limitations et sont loin de répondre aux attentes
Le manque d’intérêt de GitHub
- Le plus gros problème parmi ceux évoqués ci-dessus est l’impression que GitHub ne considère pas vraiment ces sujets comme importants
- De nombreux tickets sont ouverts depuis des années et ne figurent pas sur la feuille de route publique, ce qui ne donne pas l’impression d’une réelle volonté d’amélioration
- Même certains problèmes discutés depuis très longtemps ont récemment vu leurs tickets fermés en masse, suscitant une réaction négative de la communauté
Options
- Compte tenu de ces problèmes et du manque apparent de volonté de GitHub de les corriger, il faut bien réfléchir avant d’adopter GitHub Actions
- Le marché propose de nombreuses autres options de CI/CD, comme GitLab, Jenkins ou TeamCity
- Des outils comme Dagger, qui proposent une approche plus récente, méritent également d’être examinés
6 commentaires
Pour le CI/CD, GitLab est le meilleur
Moi aussi, après avoir utilisé GitLab, je me souviens qu’en me retrouvant dans l’environnement GitHub Actions, j’avais l’impression que rien ne fonctionnait...
L’un de mes gros mécontentements, c’est aussi qu’on ne puisse pas gérer les dépôts sur GitHub en les regroupant par catégories..
Pour les pipelines, je trouve vraiment que GitLab est excellent. Tout ce qui a été mentionné plus haut, GitLab le fait.
Dans le cas d’un monorepo, il est pratique de configurer quels tests ou quels éléments doivent être exécutés lorsqu’un certain dossier est modifié.
Il faut connaître l’histoire de GitHub Actions pour comprendre ça…
Au départ, GitHub Actions avait un visage différent de celui d’aujourd’hui…
Environ six mois avant son ouverture (mes souvenirs sont un peu flous), GitHub a été racheté par Microsoft, et il me semble que le développement d’Actions devait se faire conjointement avec l’équipe Azure DevOps chez Microsoft.
À ce moment-là, Azure DevOps ne recevait plus vraiment de nouvelles fonctionnalités, et ce sont les fonctionnalités d’Azure DevOps qui apparaissaient comme nouveautés dans GitHub Actions…
C’est à cette époque que le passage au YAML a eu lieu et que l’environnement actuel s’est mis en place… snif.
Depuis, on a l’impression que les développeurs sont repartis chacun de leur côté et qu’il n’y a plus vraiment eu de suivi…
C’est dommage…
Dans mon entreprise actuelle, on a mis en place le CI/CD sur la base de GitHub Actions… pour l’instant on continue de l’utiliser parce qu’il ne nous manque encore rien de vraiment bloquant…
Mais il va falloir garder un œil dessus…
Avis Hacker News
Un DSL de pipeline ne devrait pas contenir la logique métier elle-même, mais seulement servir à orchestrer les tâches. Les opérations complexes devraient être mises dans des scripts exécutables simplement. Cela permet d’exécuter facilement les mêmes tâches sur GitHub Actions, Jenkins, Azure DevOps, etc.
Lors de la configuration de GitHub Actions, il vaut mieux éviter les actions préfabriquées et l’utiliser simplement comme lanceur de shell. Si l’on écrit des scripts en Python, Ruby, Bash, etc. et qu’on les exécute depuis GitHub Actions, les tests en local deviennent plus faciles et on s’épargne bien des douleurs inutiles.
GitHub Actions peut exécuter des vérifications uniquement lorsque certaines conditions sont remplies. Mais si l’on utilise ces règles, on se heurte au problème des « pull requests et vérifications obligatoires ». Avec des services externes, les vérifications obligatoires doivent impérativement réussir, sinon il est impossible de fusionner.
Pour résoudre le problème des « pull requests et vérifications obligatoires », on peut créer une version « no op » de chaque workflow de vérification obligatoire, qui s’exécute lorsque les conditions ne sont pas remplies et se termine avec le code 0. C’est une solution fondée sur les fonctionnalités de base, mais assez complexe.
Travis CI était excellent pour tester le CI en local. GitHub Actions a été créé pour concurrencer GitLab CI, alors que GitHub perdait des parts sur le marché des entreprises.
Il est recommandé d’essayer Buildkite. Au-delà de GitHub Actions, Buildkite peut être une bonne alternative. J’en ai eu l’expérience dans une grande entreprise technologique américaine, et c’était la seule partie agréable du CI.
L’architecture de GitHub Actions peut amener à prendre de mauvaises décisions de sécurité. Par exemple, les secrets d’organisation ou de dépôt sont pratiques, mais peuvent devenir des vulnérabilités. Les environnements de dépôt peuvent avoir des secrets séparés, mais il faut s’assurer que seuls les bons workflows peuvent accéder aux bons environnements.
La philosophie générale des systèmes de CI est erronée. Au lieu que le CI exécute le code, c’est le code qui devrait exécuter le CI. Le CI devrait fournir une API afin que les utilisateurs puissent transmettre des informations au système.
En utilisant Bazel, on peut faire en sorte que l’outil de CI construise des cibles Bazel et, si nécessaire, augmenter le parallélisme via l’exécution de builds à distance. C’est adapté à environ 10M+ lignes de code ou à des services de grande taille.
Sur GitHub, on peut définir des « vérifications obligatoires » qui doivent toujours être au vert. Mais comme elles ne s’exécutent que lorsqu’il y a des changements dans certains dossiers, il devient impossible de fusionner lorsqu’il y a des modifications ailleurs. Si l’on n’exécute pas tous les tests, l’intégration perd son sens ; il faut donc faire en sorte que les tests puissent s’exécuter rapidement.