Ici, nous présentons GitHub Actions et les workflows.

Vous allez découvrir les types d’actions que vous pouvez utiliser et où les trouver. Vous verrez également des exemples de ces actions et comment elles s’intègrent dans un workflow.

GitHub réduit le temps entre l’idée et le déploiement

GitHub est conçu pour aider les équipes de développeurs et d’ingénieurs DevOps à créer et déployer des applications rapidement. De nombreuses fonctionnalités de GitHub permettent ces gains d’efficacité, qui se répartissent généralement en deux grandes catégories :

• Communication : GitHub facilite la collaboration entre les membres d’une équipe grâce aux revues de code dans les pull requests, aux issues, aux tableaux de projet, aux wikis, aux notifications, etc.
• Automatisation : GitHub Actions permet à votre équipe d’automatiser les workflows à chaque étape du processus de développement logiciel, de l’intégration à la livraison, jusqu’au déploiement. Il est même possible d’automatiser l’ajout d’étiquettes aux pull requests ou la détection des issues obsolètes.

Combinées, ces fonctionnalités ont permis à des milliers d’équipes de développement de réduire efficacement le temps entre l’idée initiale et le déploiement.

Utiliser l’automatisation des workflows pour réduire le temps de développement

Dans ce module, nous nous concentrons sur l’automatisation. Prenons un moment pour comprendre comment les équipes peuvent utiliser l’automatisation afin de réduire le temps nécessaire à l’exécution d’un workflow de développement et de déploiement typique.

Considérez toutes les tâches à effectuer après l’écriture du code, mais avant de pouvoir l’utiliser de manière fiable. Selon les objectifs de votre organisation, vous devrez probablement :

• Vérifier que le code passe tous les tests unitaires.
• Effectuer des contrôles de qualité et de conformité pour s’assurer que le code respecte les normes de l’organisation.
• Analyser le code et ses dépendances à la recherche de failles de sécurité connues.
• Compiler le code en intégrant les contributions de plusieurs développeurs.
• Vérifier que le logiciel passe les tests d’intégration.
• Définir la version de la nouvelle build.
• Livrer les nouveaux fichiers binaires à l’emplacement approprié.
• Déployer les binaires sur un ou plusieurs serveurs.
• Identifier les tâches échouées et en informer la personne ou l’équipe concernée.

Le défi est d’exécuter ces tâches de manière fiable, cohérente et durable. C’est un cas idéal pour l’automatisation des workflows. Si vous utilisez déjà GitHub, il est logique de configurer cette automatisation avec GitHub Actions.

Qu’est-ce que GitHub Actions ?

GitHub Actions sont des scripts packagés permettant d’automatiser des tâches dans un workflow de développement logiciel sur GitHub. Vous pouvez configurer GitHub Actions pour déclencher des workflows complexes adaptés aux besoins de votre organisation. Le déclencheur peut être un push de code sur une branche, un intervalle de temps défini, ou une action manuelle. Le résultat est un workflow automatisé, fiable et durable, qui réduit considérablement le temps de développement.

Où trouver les GitHub Actions ?

Les GitHub Actions sont des scripts au format de données YAML (.yml). Chaque dépôt GitHub possède un onglet Actions qui permet de démarrer facilement la configuration de votre premier script. Si vous trouvez un workflow qui vous semble être un bon point de départ, cliquez simplement sur le bouton Configurer pour ajouter le script et commencer à modifier le fichier source YAML.

Au-delà des GitHub Actions proposées dans l’onglet Actions, vous pouvez également :

• Rechercher des GitHub Actions dans le GitHub Marketplace : Le Marketplace vous permet de découvrir et d’acheter des outils qui étendent vos workflows.
• Explorer des projets open source : Par exemple, l’organisation GitHub Actions propose de nombreux dépôts open source populaires contenant des actions que vous pouvez utiliser.
• Écrire vos propres GitHub Actions depuis zéro : Vous pouvez les rendre open source ou même les publier sur le GitHub Marketplace.

Utiliser des GitHub Actions open source

De nombreuses GitHub Actions sont open source et disponibles pour tous. Cependant, comme pour tout logiciel open source, il est important de les examiner attentivement avant de les intégrer à votre projet. Voici quelques bonnes pratiques à suivre, similaires aux standards communautaires recommandés pour les projets open source (README, code de conduite, fichier de contribution, modèles d’issues, etc.) :

