Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-07-09. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Comprendre GitHub Actions

Apprenez les bases de GitHub Actions, y compris les concepts de base et la terminologie essentielle.

Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.

Vue d'ensemble

GitHub Actions est une plateforme d’intégration continue et livraison continue (CI/CD) qui vous permet d’automatiser votre pipeline de génération, de test et de déploiement. Vous pouvez créer des workflows qui créent et testent chaque demande de tirage (pull request) adressée à votre dépôt, ou déployer des demandes de tirage fusionnées en production.

GitHub Actions dépasse DevOps simplement et vous permet d'exécuter des workflows lorsque d'autres événements se produisent dans votre dépôt. Par exemple, vous pouvez exécuter un workflow pour ajouter automatiquement les étiquettes appropriées chaque fois que quelqu'un crée un problème dans votre dépôt.

Vous devez héberger vos propres machines virtuelles Linux, Windows ou macOS pour exécuter des workflows pour votre instance GitHub Enterprise Server. Les exécuteurs auto-hébergés peuvent être physiques ou virtuels, et se trouver dans un conteneur, localement ou dans un cloud.

Pour plus d'informations sur l'introduction de GitHub Actions dans votre entreprise, consultez « Introduction de GitHub Actions votre entreprise ».

Composants de GitHub Actions

Vous pouvez configurer un workflow GitHub Actions à déclencher quand un événement se produit dans votre dépôt, par exemple l'ouverture d'une demande de tirage (pull request) ou la création d'un problème. Votre workflow contient un ou plusieurs travaux qui peuvent s'exécuter dans un ordre séquentiel ou en parallèle. Chaque travail s'exécute au sein de son propre exécuteur de machine virtuelle, ou au sein d'un conteneur, et comporte une ou plusieurs étapes qui exécutent un script que vous définissez ou une action, qui est une extension réutilisable qui peut simplifier votre workflow.

Diagramme d'un événement déclenchant Exécuteur 1 pour exécuter Travail 1, lequel déclenche Exécuteur 2 pour exécuter Travail 2. Chacun des travaux est divisé en plusieurs étapes.

Workflows

Un workflow est un processus automatisé configurable qui exécutera un ou plusieurs travaux. Les workflows sont définis par un fichier YAML archivé dans votre dépôt et s’exécutent lorsqu’ils sont déclenchés par un événement dans votre dépôt, ou ils peuvent être déclenchés manuellement ou selon une planification définie.

Les workflows sont définis dans le répertoire .github/workflows d’un référentiel, et un référentiel peut avoir plusieurs workflows, chacun pouvant effectuer un ensemble différent de tâches. Par exemple, vous pouvez avoir un workflow pour générer et tester des demandes de tirage, un autre workflow pour déployer votre application chaque fois qu’une version est créée, et encore un autre workflow qui ajoute une étiquette chaque fois que quelqu’un ouvre un nouveau problème.

Vous pouvez référencer un workflow dans un autre workflow. Pour plus d'informations, consultez « Réutilisation des workflows ».

Pour plus d'informations sur les workflows, consultez « Utilisation de flux de travail ».

Événements

Un événement est une activité spécifique dans un dépôt qui déclenche l'exécution d'un workflow. Par exemple, une activité peut provenir de GitHub quand quelqu’un crée une demande de tirage (pull request), ouvre un problème ou pousse (push) un commit vers un référentiel. Vous pouvez également déclencher une exécution de workflow selon une planification, en publiant dans une API REST ou manuellement.

Pour obtenir la liste complète des événements qui peuvent être utilisés pour déclencher des workflows, consultez Événements déclencheurs de workflows.

travaux

Un travail est un ensemble d'étapes dans un workflow qui s'exécute sur le même exécuteur. Chaque étape est un script d'interpréteur de commandes qui sera exécuté ou une action qui sera exécutée. Les étapes sont exécutées dans l'ordre et dépendent les unes des autres. Comme chaque étape est exécutée sur le même exécuteur, vous pouvez partager des données d'une étape à une autre. Par exemple, vous pouvez avoir une étape qui génère votre application suivie d'une étape qui teste l'application générée.

