Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

À propos des exécuteurs hébergés par GitHub

GitHub propose des machines virtuelles hébergées pour exécuter les workflows. La machine virtuelle contient un environnement d’outils, de packages et de paramètres utilisables par GitHub Actions.

Vue d’ensemble des exécuteurs hébergés par GitHub

Les exécuteurs sont les machines qui exécutent les travaux dans un workflow GitHub Actions. Par exemple, un exécuteur peut cloner votre dépôt localement, installer un logiciel de test, puis exécuter des commandes qui évaluent votre code.

GitHub fournit des exécuteurs qui vous permettent d’exécuter vos travaux. Toutefois, vous pouvez héberger vos propres exécuteurs. Chaque exécuteur hébergé par GitHub est une nouvelle machine virtuelle hébergée par GitHub sur laquelle l’application d’exécuteur et d’autres outils sont préinstallés. Elle est disponible avec les systèmes d’exploitation Ubuntu Linux, Windows ou macOS. Lorsque vous utilisez un exécuteur hébergé par GitHub, la maintenance et les mises à niveau de la machine sont effectuées automatiquement.

Utilisation d’un exécuteur hébergé par GitHub

Pour vous servir d’un exécuteur hébergé par GitHub, créez un travail et utilisez runs-on afin de spécifier le type d’exécuteur qui va traiter le travail, par exemple ubuntu-latest, windows-latest ou macos-latest. Pour obtenir la liste complète des types d’exécuteur, consultez « Exécuteurs et ressources matérielles pris en charge ».

Quand le travail commence, GitHub provisionne automatiquement une nouvelle machine virtuelle pour ce travail. Toutes les étapes du travail s’exécutent sur la machine virtuelle. Ainsi, elles peuvent partager des informations à l’aide du système de fichiers de l’exécuteur. Vous pouvez exécuter des workflows directement sur la machine virtuelle ou dans un conteneur Docker. À la fin du travail, la machine virtuelle est automatiquement désactivée.

Le diagramme suivant illustre l’exécution de deux travaux d’un workflow sur deux exécuteurs différents hébergés par GitHub.

Deux exécuteurs traitant des travaux distincts

L’exemple de workflow suivant comporte deux travaux, nommés Run-npm-on-Ubuntu et Run-PSScriptAnalyzer-on-Windows. Quand ce workflow se déclenche, GitHub provisionne une nouvelle machine virtuelle pour chaque travail.

  • Le travail nommé Run-npm-on-Ubuntu s’exécute sur une machine virtuelle Linux, car le runs-on: du travail spécifie ubuntu-latest.
  • Le travail nommé Run-PSScriptAnalyzer-on-Windows s’exécute sur une machine virtuelle Windows, car le runs-on: du travail spécifie windows-latest.
YAML
name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

Pendant l’exécution du travail, vous pouvez voir les journaux et la sortie dans l’IU de GitHub :

Sortie du travail dans l’IU d’Actions

L’exécuteur GitHub Actions est une application open source. Vous pouvez signaler et contribuer à résoudre des problèmes dans le référentiel de l’exécuteur.

Exécuteurs et ressources matérielles pris en charge

Remarque : GitHub propose également des larger runner, qui sont disponibles dans des configurations plus grandes. Pour plus d’informations, consultez « Spécification des ordinateurs pour les larger runner ».

Spécification matérielle pour les machines virtuelles Windows et Linux :

  • Processeur 2 cœurs (x86_64)
  • 7 Go de RAM
  • 14 Go d’espace sur disque SSD

Spécification matérielle pour les machines virtuelles macOS :

  • Processeur 3 cœurs (x86_64)
  • 14 Go de RAM
  • 14 Go d’espace sur disque SSD
Image de l’exécuteur Étiquette de workflow YAML Remarques
Windows Server 2022 windows-latest ou windows-2022 L’étiquette windows-latest utilise actuellement l’image de l’exécuteur Windows Server 2022.
Windows Server 2019 windows-2019
Ubuntu 22.04 ubuntu-latest ou ubuntu-22.04 L’étiquette ubuntu-latest utilise actuellement l’image de l’exécuteur Ubuntu 22.04.
Ubuntu 20.04 ubuntu-20.04
Ubuntu 18.04 [déconseillé] ubuntu-18.04 Migrer vers ubuntu-20.04 ou ubuntu-22.04. Pour plus d’informations, consultez ce billet de blog GitHub.
macOS Monterey 12 macos-latest ou macos-12 L’étiquette macos-latest utilise actuellement l’image de l’exécuteur macOS 12.
macOS Big Sur 11 macos-11
macOS Catalina 10.15 [déprécié] macos-10.15 Migrer vers macOS-11 ou macOS-12. Pour plus d’informations, consultez ce billet de blog GitHub.

