Comment les actions GitHub automatisent les tâches de développement ?

Ici, nous présentons GitHub Actions et flux de travail. Vous découvrez les types d’actions que vous pouvez utiliser et où les trouver. Vous examinez également des exemples de ces types d’actions et comment elles s’intègrent dans un flux de travail.

GitHub réduit le temps de l’idée au déploiement

GitHub est conçu pour aider les équipes de développeurs et d’ingénieurs DevOps à créer et à déployer rapidement des applications. Il existe de nombreuses fonctionnalités dans GitHub qui permettent ces économies, mais elles appartiennent généralement à l’une des deux catégories suivantes :

• Communication : prenez en compte toutes les façons dont GitHub permet à une équipe de développeurs de communiquer facilement sur le projet de développement logiciel : les révisions de code dans les requêtes de demande de tirage (pull request), les problèmes GitHub, les tableaux de projets, les wikis, les notifications, etc.
• Automatisation : la fonctionnalité GitHub Actions permet à votre équipe d’automatiser des flux de travail à chaque étape du processus de développement logiciel, de l’intégration au déploiement en passant par la livraison. Elle vous permet même d’automatiser l’ajout d’étiquettes à des demandes de tirage, ainsi que la vérification de problèmes et demandes de tirage obsolètes.

Quand elles sont combinées, ces fonctionnalités permettent à des milliers d’équipes de développement de réduire efficacement le temps nécessaire de l’idée initiale au déploiement.

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

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

Examinez toutes les tâches qui doivent se produire après écriture du code, mais avant que vous puissiez utiliser le code de façon fiable pour son rôle prévu. Selon les objectifs de votre organisation, vous devez probablement effectuer une ou plusieurs des tâches suivantes :

• Vérifier que le code réussit tous les tests unitaires.
• Effectuer des vérifications de la conformité et de la qualité du code pour s’assurer que le code source répond aux normes de l’organisation.
• Vérifier le code et ses dépendances pour les problèmes de sécurité connus.
• Générez le code en intégrant un nouveau code source à partir (potentiellement) de plusieurs contributeurs.
• Vérifier que le logiciel réussit les tests d’intégration
• Spécifiez la version du nouveau build.
• Fournir les nouveaux fichiers binaires à l’emplacement approprié du système de fichiers.
• Déployer les nouveaux fichiers binaires sur un ou plusieurs serveurs.
• Déterminez si l’une de ces tâches ne passe pas et signalez le problème à la personne ou à l’équipe appropriée pour la résolution.

Le défi consiste à effectuer ces tâches de façon fiable, cohérente et durable. Ce processus est un travail idéal pour l’automatisation des flux de travail. Si vous vous appuyez déjà sur GitHub, vous souhaiterez probablement configurer votre automatisation de flux de travail à l’aide de GitHub Actions.

Qu’est-ce qu’une action GitHub ?

La fonctionnalité GitHub Actions est un ensemble de scripts empaquetés qui permet d’automatiser les tâches d’un workflow de développement logiciel dans GitHub. Vous pouvez configurer GitHub Actions pour déclencher des flux de travail complexes répondant aux besoins de votre organisation. Le déclencheur peut se produire chaque fois que les développeurs vérifient le nouveau code source dans une branche spécifique, à intervalles chronométrés ou manuellement. Le résultat est un workflow automatisé fiable et viable, ce qui réduit considérablement le temps de développement.

Où pouvez-vous trouver GitHub Actions ?

GitHub Actions sont des scripts qui adhèrent à un format de données yml. Chaque référentiel possède un onglet Actions qui fournit un moyen simple et rapide de commencer à configurer votre premier script. Si vous voyez un workflow que vous pensez être un excellent point de départ, sélectionnez juste le bouton Configurer pour ajouter le script et commencer à modifier la source yml.

Toutefois, au-delà de GitHub Actions proposé sous l’onglet Actions, vous pouvez :

• Rechercher GitHub Actions dans la Place de marché GitHub. La Place de marché GitHub vous permet de découvrir et d’acheter des outils qui étendent votre workflow.
• Rechercher des projets open source. Par exemple, l’organisation GitHub Actions comprend de nombreux dépôts open source populaires contenant les actions GitHub que vous pouvez utiliser.
• Écrire votre propre GitHub Actions à partir de zéro. Vous pouvez les rendre open source, ou même les publier sur la place de marché GitHub.

Utiliser des actions GitHub open source

