GitHub Actions pourrait être bien meilleur

 (blog.yossarian.net)
2 points par GN⁺ 2023-09-24 | 1 commentaires | Partager sur WhatsApp
  • GitHub Actions est utile en termes de productivité et de fonctionnalités, mais dans la rédaction concrète de workflows, les délais de débogage, les erreurs de sécurité, l’absence de typage et le manque d’actions officielles entraînent des pertes de temps récurrentes
  • Même pour de petites corrections, il faut répéter git add; git commit; git push puis consulter les logs dans le navigateur ; dans un cas, même un workflow de release simple a nécessité 4 commits et des releases échouées
  • L’expansion ${{... }}, pull_request_target, les permissions par défaut très larges de GITHUB_TOKEN et les références SHA de forks sont autant de points de sécurité propices aux erreurs ; en particulier, un SHA de fork peut ressembler à un commit du dépôt visé
  • Les entrées d’actions n’ont pas de validation type:, et la prise en charge diffère aussi entre workflow_call et workflow_dispatch, ce qui oblige à gérer soi-même des chaînes de type CSV ou des entrées aplaties au lieu d’entrées tableau ou objet
  • La validation au moment du push, les contrôles de sécurité à l’exécution, la réduction des permissions par défaut des tokens dans les dépôts personnels, un typage plus strict et davantage d’actions officielles ou semi-officielles pourraient améliorer la fiabilité des workflows

GitHub Actions : utile, mais source récurrente de blocages

  • GitHub Actions est, depuis 2019, un outil suffisamment utilisé au quotidien dans des projets professionnels comme personnels pour apporter un vrai gain de productivité et de stabilité
  • Ses fonctionnalités ont aussi continué à s’étendre régulièrement
  • Pourtant, dans le développement réel, il peut aussi devenir une source de grande frustration et de perte de temps

Le débogage est trop lourd, même pour de petites erreurs

  • Lors de la configuration d’un workflow de release, il est arrivé qu’il faille 4 commits et 4 releases échouées pour corriger de petites erreurs
    • Oubli de ${{ ... }} là où c’était nécessaire
    • Oubli d’une relation needs:
  • Le cycle de débogage actuel comporte beaucoup d’étapes, même pour vérifier une simple erreur
    • Passer de l’environnement de développement au navigateur
    • Trouver le bon onglet
    • Cliquer dans le résumé Actions et l’écran d’état
    • Actualiser les logs console mis en mémoire tampon pour trouver l’erreur suivante
  • Même une petite modification peut faire prendre plus de 30 secondes à l’ensemble du processus

  • Pistes d’amélioration

    • Fournir un shell de débogage interactif, ou au minimum permettre de relancer un workflow avec de petites modifications sans git add; git commit; git push
    • Un paramètre de dépôt devrait permettre de refuser au moment du push les workflows manifestement invalides
      • Syntaxe impossible à exécuter
      • Références à des jobs ou steps inexistants
      • Situations où un YAML invalide empêche silencieusement le workflow de s’exécuter

Les erreurs de sécurité arrivent trop facilement

  • Dans GitHub Actions, il est facile qu’un workflow écrit par l’utilisateur devienne vulnérable sans que ce soit intentionnel
  • Quand l’expansion ${{ ... }} est utilisée dans un shell ou un autre contexte d’exécution, si la valeur expansée est une entrée contrôlée par l’utilisateur, cela peut conduire à une injection de code malveillant
    • Dans l’exemple, du code peut être injecté via inputs.frob et $MY_IMPORTANT_SECRET peut fuiter
  • pull_request_target est très difficile à utiliser de façon sûre dans les workflows non triviaux
    • Le cas d’usage prévu semble être un périmètre étroit, comme ajouter un label ou un commentaire à une PR provenant d’un fork
    • Mais dans la pratique, il est exposé comme un gros foot-gun
  • Les permissions au niveau du workflow et des jobs sont aussi faciles à configurer de façon excessive
    • Les droits d’accès par défaut du GITHUB_TOKEN standard sont très larges
    • Dans les dépôts de comptes personnels, on oublie souvent de réduire les permissions par défaut du token
    • Faute de connaître précisément le périmètre de permissions nécessaire, on accorde trop de droits au token
  • Le modèle de permissions de GitHub, forcé dans un seul axe read/write/none, ajoute à la confusion
    • id-token: write permet de lire le token OpenID Connect du workflow
    • Certaines opérations GET de security advisory exigent la permission write, tandis que d’autres ne nécessitent que read