Vous pouvez configurer les dépendances d'un travail avec d'autres travaux. Par défaut, les travaux n'ont aucune dépendance et s'exécutent en parallèle entre eux. Lorsqu'un travail prend une dépendance sur un autre travail, il attend que le travail dépendant se termine avant de pouvoir s'exécuter. Par exemple, vous pouvez avoir plusieurs travaux de génération pour différentes architectures qui n'ont pas de dépendances, et un travail d'empaquetage dépendant de ces travaux. Les travaux de génération s'exécutent en parallèle et le travail d'empaquetage s'exécutera quand ils auront fini de s'exécuter.

Pour plus d'informations sur les travaux, consultez « Utilisation des travaux ».

Actions

Une action est une application personnalisée pour la plateforme GitHub Actions qui effectue une tâche complexe mais fréquemment répétée. Utilisez une action pour réduire la quantité de code répétitif que vous écrivez dans vos fichiers de workflow. Une action peut tirer (pull) votre dépôt git à partir de GitHub, configurer la chaîne d'outils appropriée pour votre environnement de build ou configurer l'authentification auprès de votre fournisseur de cloud.

Vous pouvez écrire vos propres actions ou trouver des actions à utiliser dans vos workflows dans le GitHub Marketplace.

Pour partager des actions au sein de votre entreprise sans les publier publiquement, vous pouvez les stocker dans un référentiel interne, puis configurer celui-ci pour autoriser l’accès aux workflows GitHub Actions dans d’autres référentiels appartenant à la même organisation ou à toute autre organisation de l’entreprise. Pour plus d’informations, consultez « Partage d’actions et de workflows au sein de votre entreprise ».

Pour plus d'informations, consultez « Création d’actions ».

Exécuteurs

Un exécuteur est un serveur qui exécute vos workflows quand ils sont déclenchés. Chaque exécuteur peut exécuter un seul travail à la fois. Vous devez héberger vos propres exécuteurs pour GitHub Enterprise Server. Pour plus d'informations, consultez « Hébergement de vos propres exécuteurs ».

Créer un exemple de workflow

GitHub Actions utilise la syntaxe YAML pour définir le workflow. Chaque workflow est stocké en tant que fichier YAML distinct dans votre référentiel de code, dans un répertoire appelé .github/workflows.

Vous pouvez créer un exemple de workflow dans votre dépôt qui déclenche automatiquement une série de commandes chaque fois que du code est poussé (push). Dans ce workflow, GitHub Actions extrait le code envoyé, installe le framework de test bats et exécute une commande de base pour générer la version de bats : bats -v.

  1. Dans votre dépôt, créez le répertoire .github/workflows/ pour stocker vos fichiers de workflow.

  2. Dans le répertoire .github/workflows/, créez un nouveau fichier appelé learn-github-actions.yml et ajoutez le code suivant.

    YAML
    name: learn-github-actions
    run-name: ${{ github.actor }} is learning GitHub Actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - uses: actions/setup-node@v4
            with:
              node-version: '20'
          - run: npm install -g bats
          - run: bats -v
    
  3. Validez ces modifications et poussez-les vers votre dépôt GitHub.

Votre nouveau fichier de workflow GitHub Actions est maintenant installé dans votre dépôt et s’exécute automatiquement chaque fois que quelqu’un pousse (push) une modification vers le dépôt. Pour afficher les détails sur l’historique d’exécution d’un workflow, consultez « Affichage de l’activité pour une exécution de workflow ».

Présentation du fichier de workflow

Pour vous aider à comprendre comment la syntaxe YAML est utilisée pour créer un fichier de workflow, cette section explique chaque ligne de l’exemple d’introduction :

