Dans GitHub Actions, n’importe quel programme peut être utilisé comme shell

• Dans GitHub Actions, il est possible de définir via le mot-clé shell le shell utilisé pour exécuter un bloc run:
• Dans un workflow, c’est facultatif, mais c’est obligatoire dans la définition d’une action individuelle
• La valeur par défaut est choisie automatiquement selon le système d’exploitation : bash sur Linux/macOS, pwsh sur Windows
• Si l’on définit explicitement shell: bash, les drapeaux par défaut suivants sont également inclus : --noprofile --norc -eo pipefail

N’importe quel exécutable peut être défini comme shell

• On a facilement tendance à penser que les valeurs utilisables pour shell sont limitées
• En réalité, tout exécutable présent dans $PATH peut être utilisé comme shell
• Si la commande exécutée n’accepte pas une entrée sous forme de fichier, il faut passer un argument spécial, {0}
• {0} est automatiquement remplacé par GitHub par le chemin d’un fichier temporaire

Exemples expérimentaux

• Il est même possible d’utiliser un compilateur C (tcc) comme shell afin d’exécuter directement du code
• Il est aussi possible de manipuler $PATH pour créer et utiliser un faux shell bash
• GitHub ne se préoccupe pas du fait que la valeur indiquée dans le champ shell corresponde ou non à un exécutable particulier

Implications en matière de sécurité

• Dans GitHub Actions, la frontière entre écriture de fichiers et exécution est floue (avec des possibilités d’exécution via GITHUB_ENV, $GITHUB_PATH, etc.)
• Même des valeurs bien connues comme shell: bash sont résolues via $PATH, sans utiliser un chemin d’exécution fixe comme /bin/bash
• Contrairement à ce que l’on pourrait penser, une valeur comme python n’est pas une simple référence au toolcache, mais bien une exécution basée sur un chemin réel

[tujuc]

Rien qu’en regardant le dépôt github/runner-image, on voit qu’un bon nombre de packages directement utilisables sont déjà installés....

Quand on crée une image, 1 Go partent facilement....

[GN⁺]

Avis Hacker News

• J’ai déjà utilisé le flag -x de bash pour forcer l’affichage de toutes les commandes exécutées dans un workflow Actions. C’est très utile pour le débogage
• Une astuce non officielle sympa de GitHub Actions que j’ai découverte au travail consiste à faire correspondre le nom d’un événement repository_dispatch avec des jokers
  • C’est la seule façon de faire respecter des workflows réutilisables définis via un pipeline de release centralisé
  • Cela permet d’identifier facilement le produit et la version lors du dispatch de l’événement
• Mon expérience me dit que moins on en fait dans GitHub Actions, mieux c’est
  • Je préfère encoder la logique dans un système de build, comme Make, puis l’appeler depuis GitHub Actions, ou
  • écrire un petit programme CLI et l’appeler depuis GitHub Actions
  • Déboguer en local est bien plus simple que déboguer dans la CI
• Il y a eu une génération qui redoutait qu’on lui demande de transformer des feuilles de calcul en code
  • Cette génération redoutera qu’on lui demande d’imposer de la discipline à des déploiements construits avec GitHub Actions
• Le code du GitHub Actions Runner est facile à lire
  • Il existe un endroit précis où sont définis les arguments par défaut pour les shells/binaires populaires
  • ScriptHandler.cs contient tout le code qui prépare l’environnement du processus, les arguments, etc.
  • Globalement, j’ai été agréablement surpris par la simplicité de ce code
• On peut tromper le shell par défaut bash pour exécuter n’importe quel programme
  • Tant que les lecteurs d’une autre action comprennent ce qui se passe, c’est très utile
  • J’ai déjà vu des scripts shell commencer sur quelques lignes puis devenir des monstres de plus de cent lignes
  • Je voulais des fonctionnalités comme les tableaux et le typage de la stdlib Python
• Cela donne de l’espoir pour exécuter facilement du code Go qui lance directement des jobs de CI depuis un fichier YAML de workflow GitHub
  • goeval ne prend pas encore directement en charge l’entrée via fichier
  • Il faut une astuce shell
  • Un peu de boilerplate est nécessaire
  • J’en suis l’auteur
• Je me demande quel est l’intérêt de la YAML de GitHub CI
• Dans la CI/CD, on peut écrire du C et appeler ça du travail système bas niveau
  • On pourrait même écrire de l’assembleur