Les actions figées sur un SHA peuvent être confondues avec des commits de fork

  • Une référence comme actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e peut en réalité ne pas être un commit du dépôt actions/checkout
  • Ce SHA est un commit situé dans un fork du réseau actions/checkout, et l’utilisation des alternates par GitHub peut le faire apparaître comme s’il appartenait au dépôt parent
  • L’article de Chainguard sur le sujet divise le problème en trois points
    • Les références SHA d’un fork et celles du dépôt cible ne se distinguent pas visuellement
    • L’API REST GitHub /repos/{user}/{repo}/commits/{ref} renvoie une réponse JSON qui ne référence que {user}/{repo}, même si {ref} n’existe que dans un fork
    • Si l’on ne peut pas distinguer les SHA de forks des SHA hors forks, il devient possible de contourner la restriction des sources de confiance de GitHub Actions
  • Jusqu’ici, la réponse de GitHub s’est limitée à ajouter une mention dans la documentation

  • Pistes d’amélioration

    • Il faut un mode paranoid workflow security capable de refuser au moment du push les workflows manifestement dangereux
    • Comme l’instrumentation à l’exécution de type AddressSanitizer, l’exécution d’un workflow devrait pouvoir échouer lorsqu’elle détecte des motifs dangereux pour la sécurité
      • Exemple : échec si actions/checkout utilise, dans pull_request_target, une ref qui n’appartient pas au dépôt cible
    • Il pourrait aussi être envisagé de déprécier ou de supprimer pull_request_target
    • Même dans les dépôts personnels, il devrait être possible de configurer par défaut un périmètre GITHUB_TOKEN plus restrictif, comme dans les organisations et les entreprises
    • Les actions SHA-pinned dont le SHA n’existe pas dans le dépôt référencé et n’existe que dans un fork devraient être rejetées par défaut

Le système de types manque de cohérence et d’expressivité

  • Une GitHub Action personnalisée peut définir des entrées sous inputs:, mais les entrées d’action n’ont pas de typage imposé
  • Une déclaration comme type: number ne fonctionne pas pour les entrées d’action
  • Même à l’intérieur de GitHub Actions, les endroits où les types sont pris en charge ne sont pas cohérents
    • workflow_call : prise en charge de boolean, number, string
    • workflow_dispatch : prise en charge de boolean, choice, number, string
    • action inputs : aucune prise en charge des types
  • Même les entrées qui prennent en charge les types ne gèrent pas les structures de données complexes comme les tableaux ou les objets
    • Impossible d’avoir une entrée tableau comme paths: [foo, bar, baz]
    • Impossible d’avoir une entrée objet avec une structure hiérarchique sous headers:
  • Les auteurs d’actions doivent donc demander des entrées dans des formats ad hoc
    • Implémenter eux-mêmes un parsing façon CSV, comme paths: foo,bar,baz
    • Aplatir une structure hiérarchique naturelle avec header-foo, header-baz
  • Ces approches sont mauvaises à la fois pour la maintenabilité et pour la sécurité
    • Il faut gérer soi-même un espace de noms d’entrées plat unique
    • On finit par créer des langages arbitraires non spécifiés pour des entrées complexes

  • Pistes d’amélioration

    • Les auteurs d’actions et de workflows devraient pouvoir utiliser type: partout
    • choice ne devrait pas être limité à workflow_dispatch, mais disponible partout
    • Quand le type peut être inféré statiquement, les modifications de workflow au mauvais type devraient être rejetées au moment du push
    • type: object et type: array sont nécessaires
    • Même si ce ne serait pas parfait parce que les types internes peuvent être hétérogènes, ce serait déjà mieux qu’aujourd’hui
    • Si nécessaire, les valeurs peuvent être transmises sous forme de chaînes sérialisées en JSON
    • GitHub Actions dispose déjà de la fonction fromJSON(...)