YAML
name: learn-github-actions

Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.

run-name: ${{ github.actor }} is learning GitHub Actions

Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the github context to display the username of the actor that triggered the workflow run. For more information, see "Workflow syntax for GitHub Actions."

on: [push]

Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for GitHub Actions."

jobs:

Groups together all the jobs that run in the learn-github-actions workflow.

  check-bats-version:

Defines a job named check-bats-version. The child keys will define properties of the job.

    runs-on: ubuntu-latest

Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Workflow syntax for GitHub Actions"

    steps:

Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.

      - uses: actions/checkout@v4

The uses keyword specifies that this step will run v4 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

This step uses the actions/setup-node@v4 action to install the specified version of the Node.js. (This example uses version 20.) This puts both the node and npm commands in your PATH.

      - run: npm install -g bats

The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.

      - run: bats -v

Finally, you'll run the bats command with a parameter that outputs the software version.

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions

# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 20.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

Visualisation du fichier de workflow

Dans ce diagramme, vous pouvez voir le fichier de workflow que vous venez de créer et comment les composants GitHub Actions sont organisés dans une hiérarchie. Chaque étape exécute une action ou un script d’interpréteur de commandes unique. Les étapes 1 et 2 exécutent des actions, tandis que les étapes 3 et 4 exécutent des scripts d’interpréteur de commandes. Pour trouver d’autres actions prédéfinies pour vos workflows, consultez « Recherche et personnalisation d’actions ».

Diagramme montrant le déclencheur, l’exécuteur et le travail d’un workflow. Le travail est divisé en 4 étapes.

Affichage de l’activité pour une exécution de workflow

Lorsque votre workflow est déclenché, une exécution de workflow est créée et exécute le workflow. Une fois l’exécution de votre workflow démarrée, vous pouvez voir un graphe de visualisation de la progression de l’exécution, ainsi que l’activité de chaque étape sur GitHub.

  1. Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.

  2. Sous le nom de votre dépôt, cliquez sur Actions.

    Capture d’écran des onglets du référentiel « github/docs ». L’onglet « Actions » est mis en surbrillance avec un encadré orange.

  3. Dans la barre latérale gauche, cliquez sur le workflow que vous souhaitez afficher.

    Capture d'écran de la barre latérale gauche de l'onglet « Actions », avec un workflow « CodeQL » indiqué en orange foncé.

  4. Dans la liste des exécutions de workflow, cliquez sur le nom de l’exécution pour voir le résumé de l’exécution du workflow.

  5. Dans la barre latérale à gauche ou dans le graphe de visualisation, cliquez sur le travail que vous souhaitez voir.

  6. Pour voir les résultats d’une étape, cliquez sur l’étape.

Étapes suivantes

GitHub Actions peut vous aider à automatiser presque tous les aspects de vos processus de développement d’applications. Vous êtes prêt à commencer ? Voici quelques ressources utiles pour effectuer vos étapes suivantes avec GitHub Actions :

  • Pour obtenir un moyen rapide de créer un flux de travail GitHub Actions, consultez « Utilisation de workflows de démarrage ».
  • Pour obtenir des workflows d’intégration continue (CI) permettant de générer et tester votre code, consultez « Automatisation des builds et des tests ».
  • Pour générer et publier des packages, consultez « Publication de packages ».
  • Pour le déploiement de projets, consultez « Déploiement ».
  • Pour automatiser les tâches et les processus sur GitHub, consultez « Gestion des problèmes et demandes de tirage ».
  • Pour obtenir des exemples illustrant les fonctionnalités plus complexes de GitHub Actions, dont beaucoup des cas d’usage ci-dessus, consultez « Exemples ». Des exemples détaillés expliquent comment tester votre code sur un exécuteur et accéder à la CLI GitHub. Ils montrent également comment utiliser des fonctions avancées telles que la concurrence et les matrices de test.

Pour aller plus loin