GitHub Actions : bonnes pratiques

Ce document évolutif est un recueil de bonnes pratiques pour utiliser GitHub Actions. Si tu as des suggestions ou des ajouts, n'hésite pas à ouvrir une pull request sur GitHub !

Recueil de bonnes pratiques

Définis des délais d'expiration pour les workflows

Par défaut, GitHub Actions interrompt les workflows au bout de 6 heures s'ils ne sont pas terminés avant. Beaucoup de workflows ont besoin de bien moins de temps que ça pour se terminer, mais il arrive qu'une erreur inattendue survienne ou qu'un job reste bloqué jusqu'à ce que l'exécution du workflow soit interrompue, 6 heures après son lancement. Il est donc recommandé de définir un délai d'expiration plus court.

Le délai d'expiration idéal dépend de chaque workflow, mais 30 minutes suffisent généralement largement pour les workflows utilisés dans les dépôts Exercism.

Cela présente les avantages suivants :

  • Les PR ne restent plus en attente de la CI pendant la moitié de la journée : les problèmes peuvent être détectés tôt, ou l'exécution du workflow peut être relancée.
  • Le nombre total de builds parallèles est limité : les jobs bloqués ne gênent pas les autres PR s'ils sont annulés rapidement.

Exemple

jobs:
  configlet:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - [...]

Demande-toi si les actions (tierces) sont vraiment nécessaires

Les actions doivent être considérées comme des dépendances dans ton langage de programmation préféré1 : ce sont du code écrit par des tiers, hors du contrôle d'Exercism. Même si tu fais confiance aux auteurs de l'action, le dépôt peut faire l'objet d'une prise de contrôle hostile, ce qui donnerait indirectement à ces personnes l'accès aux dépôts Exercism, y compris en écriture.

Par conséquent, demande-toi sérieusement si l'ajout d'une nouvelle action vaut vraiment le coup, ou s'il vaut mieux déplacer le code dans une action (nouvelle) sous le contrôle d'Exercism.

Vérifie aussi si l'action est activement maintenue, par exemple en regardant l'activité récente du dépôt ou en t'assurant qu'elle appartient à une organisation plutôt qu'à un compte individuel.

Les actions publiées par GitHub ou par l'organisation Exercism peuvent généralement être considérées comme sûres (ou presque) et être incluses sans examen particulier.

Limite la portée du jeton de workflow

Par défaut, le jeton d'accès fourni au workflow dispose de permissions très larges, en lecture comme en écriture.

Le principe du moindre privilège doit aussi s'appliquer aux workflows.

Tu peux indiquer les permissions dont un workflow a besoin au niveau de chaque workflow.

Exemple

Si un workflow a seulement besoin de lire le contenu d'un dépôt sans y écrire, par exemple parce qu'il s'agit d'une simple vérification de CI, tu peux restreindre le jeton comme ceci :

permissions:
  contents: read

Consulte la documentation GitHub pour la liste complète des permissions.

Épingle les actions sur des SHA

Quand tu utilises d'autres actions, épingle-les sur un commit (via son SHA), et non sur une branche ou un tag. Ainsi, c'est toujours le même code qui sera exécuté, ce qui n'est pas garanti lorsqu'on épingle sur une branche ou un tag.

Cela présente deux avantages :

  1. Cela rend ton build stable
  2. Cela empêche un attaquant de modifier une branche ou un tag pour qu'elle pointe vers du code malveillant

La seule exception à cette règle concerne les actions que nous (Exercism) avons écrites nous-mêmes.

Trouve le SHA du commit

En général, tu veux épingler sur le SHA de commit d'une release précise. Pour trouver le SHA de commit d'une release, va sur la page des releases du dépôt de l'action (par exemple https://github.com/actions/checkout/releases). Trouve la release que tu veux utiliser et clique sur le SHA abrégé (par exemple a12a394) indiqué dans la section de résumé à gauche de la release. Tu arriveras alors sur la page de détails de la release, qui indique le SHA de commit complet à utiliser.

Exemple

- name: Checkout code
  uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846

Épingle les exécuteurs de tests sur une version

La plupart des workflows s'exécutent sur les exécuteurs pris en charge par GitHub. Quand tu utilises l'un de ces exécuteurs, choisis une version précise plutôt que la dernière version.

Ainsi, le workflow s'exécute toujours sur le même exécuteur, ce qui rend ton build stable.

Exemple

Utilise :

runs-on: ubuntu-22.04

au lieu de :

runs-on: ubuntu-latest

Demande-toi s'il faut mettre en place une stratégie de concurrence

Il n'est souvent ni nécessaire ni utile de lancer la CI sur les commits intermédiaires si un commit plus récent a été poussé entre-temps.

Tu peux configurer une stratégie de concurrence pour annuler automatiquement les workflows en cours d'exécution dans le même contexte.

Exemple

Pour annuler les builds intermédiaires dans une PR, tu peux utiliser les paramètres de concurrence suivants :

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}
Mention de tiers

L'exemple ci-dessus est tiré du workflow CI de PkgTemplates.jl, publié sous licence MIT :

MIT License

Copyright (c) 2017-2020 Chris de Graaf, Invenia Technical Computing Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Demande-toi quels déclencheurs sont vraiment nécessaires

Lis le guide « Security hardening for GitHub Actions »

Les pratiques mentionnées ci-dessus sont loin d'être exhaustives. Pour un guide complet sur les bonnes pratiques de sécurité et l'utilisation sûre de GitHub Actions, consulte le guide de sécurité de GitHub.

Liste de vérification des workflows

Tu peux utiliser la liste de vérification suivante pour savoir si un workflow suit les bonnes pratiques. Cette liste n'a pas vocation à être exhaustive : elle se concentre sur les points les plus importants.

Version à copier-coller, par exemple pour les PR

  1. sauf si le langage utilise l'écosystème npm. ↩