La souffrance qu’est GitHub Actions

• Les problèmes de GitHub Actions

  • J’ai récemment passé beaucoup de temps à réécrire des scripts de CI avec GitHub Actions. J’utilisais auparavant Earthly, mais le projet a été abandonné, ce qui m’a forcé à revenir à GitHub Actions.
  • La CI est complexe et inclut une file d’attente de fusion, plusieurs runners, des builds Rust, des images Docker, des tests d’intégration, etc. Chaque fusion de PR consomme énormément de temps de CI.
  • Les bonnes pratiques logicielles exigent que tous les tests passent, que les petites erreurs soient corrigées automatiquement et que les artefacts testés soient identiques à ceux de la release. GitHub Actions permet cela, mais sa configuration est complexe et incohérente.

• Vérifications d’état et file d’attente de fusion

  • La file d’attente de fusion de GitHub rebase une PR sur la branche principale avant d’exécuter la CI. Mais il faut exécuter la CI à la fois avant et après l’entrée dans la file d’attente, et cela est difficile à configurer.
  • La solution consiste à définir le même nom de job aux deux étapes. Cela permet d’exiger la réussite des deux phases.

• Problèmes de sécurité

  • Une GitHub Action populaire a récemment été compromise. En réponse, il a été recommandé d’épingler les dépendances par hash, mais la plupart des utilisateurs ne le font pas.
  • Le modèle de sécurité de GitHub est complexe et difficile à comprendre. Il est possible de définir les permissions par défaut de GITHUB_TOKEN, mais la manière de retirer des permissions n’est pas claire.
  • Les permissions du workflow ne dépendent pas de l’action elle-même, et le fait d’élever les permissions dans le code paraît étrange.

• La combinaison de Docker et GitHub Actions

  • GitHub Actions permet d’exécuter des tâches dans un conteneur, mais cela provoque des problèmes comme les permissions de fichiers et le changement d’emplacement du répertoire $HOME.
  • Le champ container comporte de nombreuses limitations, ce qui empêche par exemple de redéfinir l’entrypoint ou d’exécuter seulement certaines étapes dans le conteneur.

• Développer des workflows en YAML

  • Écrire de la logique en YAML peut vite devenir complexe et propice aux erreurs. J’ai utilisé l’IDE RustRover pour effectuer certaines vérifications, mais de meilleurs contrôles statiques sont nécessaires.
  • Il est difficile de tester en local, si bien qu’il faut créer le même dépôt, puis répéter les commits et les push jusqu’à ce que la CI fonctionne.
  • Il faut garder les workflows petits et pousser des artefacts pour pouvoir les réutiliser dans d’autres workflows. Mais télécharger des artefacts nécessite un token.

• Conclusion

  • Le nouveau script de CI a nettement réduit le temps de fusion, mais le processus de configuration reste complexe et le débogage difficile. Il faut de l’innovation.

[GN⁺]

Avis Hacker News

• Certains estiment que GitLab est meilleur, mais GitLab a aussi ses propres problèmes d’une autre manière

  • Après avoir utilisé plusieurs outils de CI, il est important d’écrire autant que possible la logique de CI dans son propre code
  • Il faut investir pour pouvoir exécuter le pipeline en local sur la machine du développeur
  • Il faut éviter YAML autant que possible
  • Il ne faut pas dépendre de nouveaux outils financés par du capital-risque
  • Il faut utiliser autant que possible ses propres runners et les exploiter on-premise

• Il est intéressant de constater que GitHub Actions et le DevOps sont largement critiqués

  • La configuration et les tests peuvent être fastidieux, mais une fois que ça fonctionne, on n’y touche presque plus
  • À part les mises à jour de version de Node, je n’ai presque pas modifié le workflow en 4 ans
  • Personnellement, j’en suis satisfait

• Je suis passé de GitLab à GitHub, mais j’ai été déçu

  • J’ai le sentiment que GitHub Actions est très en retrait par rapport à GitLab
  • Si je dirigeais une entreprise, je choisirais GitLab

• Une boucle de feedback de 30 à 60 secondes, c’est le pire

  • J’ai essayé de reproduire l’environnement GHA en local, mais c’était impossible
  • Une petite erreur peut faire perdre énormément de temps

• Je ne veux pas que la CI modifie automatiquement le code

  • Les vérifications mineures devraient être exécutées via un hook pre-commit

• Je suis déçu, on dirait que l’évolution de GitHub Actions s’est arrêtée

  • Il est regrettable qu’Earthly et Dagger aient arrêté leur développement
  • Après avoir évalué Depot.dev, il semble qu’une équipe très intelligente ait bien résolu le problème

• GitHub Actions pousse à détourner les conteneurs en scripts d’installation

  • Dans les workflows, beaucoup de temps est consacré à l’exécution d’installateurs

• Il est important de choisir l’outil adapté

  • GitHub Actions convient aux tâches simples, mais pas aux tâches complexes

• À cause des problèmes de sécurité de GitHub Actions, il faut verrouiller les dépendances avec des hash

  • Avec des hash, c’est beaucoup plus sûr

• GitHub Actions a de nombreux problèmes

  • Limite de cache de 10 Go, limites de concurrence selon le type de runner, coût élevé, etc.
  • Depot.dev essaie de rendre GitHub Actions plus rapide et de résoudre ses problèmes
  • Cela accélère la construction des images Docker et optimise les runners pour rendre les tâches très rapides
  • GitHub Actions est populaire, mais il y a encore beaucoup de marge d’amélioration