Les actions officielles sont directement liées à la confiance dans la plateforme

  • L’écosystème tiers de GitHub Actions compte de nombreuses actions de grande qualité
  • En dessous se trouvent les actions officielles maintenues par GitHub
    • Opérations git essentielles : actions/checkout
    • Opérations GitHub et gestion de dépôt : actions/{upload,download}-artifact, actions/cache, actions/stale
    • Configuration indispensable : actions/setup-python, actions/setup-node
  • Ces actions ont une forte portée générale et une grande importance, ce qui donne beaucoup de valeur à des implémentations maintenues officiellement
  • Mais les actions officielles sont peu nombreuses, et certaines opérations reliant directement des fonctionnalités GitHub ne sont pas fournies sous forme d’action officielle
    • Exemple : une action pour ajouter programmatiquement une pull request à une merge queue
    • GitHub CLI propose gh pr merge, mais ce n’est pas exposé comme une action

  • Exemples d’actions officielles abandonnées

  • Pistes d’amélioration de l’écosystème

    • Les tâches qui relient directement différentes parties de l’infrastructure GitHub et qui nécessitent aujourd’hui des appels REST API ou l’exécution manuelle de gh mériteraient d’être fournies sous forme d’actions officielles
    • GitHub pourrait coopérer avec de grandes actions tierces pour créer une organisation semi-officielle du type community-actions
      • Actions examinées par GitHub
      • Respect des bonnes pratiques de sécurité des dépôts
      • Mises à jour en versionnement sémantique
      • Chemin de confiance clair pour les actions majeures de l’écosystème

Outils existants et feuille de route GitHub

  • Plusieurs personnes recommandent nektos/act, un outil d’émulation locale de GitHub Actions
    • Utile pour itérer rapidement et déboguer des workflows simples
    • Mais les images et les événements ne correspondent pas toujours exactement à l’environnement réel de GitHub, ce qui en fait un outil avec pertes
  • rhysd/actionlint est utilisé pour le linting local et le linting de sécurité
    • Sa limite est qu’il ne peut linter que les workflows, pas les actions
  • GitHub Actions extension for VS Code fournit du linting dans l’éditeur et une intégration des workflows du dépôt
    • Elle s’appuie sur le schéma JSON public
    • Elle affiche les workflows en cours d’exécution et propose la complétion des variables, entre autres
    • Mais il reste des problèmes qu’elle ne détecte pas, comme les fautes de frappe dans les secrets ou dans les noms d’outputs générés dynamiquement, ce qui rend toujours nécessaire le débogage add-commit-push
  • Julian Dunn, responsable de la gestion de projet de GitHub Actions, a partagé plusieurs fonctionnalités et priorités en cours
    • Le débogage interactif figure dans la feuille de route publique de GitHub Actions
    • Le passage du workflow pinning fondé sur les tags et les SHA à une approche plus immuable figure aussi dans la feuille de route publique
    • GitHub considère la santé et la qualité de l’écosystème des actions officielles comme une priorité, et adopte une stratégie consistant à maintenir un petit nombre d’actions officielles afin d’accorder à chacune suffisamment de maintenance et d’attention

À lire aussi