De nombreuses actions GitHub sont open source et disponibles pour toute personne souhaitant les utiliser. Toutefois, comme avec n’importe quel logiciel open source, vous devez soigneusement les vérifier avant de les utiliser dans votre projet. À l’instar des normes de la communauté recommandées avec des logiciels open source, comme l’inclusion d’un fichier Lisez-moi, d’un code de conduite, d’un fichier de contribution et de l’émission de modèles, vous pouvez suivre les suggestions ci-dessous lors de l’utilisation de GitHub Actions :

• Examinez le fichier action.yml de l’action pour les entrées et les sorties, et assurez-vous que le code fait ce qu’il dit.
• Vérifiez si l’action se trouve sur la Place de marché GitHub. Cette vérification vaut la peine, même si une action n’a pas besoin d’être sur la Place de marché GitHub pour être valide.
• Vérifiez si l’action est vérifiée sur la Place de marché GitHub. La vérification signifie que GitHub a approuvé l’utilisation de cette action. Toutefois, vous devez toujours l’examiner avant de l’utiliser.
• Incluez la version de l’action que vous utilisez en spécifiant une référence Git, un hachage SHA ou une étiquette.

Types d’actions GitHub

Il existe trois types d’actions GitHub : les actions de conteneur, les actions JavaScript et les actions composites.

Avec les actions de conteneur, l’environnement fait partie du code de l’action. Ces actions peuvent uniquement être exécutées dans un environnement Linux que GitHub héberge. Les actions de conteneur prennent en charge un grand nombre de langages.

Les actions JavaScript n’incluent pas l’environnement dans le code. Vous devez spécifier l’environnement pour exécuter ces actions. Vous pouvez exécuter ces actions sur une machine virtuelle locale ou située dans le cloud. Les actions JavaScript prennent en charge les environnements Linux, macOS et Windows.

Les actions composites vous permettent de combiner plusieurs étapes de workflow dans une même action. Par exemple, vous pouvez utiliser cette fonctionnalité pour regrouper plusieurs commandes d’exécution dans une action, puis utiliser un workflow pour exécuter les commandes groupées en une seule étape à l’aide de cette action.

L’anatomie d’une action GitHub

Voici un exemple d’action qui effectue une opération « git checkout » sur un dépôt. Cette action, actions/checkout@v1, fait partie d’une étape dans un workflow. Cette étape génère également le code Node.js qui a été extrait. Nous allons aborder les workflows, les travaux et les étapes dans la section suivante.

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

Supposons que vous souhaitiez utiliser une action de conteneur pour exécuter du code conteneurisé. Votre action peut 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"

Remarquez la section inputs. Ici, vous obtenez la valeur d’une variable appelée MY_NAME. Cette variable est définie dans le flux de travail qui exécute cette action.

Dans la section runs, notez que vous devez spécifier docker dans l’attribut uses. Lorsque vous définissez cette valeur, vous devez fournir le chemin d’accès au fichier image Docker. Dans ce cas, Dockerfile. Nous ne abordons pas les spécificités de Docker ici, mais si vous souhaitez plus d’informations, consultez le module Présentation des conteneurs Docker .

La dernière section intitulée Personnalisation explique comment personnaliser votre action dans GitHub Marketplace, si vous décidez de l’y publier.

Pour obtenir la liste complète des métadonnées d’action, consultez Metadata syntax for 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 afin d’automatiser les tâches du cycle de vie du développement logiciel, notamment les actions GitHub. Avec un workflow, vous pouvez générer, tester, empaqueter, publier et déployer n’importe quel projet sur GitHub.

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

Dans l’exercice à venir, votre fichier de flux de travail main.yml ressemble à 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"

Notez que l’attribut on: , sa valeur est un déclencheur à spécifier lors de l’exécution de ce flux de travail. Ici, l’exécution est déclenchée lorsqu’un événement de push se produit vers votre dépôt. Vous pouvez spécifier des événements uniques comme on: push, un tableau d’événements comme on: [push, pull_request], ou un mappage de configuration d’événement qui planifie un workflow ou restreint l’exécution d’un workflow à certains fichiers, étiquettes ou modifications de branche. Voici à quoi la carte pourrait ressembler :

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 se déclenche pour tous les types d’activité, sauf si vous en spécifiez un ou plusieurs. Pour obtenir la liste complète des événements et leurs types d’activité, consultez Événements qui déclenchent des workflows dans la documentation de GitHub.

Un workflow doit comprendre au moins un travail. Une tâche est une section du flux de travail associée à un exécuteur. Un exécuteur peut être hébergé dans GitHub ou être auto-hébergé, et le travail peut s’exécuter sur un ordinateur ou dans un conteneur. Pour spécifier l’exécuteur, utilisez l’attribut runs-on:. Ici, vous indiquez au workflow qu’il doit exécuter ce travail sur ubuntu-latest.