Remarque : Les images d’exécuteur -latest sont les dernières images stables que fournit GitHub et peuvent ne pas correspondre à la version la plus récente du système d’exploitation disponible auprès du fournisseur du système d’exploitation.

Avertissement : Les images bêta et dépréciées sont fournies « en l’état », « avec toutes les imperfections » et « selon la disponibilité », et sont exclues du contrat de niveau de service et de la garantie. Les images bêta peuvent ne pas être couvertes par le service client.

Les journaux de workflow répertorient l’exécuteur utilisé pour exécuter un travail. Pour plus d’informations, consultez « Affichage de l’historique des exécutions de workflows ».

Logiciels pris en charge

Les outils logiciels inclus dans les exécuteurs hébergés par GitHub sont mis à jour chaque semaine. Le processus de mise à jour prend plusieurs jours, et la liste des logiciels préinstallés sur la branche main est mise à jour une fois l’ensemble du déploiement terminé.

Logiciels préinstallés

Les journaux de workflow incluent un lien vers les outils préinstallés sur l’exécuteur exact. Pour trouver ces informations dans le journal de workflow, développez la section Set up job. Sous cette section, développez la section Runner Image. Le lien suivant Included Software décrit les outils préinstallés sur l’exécuteur qui a exécuté le workflow. Lien vers les logiciels installés Pour plus d’informations, consultez « Affichage de l’historique des exécutions de workflows ».

Pour obtenir la liste globale des outils inclus pour chaque système d’exploitation d’exécuteur, consultez les liens ci-dessous :

Les exécuteurs hébergés par GitHub incluent les outils intégrés par défaut du système d’exploitation, en plus des packages listés dans les références ci-dessus. Par exemple, les exécuteurs Ubuntu et macOS incluent grep, find et which, entre autres outils par défaut.

Vous pouvez également afficher une nomenclature logicielle (SBOM) pour chaque build des images de l’exécuteur Windows et Ubuntu. Pour plus d’informations, consultez « Examen de la chaîne d’approvisionnement pour les exécuteurs hébergés par GitHub ».

Utilisation des logiciels préinstallés

Nous vous recommandons d’utiliser des actions pour interagir avec les logiciels installés sur les exécuteurs. Cette approche présente plusieurs avantages :

  • En général, les actions fournissent des fonctionnalités plus flexibles, comme la sélection des versions, la possibilité de passer des arguments, et des paramètres
  • Cela garantit que les versions d’outils utilisées dans votre workflow restent les mêmes, quelles que soient les mises à jour logicielles

S’il y a un outil que vous souhaitez demander, ouvrez un problème dans actions/runner-images. Ce dépôt contient également des annonces sur toutes les principales mises à jour logicielles sur les exécuteurs.

Installation de logiciels supplémentaires

Vous pouvez installer des logiciels supplémentaires sur les exécuteurs hébergés par GitHub. Pour plus d’informations, consultez « Personnalisation des exécuteurs hébergés par GitHub ».

Hôtes cloud utilisés par les exécuteurs hébergés par GitHub

GitHub héberge les exécuteurs Linux et Windows sur des machines virtuelles Standard_DS2_v2 dans Microsoft Azure. L’application d’exécuteur GitHub Actions est installée sur ces machines. L’application d’exécuteur hébergé par GitHub est une duplication (fork) de l’agent Azure Pipelines. Les paquets ICMP entrants sont bloqués pour toutes les machines virtuelles Azure. Par conséquent, les commandes ping ou traceroute peuvent ne pas fonctionner. Pour plus d’informations sur les ressources Standard_DS2_v2, consultez « Séries Dv2 et DSv2 » dans la documentation de Microsoft Azure.

GitHub héberge les exécuteurs macOS dans le propre cloud macOS de GitHub.

Continuité du workflow