• Examiner le fichier action.yml de l’action pour comprendre les entrées, les sorties, et vérifier que le code fait bien ce qu’il prétend faire.
• Vérifier si l’action est présente sur le GitHub Marketplace : Même si ce n’est pas obligatoire, cela peut être un gage de qualité.
• Vérifier si l’action est certifiée sur le Marketplace : Une action vérifiée a été approuvée par GitHub, mais il est tout de même recommandé de la revoir avant utilisation.
• Spécifier la version de l’action utilisée en indiquant une référence Git, un SHA ou un tag, pour garantir la stabilité.

Types de GitHub Actions

Il existe trois types de GitHub Actions :

1. Actions basées sur des conteneurs
   • L’environnement d’exécution fait partie du code de l’action.
   • Ces actions ne peuvent être exécutées que dans un environnement Linux hébergé par GitHub.
   • Elles prennent en charge de nombreux langages de programmation.
2. Actions JavaScript
   • L’environnement n’est pas inclus dans le code.
   • Vous devez spécifier l’environnement d’exécution.
   • Ces actions peuvent être exécutées dans une machine virtuelle (VM) dans le cloud ou sur site.
   • Compatibles avec Linux, macOS et Windows.
3. Actions composites
   • Permettent de combiner plusieurs étapes de workflow dans une seule action.
   • Par exemple, vous pouvez regrouper plusieurs commandes run dans une action, puis exécuter ces commandes comme une seule étape dans un workflow.

Anatomie d’une GitHub Action

Voici un exemple d’action qui effectue un checkout Git d’un dépôt.
L’action actions/checkout@v1 fait partie d’une étape dans un workflow. Cette étape compile également le code Node.js extrait du dépôt.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Supposons que vous souhaitiez utiliser une action basée sur un conteneur pour exécuter du code conteneurisé.

Votre action pourrait ressembler à ceci :

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Remarquez la section inputs.

Ici, vous récupérez la valeur d’une variable appelée MY_NAME. Cette variable est définie dans le workflow qui exécute cette action.

Dans la section runs,

vous spécifiez docker dans l’attribut uses. Lorsque vous définissez cette valeur, vous devez fournir le chemin vers le fichier de l’image Docker — dans ce cas, Dockerfile.
Nous n’entrons pas ici dans les détails de Docker, mais si vous souhaitez en savoir plus, consultez le module Introduction aux conteneurs Docker.

La dernière section, branding,

personnalise votre action dans le GitHub Marketplace si vous décidez de la publier.

Vous pouvez consulter la liste complète des métadonnées d’une action dans la documentation : Syntaxe des métadonnées pour GitHub Actions.

Qu’est-ce qu’un workflow GitHub Actions ?

Un workflow GitHub Actions est un processus que vous configurez dans votre dépôt pour automatiser les tâches du cycle de vie du développement logiciel, y compris l’exécution d’actions GitHub.
Avec un workflow, vous pouvez compiler, tester, empaqueter, publier et déployer n’importe quel projet sur GitHub.

Pour créer un workflow, vous ajoutez des actions dans un fichier .yml situé dans le répertoire .github/workflows de votre dépôt GitHub.

Dans l’exercice à venir, votre fichier de workflow main.yml ressemblera à cet exemple :

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Remarquez l’attribut on:

Sa valeur est un déclencheur qui spécifie quand ce workflow doit s’exécuter.
Dans cet exemple, il est déclenché lorsqu’un événement de type push se produit sur votre dépôt.

Vous pouvez spécifier :

• un événement unique comme on: push,
• un tableau d’événements comme on: [push, pull_request],
• ou une carte de configuration d’événements (event-configuration map) qui permet de planifier un workflow ou de restreindre son exécution à certains fichiers, balises (tags) ou modifications de branches.

Une carte de configuration pourrait ressembler à ceci :

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

Un événement déclenche toutes les activités associées, sauf si vous spécifiez un ou plusieurs types d’activités.

Pour une liste complète des événements et de leurs types d’activités, consultez la documentation GitHub : Événements qui déclenchent des workflows.

Un workflow doit contenir au moins un job. Un job est une section du workflow associée à un runner.
Un runner peut être hébergé par GitHub ou auto-hébergé, et le job peut s’exécuter sur une machine ou dans un conteneur. Vous spécifiez le runner avec l’attribut runs-on:.
Dans cet exemple, vous indiquez que le job doit s’exécuter sur ubuntu-latest.

Chaque job contient des étapes (steps) à exécuter. Dans notre exemple, l’étape utilise l’action actions/checkout@v1 pour effectuer un checkout du dépôt.
Ce qui est intéressant ici, c’est la valeur uses: ./action-a, qui correspond au chemin vers l’action conteneurisée que vous avez définie dans un fichier action.yml.

La dernière partie de ce fichier de workflow définit la variable MY_NAME pour ce workflow.
Rappelez-vous que l’action conteneurisée attendait une entrée appelée MY_NAME.