Chaque travail a des étapes à suivre. Dans notre exemple, l’étape utilise l’action actions/checkout@v1 pour extraire le dépôt. Ce qui est intéressant, c’est la valeur uses: ./action-a, qui est le chemin de l’action de conteneur que vous générez dans un fichier action.yml.

La dernière partie de ce fichier de workflow définit la valeur de variable MY_NAME pour ce workflow. N’oubliez pas que l’action de conteneur a pris une entrée appelée MY_NAME.

Pour plus d’informations sur la syntaxe des workflows, consultez Workflow syntax for GitHub Actions.

Référencement d’actions dans les flux de travail

Lors de la création de flux de travail dans GitHub Actions, vous pouvez référencer des actions à partir de différentes sources. Ces actions peuvent être utilisées pour automatiser les tâches dans vos flux de travail. Voici les sources principales où les flux de travail peuvent référencer des actions :

1. Image conteneur Docker publiée sur Docker Hub
   Les flux de travail peuvent référencer des actions publiées en tant qu’images conteneur Docker sur Docker Hub. Ces actions sont conteneurisées et incluent toutes les dépendances requises pour exécuter l’action. Pour utiliser cette action, vous spécifiez l’image Docker dans l’attribut uses de votre étape de flux de travail. Par exemple:

   steps:
     - name: Run a Docker action
       uses: docker://<docker-image-name>:<tag>
   

2. Tout dépôt public
   Les actions hébergées dans des référentiels publics peuvent être directement référencées dans vos flux de travail. Ces actions sont accessibles à tout le monde et peuvent être utilisées en spécifiant le nom et la version du référentiel (git ref, SHA ou balise) dans l’attribut uses . Par exemple:

   steps:
     - name: Use a public action
       uses: actions/checkout@v3
   

[!IMPORTANT]

Pour une meilleure sécurité, utilisez une sha de validation complète lors du référencement d’actions, pas seulement une balise comme @v3.
Ainsi, votre workflow utilise toujours le même code, même si l’action est mise à jour ou modifiée ultérieurement.
Exemple : uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

3. Le même dépôt que votre fichier de flux de travail
   Vous pouvez référencer des actions stockées dans le même référentiel que votre fichier de flux de travail. Cette fonctionnalité est utile pour les actions personnalisées spécifiques à votre projet. Pour référencer ces actions, utilisez un chemin relatif vers le répertoire de l’action. Par exemple:

   steps:
     - name: Use a local action
       uses: ./path-to-action
   

Pour plus d’informations, consultez les instructions de renforcement de la sécurité pour GitHub Actions.

4. Place de marché d’entreprise
   Si votre organisation utilise GitHub Enterprise, vous pouvez référencer des actions à partir de la Place de marché privée de votre entreprise. Ces actions sont organisées et gérées par votre organisation, ce qui garantit la conformité aux normes internes. Par exemple:

   steps:
     - name: Use an enterprise marketplace action
       uses: enterprise-org/action-name@v1
   

Pour plus d’informations, consultez Référencer des actions dans les flux de travail.

Exécuteurs hébergés sur GitHub et auto-hébergés

Nous avons brièvement mentionné les exécuteurs comme étant associés à une tâche. Un exécuteur est simplement un serveur sur lequel l’application d’exécuteur GitHub Actions est installée. Dans l’exemple de flux de travail précédent, il y avait un runs-on: ubuntu-latest attribut dans le bloc de travaux, qui a indiqué au flux de travail que le travail va s’exécuter à l’aide de l’exécuteur hébergé par GitHub qui s’exécute dans l’environnement ubuntu-latest .

En ce qui concerne les runners, deux options sont disponibles : runners hébergés par GitHub ou runners auto-hébergés. Si vous utilisez un exécuteur hébergé par GitHub, chaque travail s’exécute dans une nouvelle instance d’environnement virtuel. Le type d’exécuteur hébergé par GitHub que vous définissez, runs-on: {operating system-version} spécifie ensuite cet environnement. Avec les exécuteurs auto-hébergés, vous devez appliquer l’étiquette Auto-hébergé, son système d’exploitation et l’architecture système. Par exemple, un exécuteur auto-hébergé avec un système d’exploitation Linux et une architecture ARM32 ressemblent à la spécification suivante : runs-on: [self-hosted, linux, ARM32]