Si les services GitHub Actions sont temporairement indisponibles, alors une exécution de workflow est ignorée si elle n’a pas été mise en file d’attente dans les 30 minutes suivant son déclenchement. Par exemple, si un workflow est déclenché et que les services GitHub Actions ne sont pas disponibles pendant 31 minutes ou plus, l’exécution du workflow n’est pas traitée.

En outre, si l’exécution du workflow a été correctement mise en file d’attente, mais n’a pas été traitée par un exécuteur hébergé par GitHub dans les 45 minutes, l’exécution du workflow mis en file d’attente est ignorée.

Privilèges d’administration

Les machines virtuelles Linux aussi bien que macOS s’exécutent à l’aide de sudo sans mot de passe. Lorsque vous devez exécuter des commandes ou installer des outils qui nécessitent plus de privilèges que ceux de l’utilisateur actuel, vous pouvez utiliser sudo sans avoir à fournir de mot de passe. Pour plus d’informations, consultez le manuel sudo.

Les machines virtuelles Windows sont configurées pour s’exécuter en tant qu’administrateurs avec le Contrôle de compte d’utilisateur (UAC) désactivé. Pour plus d’informations, consultez « Fonctionnement du contrôle de compte d’utilisateur » dans la documentation Windows.

Adresses IP

Remarque : Si vous utilisez une liste verte d’adresses IP pour votre organisation ou votre compte d’entreprise GitHub, vous ne pouvez pas utiliser des exécuteurs hébergés par GitHub et vous devez plutôt utiliser des exécuteurs auto-hébergés. Pour plus d’informations, consultez « About self-hosted runners ».

Pour obtenir la liste des plages d’adresses IP utilisées par GitHub Actions pour les exécuteurs hébergés par GitHub, vous pouvez utiliser l’API REST GitHub. Pour plus d’informations, consultez la clé actions dans la réponse du point de terminaison « Obtenir les informations de métadonnées GitHub ».

Les exécuteurs Windows et Ubuntu sont hébergés dans Azure et ont par la suite les mêmes plages d’adresses IP que les centres de données Azure. Les exécuteurs macOS sont hébergés dans le dans le propre cloud macOS de GitHub.

En raison du nombre élevé de plages d’adresses IP pour les exécuteurs hébergés par GitHub, nous vous déconseillons d’utiliser ces plages comme listes vertes pour vos ressources internes.

La liste des données d’adresses IP GitHub Actions retournées par l’API est mise à jour une fois par semaine.

Systèmes de fichiers

GitHub exécute des actions et des commandes d’interpréteur de commandes dans des répertoires spécifiques sur la machine virtuelle. Les chemins des fichiers sur les machines virtuelles ne sont pas statiques. Utilisez les variables d’environnement fournies par GitHub pour construire des chemins de fichiers pour les répertoires home, workspace et workflow.

RépertoireVariable d’environnementDescription
homeHOMEContient des données associées aux utilisateurs. Par exemple, ce répertoire peut contenir des informations d’identification provenant d’une tentative de connexion.
workspaceGITHUB_WORKSPACELes actions et les commandes d’interpréteur de commandes s’exécutent dans ce répertoire. Une action peut modifier le contenu de ce répertoire, auquel les actions suivantes peuvent accéder.
workflow/event.jsonGITHUB_EVENT_PATHCharge utile POST de l’événement de webhook qui a déclenché le workflow. GitHub réécrit cette opération chaque fois qu’une action s’exécute pour isoler le contenu du fichier entre les actions.

Pour obtenir la liste des variables d’environnement créées par GitHub pour chaque workflow, consultez « Variables ».

Système de fichiers de conteneur Docker

Les actions qui s’exécutent dans des conteneurs Docker ont des répertoires statiques sous le chemin /github. Toutefois, nous vous recommandons vivement d’utiliser les variables d’environnement par défaut pour construire des chemins de fichiers dans des conteneurs Docker.

GitHub réserve le préfixe du chemin /github et crée trois répertoires pour les actions.

  • /github/home
  • /github/workspace - Remarque : GitHub Actions doit être exécuté par l’utilisateur Docker par défaut (racine). Vérifiez que votre Dockerfile ne définit pas l’instruction USER, sinon vous ne pourrez pas accéder à GITHUB_WORKSPACE.
  • /github/workflow

Pour aller plus loin