1 commentaires

 
GN⁺ 2023-09-24
Avis sur Hacker News

  • Il existe deux façons d’aborder les workflows GitHub Actions. 1) « Programmer » avec GitHub Actions, y compris en branchant des outils du Marketplace pour envoyer des e-mails, avec un YAML qui finit par atteindre 500 à 1 000 lignes, truffé de conditions et difficile à comprendre
    2) Ne faire que de la « configuration » dans GitHub Actions, en se demandant constamment : « Est-ce que je peux repousser cette complexité YAML dans un script ? » Si l’envoi d’e-mails est aussi mis dans un script, le workflow tient en 50 à 60 lignes, on peut déboguer le script en local, et la boucle idiote push-debug-commit disparaît presque entièrement. À chaque fois que j’arrive dans une nouvelle équipe, je dis que la première voie est celle de la folie et que la deuxième est raisonnable, mais environ la moitié choisit encore la première. Le manque d’outils de débogage et le verrouillage fournisseur posent aussi beaucoup moins problème si l’on choisit la deuxième approche

    • Je suis largement d’accord avec ce point de vue. Si l’on n’essaie pas de programmer GitHub Actions en YAML et qu’on le traite uniquement comme un système d’exécution de tâches, beaucoup de souffrances disparaissent
      Cela dit, tout pousser dans un vrai langage de programmation ne suffit pas toujours. Il arrive qu’il faille utiliser des fonctionnalités propres au fournisseur dans GHA, représenter des dépendances entre tâches, ou appeler une API REST déjà bien abstraite sous forme d’action. On peut les réimplémenter dans le langage de son choix, mais cela ne supprime pas la dépendance au fournisseur et reste fragile. Au final, la proposition de valeur liée au verrouillage fournisseur de GHA est très forte ; pour convaincre les gens d’adopter l’option 2, il faut donc des avantages encore plus solides
    • La deuxième approche permet aussi aux développeurs d’exécuter le build en local plus facilement. On utilise la même chaîne de build pour le débogage local et pour les environnements de test/staging/production, sans avoir à maintenir des procédures de build différentes
      Cela vaut non seulement pour GHA, mais pour tous les serveurs de build. Un serveur de build devrait être un exécuteur de scripts qui ajoute l’historique, la gestion des artefacts, les droits et l’audit ; le processus de build réel devrait être délégué au dépôt cible
    • Bon point de vue. Mais si l’on veut automatiser GitHub lui-même, par exemple pour attribuer des rôles ou poser des tags, l’option 1 est difficile à éviter. Malgré tout, aujourd’hui, je préférerais gérer une bonne partie de ces tâches manuellement plutôt que subir l’affreuse boucle de débogage de GHA
      À noter qu’il existe nektos/act pour reproduire le comportement de GHA en local : https://github.com/nektos/act
    • Je me demande comment on débogue les actions. Passer autant de temps dans une boucle commit-action-debug-change est presque absurde. Je suis entièrement d’accord pour dire que l’approche 2 rend le débogage des scripts bien plus simple. La CI doit pouvoir être exécutée en local, mais même s’il existe quelques outils, GitHub Actions ne rend pas cela facile
    • La principale raison de viser l’option 2, c’est de pouvoir lancer le build en local même si GitHub est indisponible, et de pouvoir le déplacer facilement ailleurs si nécessaire
      Les étapes de build/test/signature/déploiement, etc. devraient être écrites sous forme de scripts aussi portables que possible, et ces scripts devraient toujours fonctionner en local. Je vois GitHub uniquement comme un environnement qui prépare automatiquement de quoi exécuter ces scripts, puis les lance effectivement

  • La boucle git commit, push, wait est une expérience utilisateur catastrophique. Les utilisateurs méritent des pipelines portables qui s’exécutent partout, y compris sur leur machine locale. Act résout en partie ce problème, mais dans l’ensemble il ne représente pas vraiment l’environnement réel à l’identique
    Beaucoup de pipelines ne peuvent pas être exécutés en local comme en production, mais pour les étapes de développement moins critiques, rien n’empêche de capturer ces workflows et de les exécuter localement. Garden fournit des pipelines portables et ajoute du cache sur l’ensemble du graphe de dépendances. Certains clients ont réduit les temps d’exécution de plus de 80 %, et les développeurs voient immédiatement si les tests passent ou échouent sans devoir d’abord pousser vers git. C’est open source : https://github.com/nektos/act, https://docs.garden.io

    • Si les gens avaient simplement fait en sorte que les actions appellent make ou des scripts bash, au lieu de bourrer des scripts bash à l’intérieur des actions, ce problème n’existerait pas. La CI/CD et les développeurs devraient tous utiliser les mêmes cibles/commandes, comme make release
    • On dirait qu’on a beaucoup perdu le principe selon lequel « la CI ne doit pas être un flocon de neige spécial » quand on a commencé à créer des équipes spécialisées en DevOps et en outils DevOps. Dès que quelque chose devient un métier, on a l’impression d’atteindre le point de bascule où cela devient excessivement complexe. J’observe le même phénomène avec l’Agile avec un grand A et les scrum masters qui doivent remplir leur temps
    • Les imperfections d’Act m’ont plusieurs fois fait creuser au mauvais endroit. Pour l’instant, je suis revenu à l’ancienne boucle, en espérant que cela s’améliore avec le temps
    • Les pipelines de build auraient eux aussi besoin de quelque chose comme Terraform. Si vous utilisez Bitbucket, que Dieu vous vienne en aide
    • La landing page de garden.io semble cassée sur iOS. Elle déborde vers la droite de l’écran

  • Je compatis totalement à la douleur que représente le débogage des exécutions de GH Actions. Les seuls outils dont on dispose, c’est d’activer le debug et de relancer. J’ai beaucoup trop de commits poubelle faits pour corriger ou déboguer des pipelines, et la plupart relèvent du « je balance ça pour voir si ça marche »
    Même des choses très basiques, comme de la logique réutilisable, sont inutilement complexes ou mal documentées. Une fois qu’on le sait, c’est assez simple, mais la documentation de GitHub était catastrophique. On avait l’impression que, pour obtenir de la réutilisabilité, il fallait rendre une action publique ou la placer dans un autre dépôt, alors qu’en réalité on peut créer un nouveau fichier YAML contenant la logique réutilisable. Il faut simplement le mettre à la racine du dossier workflows pour que ça fonctionne. Travailler avec GH Actions est vraiment pénible, mais une fois que ça marche, c’est très pratique. Ce serait bien d’avoir quelque chose comme un runner local pour tester les actions avant de commit et push

    • Une approche consiste à utiliser une draft PR. On peut y exécuter les changements de YAML d’actions, puis, une fois satisfait, squash les commits proprement dans la PR destinée au vrai merge. Pour déboguer ou développer de la logique GH Action, les draft PR se sont révélées plutôt correctes
    • Il existe un outil qui ne fait pas tout, mais qui est assez utile : https://github.com/nektos/act
    • Quand je corrige la CI, je pousse toujours sur une feature branch puis je fais un squash merge à la fin. Les corrections rapides qui se font en une seule fois sont rares ; ça finit toujours en 3 à 10 commits
    • J’ai déjà essayé d’exécuter l’image GitHub runner, ou une image qui l’imite, et la configuration ainsi que le comportement de certaines fonctionnalités étaient extrêmement pénibles. J’ai abandonné au bout de deux jours
      Ce n’est pas propre à GitHub. Les autres grandes plateformes de CI ne font pas vraiment mieux en matière de workflows et d’intégration. Aujourd’hui, je script au maximum tout ce que je peux
    • C’est l’une des principales raisons pour lesquelles nous avons créé Earthly : pouvoir exécuter les builds en local et obtenir de la cohérence avec la CI

  • GitHub Actions est un mauvais système de CI/CD. On ne peut pas exécuter des étapes en parallèle sur la même VM, et les jobs basés sur des conteneurs sont traités comme des citoyens de seconde zone
    À cause du premier problème, on ne peut pas paralléliser la configuration des identifiants locaux ou des dépendances d’environnement. Voir google-github-actions/setup-gcloud prendre plus d’une minute me met en colère. À cause du second, il est très difficile d’exprimer la configuration de l’environnement de CI avec un Dockerfile dans le dépôt, de faire en sorte que la CI reconstruise l’image quand son contenu change et mette en attente les workflows qui en dépendent, et qu’elle démarre immédiatement avec les dépendances déjà installées quand le contenu n’a pas changé, sans reconstruire l’image. Avec GitHub Actions, on se retrouve à vouloir remplir le cache à chaque fois. Le cache est limité à 5 Go, on ne peut pas l’augmenter même en payant, et il est évincé en FIFO : dès qu’on dépasse 5 Go, c’est pratiquement comme s’il n’existait pas. Concourse me manque vraiment. On pouvait y faire des tâches en parallèle, des déclencheurs de pipeline personnalisés, entrer en SSH dans l’environnement de CI pour déboguer, exécuter des tâches ponctuelles sans pipeline, transmettre le contenu d’un répertoire entre tâches sans produire d’artefacts, etc. GitHub Actions ressemble davantage à un jouet de CI/CD devenu populaire grâce à une barrière d’entrée faible — il suffit de déposer un fichier dans .github/workflows pour l’utiliser. C’est bien pour attirer des utilisateurs, mais au-delà des fonctionnalités initiales, ce n’est pas assez puissant pour être qualifié de « meilleur »

    • La limite de cache à 5 Go va peut-être me permettre d’enquêter sur ce problème de « cache de build qui casse bizarrement ». Merci pour l’info
    • Concourse est excellent. Je ne savais pas que l’équipe avait été démantelée, c’est vraiment dommage. La façon dont Zito communiquait était aussi excellente
    • Je dirais que c’est plutôt VMWare, après l’acquisition, qui l’a démantelée, plus que Pivotal. En interne, beaucoup de gens aimaient Concourse. Cela dit, j’étais parti avant l’acquisition
      Le débogage en SSH et les tâches ponctuelles étaient vraiment un rêve
    • Je me demande si tu as regardé Tekton : https://tekton.dev/
    • Il existe une solution déjà en place qui prend en compte beaucoup de ces problèmes. J’aimerais avoir des avis. Ce serait bien de partager ton e-mail ou de me contacter à lawnchair@lawnchair.net

  • Je ne comprends pas comment le fait que GitHub ne distingue pas les références SHA provenant de forks et de non-forks, ce qui permet à un fork de contourner les réglages de sécurité de GitHub Actions, n’a toujours pas été corrigé
    Si un contrôle de sécurité peut être facilement contourné, c’est une faille de sécurité majeure. Il faut certes convaincre quelqu’un d’utiliser mon SHA, mais l’ingénierie sociale est généralement la partie facile

  • Franchement, c’est gênant à quel point c’est mauvais. C’est aussi étrange que les notifications pour un échec de build sans rapport n’aillent qu’au dernier maintainer ayant mergé quelque chose. Je pourrais ne pas savoir pendant une semaine que ma mise à jour/mon build échoue, jusqu’à ce qu’un maintainer nouvellement ajouté me le signale sur Matrix
    L’action de cache est manifestement cassée, rien qu’en la regardant, et elle semble ne pas avoir de mainteneur. On ne peut même pas suivre en tail les logs de build d’une étape si l’UI tombe en panne ou si l’onglet est déchargé. Il n’y a pratiquement aucune abstraction pour rendre les workflows portables entre nœuds workers. Les images de base sont presque une catastrophe. Au début, je trouvais simplement ça agaçant parce qu’elles étaient trop énormes, mais plus j’ai creusé, plus je me suis dit : « quelqu’un chez Microsoft qui ne connaît pas Linux a dû s’en occuper ». Il n’y a aucun effort pour fournir des images plus légères à ceux qui utilisent Nix ou Docker. Je suis en train de quitter GitHub, et la raison principale est qu’Actions m’a brutalement ouvert les yeux. Si je ne programme pas en YAML, c’est parce que je considère YAML comme une honte produite par un déversement d’argent VC sur un écosystème qui ne connaît pas les technologies modernes réellement utiles

    • Quand Microsoft a racheté GitHub, ce genre de chose n’était-il pas prévisible ?

  • Je recommande vivement https://pre-commit.ci. Je n’y suis pas lié, je suis simplement un utilisateur satisfait
    L’idée consiste à écrire des hooks, ou à utiliser des hooks existants, qui vérifient le code avant le commit et le corrigent si possible ; puis, après le push, la CI vérifie à nouveau et, si nécessaire, crée même automatiquement un commit de correction. La mise en cache automatique est excellente, au point que c’est presque difficile à croire tant c’est rapide, et comme on utilise la même configuration sur la machine de développement locale et dans la CI, cela réduit beaucoup les problèmes de débogage. C’est gratuit pour l’open source. Ça ne fait pas de release automatique ni ce genre de choses, seulement des vérifications, mais il les fait très bien

    • Pour les projets Python, c’est particulièrement intéressant à utiliser avec tox. tox crée un virtualenv correspondant à la version de Python que l’on veut tester, puis exécute les tests dedans
      Pour vérifier le code source lui-même, on peut aussi lancer des contrôles statiques avec skip_install = True. Il suffit de l’exécuter dans un conteneur où tox est installé comme outil global et où toutes les versions de Python nécessaires sont présentes. Il existe par exemple des images comme https://github.com/georgek/docker-python-multiversion. Elle n’est pas maintenue, mais elle est facile à mettre à jour. Un peu de boilerplate du type [tox] envlist = py{310,311}, [testenv], et [testenv:check] avec pre-commit run --all-files --show-diff-on-failure suffit

  • Après avoir subi trop souvent la boucle git commit; git push; repeat, j’ai découvert https://github.com/mxschmitt/action-tmate. Cela ouvre un accès shell entre les étapes, donc ça ne résout pas tous les problèmes, mais parfois cela réduit nettement la douleur

  • Personnellement, j’aimerais pouvoir attacher des rapports HTML à une exécution d’action sans avoir à utiliser quelque chose comme actions/upload-artifact
    En particulier pour les builds de test, on veut souvent consulter rapidement le rapport HTML généré. Les méthodes que je connais aujourd’hui sont upload-artifact ou GH Pages, mais GH Pages n’est pas idéale quand un même dépôt produit plusieurs rapports, ou quand on veut consulter rapidement un ancien rapport plutôt que le dernier. Ce serait bien d’avoir une action simple attach-report qui ajoute un lien vers le rapport HTML dans le résumé du job et qui, au clic, rend le HTML. D’autres systèmes d’automatisation CI/CD prennent en charge nativement la capture et la consultation de rapports HTML de façon bien plus riche

    • Ce n’est pas du HTML, mais on peut ajouter directement une sortie Markdown dans $GITHUB_STEP_SUMMARY sans passer par l’upload d’artefacts ou autre

  • À mon avis, GH Actions est en fait assez proche d’un rebranding par Microsoft d’« Azure Pipelines ». Pour avoir utilisé toutes les anciennes formes des pipelines de build et de release de TFS/VSTS/AzDO, cette équipe ne fait pas bien ce genre de choses
    Si Azure Pipelines est devenu à peu près utilisable, c’est seulement parce que toutes les approches essayées auparavant avaient littéralement échoué. Il y avait aussi un projet pour exécuter les pipelines en local, afin de pouvoir faire une boucle edit-run-debug dans son environnement personnel sans commit, mais il a évidemment été annulé : https://github.com/microsoft/azure-pipelines-agent/pull/2687/files#diff-570b52bcb927a5365c22d17a21e8e19e1ba3427c7f3ec16ea64b7b3d14e4ee20. Il existe malgré tout des outils qui améliorent la qualité de vie. Par exemple, une extension VS Code qui comprend la syntaxe : https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines. De façon un peu polémique, si l’on avait utilisé XML au lieu de YAML, une simple déclaration xmlns en haut du fichier aurait permis la validation dans la plupart des bons éditeurs de code sans intervention supplémentaire de l’utilisateur. XML est horrible, mais en le jetant entièrement, nous avons aussi perdu beaucoup de fonctionnalités utiles

    • Je pensais que GHA était un projet déjà assez avancé en interne chez GitHub, indépendamment, avant l’acquisition par Microsoft. Je me demande si cela veut dire que GHA a été recréé par-dessus AzP, que c’est simplement AzP avec un nouveau nom, ou autre chose
    • C’est probablement plus vrai que la plupart des gens ne le pensent. Après l’acquisition, une grande partie de l’équipe AzDo est passée sur GitHub Actions/Projects
    • J’étais d’accord jusqu’au dernier paragraphe. XML fait mal aux yeux. Plutôt qu’une horreur faite de chevrons et de camelCase, je choisirais un document YAML bien formaté, même s’il y a de la souffrance