Chaque type d’exécuteur présente ses avantages, mais les exécuteurs hébergés sur GitHub offrent un moyen plus rapide et plus simple d’exécuter vos workflows, bien qu’avec des options limitées. Les exécuteurs auto-hébergés sont un moyen très configurable d’exécuter des workflows dans votre propre environnement local personnalisé. Vous pouvez exécuter des exécuteurs auto-hébergés localement ou dans le cloud. Vous pouvez également utiliser des exécuteurs auto-hébergés pour créer une configuration matérielle personnalisée avec plus de puissance de traitement ou de mémoire. Ce type de configuration permet d’exécuter des travaux plus volumineux, d’installer des logiciels disponibles sur votre réseau local et de choisir un système d’exploitation non proposé par les exécuteurs hébergés par GitHub.

GitHub Actions peut avoir des limites d’utilisation

GitHub Actions a certaines limites d’utilisation, selon votre plan GitHub et si votre exécuteur est hébergé par GitHub ou auto-hébergé. Pour plus d’informations sur les limites d’utilisation, consultez Usage limits, billing, and administration dans la documentation GitHub.

GitHub a hébergé des exécuteurs de plus grande taille

GitHub offre des exécuteurs plus volumineux pour les flux de travail qui nécessitent plus de ressources. Ces exécuteurs sont hébergés par GitHub et fournissent des capacités accrues en termes de CPU, de mémoire et d'espace disque par rapport aux exécuteurs standard. Ils sont conçus pour gérer efficacement les flux de travail gourmands en ressources, ce qui garantit des performances optimales pour les tâches exigeantes.

Tailles et étiquettes de coureur

Les plus grands exécuteurs sont disponibles dans plusieurs configurations, fournissant des processeurs virtuels améliorés, la RAM et le stockage SSD pour répondre à diverses exigences de flux de travail. Ces configurations sont idéales pour les scénarios tels que :

• Compilation de bases de code volumineuses avec des fichiers sources étendus.
• Exécution de suites de tests complètes, notamment des tests d’intégration et de bout en bout.
• Traitement de jeux de données volumineux pour l’analyse des données ou les tâches de Machine Learning.
• Création d’applications avec des dépendances complexes ou des sorties binaires volumineuses.
• Effectuer des simulations hautes performances ou une modélisation de calcul.
• Exécution d’un encodage vidéo, d’un rendu ou d’autres flux de travail de traitement multimédia.

Pour utiliser un exécuteur plus grand, spécifiez l’étiquette d’exécuteur souhaitée dans l’attribut runs-on de votre fichier de flux de travail. Par exemple, pour utiliser un exécuteur avec 16 processeurs virtuels et 64 Go de RAM, vous devez définir runs-on: ubuntu-latest-16core.

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

Ces exécuteurs de plus grande taille maintiennent la compatibilité avec les workflows existants en incluant les mêmes outils préinstallés que les exécuteurs ubuntu-latest standard.

Pour plus d’informations sur les tailles d’exécuteur pour les exécuteurs plus volumineux, consultez la documentation GitHub

Gestion des exécuteurs de plus grande taille

GitHub fournit des outils pour gérer efficacement des exécuteurs plus importants, garantissant une utilisation optimale des ressources et la gestion des coûts. Voici quelques aspects clés de la gestion de plus grands coureurs :

Surveillance de l’utilisation

Vous pouvez surveiller l’utilisation de plus grands exécuteurs via la page d’utilisation de GitHub Actions dans vos paramètres de dépôt ou d’organisation. Cette page fournit des informations sur le nombre de travaux exécutés, le runtime total et les coûts associés.

Gestion de l’accès

Si vous souhaitez contrôler l’accès aux exécuteurs de plus grande taille, vous pouvez configurer des stratégies au niveau du référentiel ou de l’organisation. Cette configuration garantit que seuls les flux de travail ou équipes autorisés peuvent utiliser ces exécuteurs à haute ressource.

Gestion des coûts

Les exécuteurs de plus grande taille entraînent des coûts supplémentaires en fonction de leur utilisation. Pour gérer les coûts, tenez compte des suggestions suivantes :

• Utilisez des exécuteurs de plus grande taille uniquement pour les workflows nécessitant des ressources élevées.
• Réduisez le runtime en optimisant les flux de travail.
• Surveillez régulièrement les détails de facturation pour suivre les dépenses.

Mise à l’échelle des flux de travail

Si vos flux de travail nécessitent une utilisation fréquente de plus grands exécuteurs, envisagez de mettre en œuvre des stratégies de mise à l'échelle telles que :

• Utilisation d’exécuteurs auto-hébergés pour les charges de travail prévisibles.
• Fractionnement des flux de travail en tâches plus petites pour répartir la charge de travail entre les exécutants standard.