Pour plus d’informations sur la syntaxe des workflows, consultez : Syntaxe des workflows pour GitHub Actions.

Runners GitHub hébergés vs auto-hébergés

Nous avons brièvement mentionné que les runners sont associés à un job.
Un runner est simplement un serveur sur lequel l’application GitHub Actions Runner est installée.

Dans l’exemple précédent, l’attribut runs-on: ubuntu-latest indique que le job s’exécutera sur un runner GitHub hébergé dans un environnement Ubuntu à jour.

Il existe deux types de runners :

• Runners GitHub hébergés : chaque job s’exécute dans une instance propre d’un environnement virtuel. Vous spécifiez l’environnement avec runs-on: {système d’exploitation-version}.
• Runners auto-hébergés : vous devez spécifier le label self-hosted, le système d’exploitation et l’architecture.
  Par exemple, un runner auto-hébergé sous Linux avec une architecture ARM32 se spécifie ainsi :
  runs-on: [self-hosted, linux, ARM32].

Avantages des différents types de runners

• Les runners GitHub hébergés sont plus simples et rapides à utiliser, mais avec des options limitées.
• Les runners auto-hébergés sont hautement configurables et peuvent être exécutés sur site ou dans le cloud.
  Ils permettent :
  • d’utiliser du matériel personnalisé (plus de puissance ou de mémoire),
  • d’installer des logiciels spécifiques à votre réseau local,
  • de choisir un système d’exploitation non proposé par GitHub.

GitHub Actions a des limites d’utilisation

GitHub Actions impose certaines limites d’utilisation, selon votre plan GitHub et le type de runner utilisé (hébergé ou auto-hébergé).
Pour plus d’informations, consultez : Limites d’utilisation, facturation et administration.

Runners GitHub hébergés de grande capacité

GitHub propose des runners plus puissants pour les workflows nécessitant davantage de ressources.
Ces runners offrent plus de CPU, de mémoire et d’espace disque que les runners standards.

Ils sont conçus pour exécuter efficacement des workflows intensifs, comme :

• Compilation de grandes bases de code
• Exécution de suites de tests complètes (intégration, end-to-end)
• Traitement de grands ensembles de données (analyse, machine learning)
• Construction d’applications avec de nombreuses dépendances
• Simulations haute performance ou modélisation computationnelle
• Encodage vidéo, rendu ou traitement multimédia

Taille et étiquettes des runners

Les runners de grande capacité sont disponibles en plusieurs configurations (vCPU, RAM, SSD).
Pour les utiliser, spécifiez l’étiquette du runner dans l’attribut runs-on de votre fichier workflow.

Exemple : pour utiliser un runner avec 16 vCPU et 64 Go de RAM, indiquez :

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Ces exécuteurs plus grands maintiennent la compatibilité avec les workflows existants

Ils incluent les mêmes outils préinstallés que les exécuteurs standards ubuntu-latest.

Pour plus d’informations sur la taille des exécuteurs pour les exécuteurs plus grands, consultez la documentation GitHub

Gérer les exécuteurs plus puissants

GitHub fournit des outils pour gérer efficacement les exécuteurs plus volumineux, garantissant une utilisation optimale des ressources et une bonne gestion des coûts. Voici quelques aspects clés de cette gestion :

Surveillance de l’utilisation

Vous pouvez surveiller l’utilisation des exécuteurs plus puissants via la page d’utilisation GitHub Actions dans les paramètres de votre dépôt ou de votre organisation.
Cette page fournit des informations sur :

• le nombre de tâches exécutées,
• la durée totale d’exécution,
• les coûts associés.

Gestion de l’accès

Pour contrôler l’accès à ces exécuteurs, vous pouvez configurer des stratégies au niveau du dépôt ou de l’organisation.
Cela garantit que seuls les workflows ou les équipes autorisées peuvent utiliser ces ressources élevées.

Gestion des coûts

Les exécuteurs plus puissants entraînent des coûts supplémentaires selon leur utilisation.
Voici quelques suggestions pour mieux gérer ces coûts :

• Utilisez-les uniquement pour les workflows nécessitant des ressources élevées.
• Réduisez le temps d’exécution en optimisant vos workflows.
• Surveillez régulièrement les détails de facturation pour suivre les dépenses.

Mise à l’échelle des workflows

Si vos workflows nécessitent fréquemment des exécuteurs plus puissants, envisagez les stratégies suivantes :

• Utiliser des exécuteurs auto-hébergés pour les charges de travail prévisibles.
• Fractionner les workflows en tâches plus petites pour répartir la charge entre les exécuteurs standards.