Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Utilisation d’exécuteurs auto-hébergés dans un workflow

Pour utiliser des exécuteurs auto-hébergés dans un workflow, vous pouvez utiliser des étiquettes ou des groupes pour spécifier l’exécuteur d’un travail.

Vous pouvez cibler des exécuteurs auto-hébergés à utiliser dans un workflow en fonction des étiquettes attribuées aux exécuteurs ou de leur appartenance à un groupe, ou encore d’une combinaison de toutes celles-ci.

À propos des étiquettes d’exécuteurs auto-hébergés

Les étiquettes vous permettent d’envoyer des travaux de workflow à des types spécifiques d’exécuteurs auto-hébergés, en fonction de leurs caractéristiques partagées. Par exemple, si votre travail nécessite un composant matériel ou un package logiciel particulier, vous pouvez affecter une étiquette personnalisée à un exécuteur, puis configurer votre travail pour qu’il s’exécute uniquement sur les exécuteurs dotés de cette étiquette.

Si vous souhaitez spécifier un exécuteur autohébergé pour votre travail, configurez runs-on dans votre fichier de workflow avec des étiquettes d’exécuteur autohébergé.

Tous les exécuteurs autohébergés ont l’étiquette self-hosted. L’utilisation de cette seule étiquette permet de sélectionner n’importe quel exécuteur autohébergé. Pour sélectionner des exécuteurs qui répondent à certains critères, par exemple le système d’exploitation ou l’architecture, nous vous recommandons de fournir un tableau d’étiquettes qui commence par self-hosted (doit être listé en premier), et qui comprend des étiquettes supplémentaires selon les besoins. Quand vous spécifiez un tableau d’étiquettes, les travaux sont mis en file d’attente sur des exécuteurs qui comportent toutes les étiquettes que vous indiquez.

Bien que l’étiquette self-hosted ne soit pas obligatoire, nous vous recommandons vivement de la spécifier quand vous utilisez des exécuteurs autohébergés pour avoir la certitude que votre travail ne spécifie pas par inadvertance des exécuteurs, actuels ou futurs, hébergés sur GitHub.

Pour obtenir des informations sur la création d’étiquettes personnalisées et par défaut, consultez « Utilisation d’étiquettes avec des exécuteurs auto-hébergés ».

À propos des groupes d’exécuteurs auto-hébergés

Pour les exécuteurs auto-hébergés définis au niveau de l’organisation, vous pouvez regrouper vos exécuteurs avec des caractéristiques partagées dans un seul groupe d’exécuteurs, puis configurer votre travail pour cibler le groupe d’exécuteurs.

Pour spécifier un groupe d’exécuteurs auto-hébergés pour votre travail, configurez runs-on.group dans votre fichier de workflow.

Pour plus d’informations sur la création et la gestion des groupes d’exécuteurs, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».

Remarque : Toutes les organisations disposent d’un seul groupe d’exécuteurs par défaut. Seuls les comptes d’une grande entreprise et les organisations appartenant à ces comptes peuvent créer et gérer des groupes d’exécuteurs supplémentaires.

Utilisation d’étiquettes par défaut pour router les travaux

Un exécuteur auto-hébergé reçoit automatiquement certaines étiquettes lorsqu’il est ajouté à GitHub Actions. Elles indiquent son système d’exploitation et sa plateforme matérielle :

  • self-hosted : étiquette par défaut appliquée à tous les exécuteurs auto-hébergés.
  • linux, windows ou macOS : selon le système d’exploitation.
  • x64, ARM ou ARM64 : selon l’architecture matérielle.

Vous pouvez utiliser le code YAML de votre workflow pour envoyer des travaux à une combinaison de ces étiquettes. Dans cet exemple, un exécuteur auto-hébergé qui correspond aux trois étiquettes est autorisé à exécuter le travail :

runs-on: [self-hosted, linux, ARM64]
  • self-hosted – Exécuter ce travail sur un exécuteur auto-hébergé.
  • linux – Utiliser uniquement un exécuteur Linux.
  • ARM64 – Utiliser uniquement un exécuteur basé sur du matériel ARM64.

Les étiquettes par défaut sont fixes et ne peuvent pas être modifiées ni supprimées. Envisagez d’utiliser des étiquettes personnalisées si vous avez besoin de plus de contrôle sur le routage des travaux.

Utilisation d’étiquettes personnalisées pour router les travaux

Vous pouvez créer des étiquettes personnalisées et les affecter à vos exécuteurs auto-hébergés à tout moment. Les étiquettes personnalisées vous permettent d’envoyer des travaux à des types particuliers d’exécuteurs auto-hébergés, selon la manière dont ils sont étiquetés.

Par exemple, si vous avez un travail qui requiert un type spécifique de matériel graphique, vous pouvez créer une étiquette personnalisée appelée gpu et l’affecter aux exécuteurs sur lesquels le matériel est installé. Un exécuteur auto-hébergé qui correspond à toutes les étiquettes attribuées sera alors autorisé à exécuter le travail.

Cet exemple montre un travail qui combine des étiquettes par défaut et personnalisées :

runs-on: [self-hosted, linux, x64, gpu]
  • self-hosted – Exécuter ce travail sur un exécuteur auto-hébergé.
  • linux – Utiliser uniquement un exécuteur Linux.
  • x64 – Utiliser uniquement un exécuteur basé sur du matériel x64.
  • gpu – Cette étiquette personnalisée a été affectée manuellement aux exécuteurs auto-hébergés sur lesquels le matériel GPU est installé.

Ces étiquettes fonctionnent par accumulation, si bien qu’un exécuteur auto-hébergé doit avoir les quatre étiquettes pour pouvoir traiter le travail.

Utilisation de groupes pour router des travaux

Dans cet exemple, des exécuteurs Ubuntu ont été ajoutés à un groupe appelé ubuntu-runners. La clé runs-on envoie le travail à n’importe quel exécuteur disponible dans le groupe ubuntu-runners :

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Utilisation d’étiquettes et de groupes pour router des travaux

Quand vous combinez des groupes et des étiquettes, l’exécuteur doit satisfaire aux deux exigences pour pouvoir exécuter le travail.

Dans cet exemple, un groupe d’exécuteurs appelé ubuntu-runners est rempli avec des exécuteurs Ubuntu, qui ont également reçu l’étiquette ubuntu-20.04-16core. La clé runs-on combine group et labels afin que le travail soit routé vers n’importe quel exécuteur disponible au sein du groupe qui a également une étiquette correspondante :

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Priorité de routage pour les exécuteurs auto-hébergés

Lors du routage d’un travail vers un exécuteur auto-hébergé, GitHub recherche un exécuteur correspondant aux étiquettes runs-on et/ou aux groupes du travail :

  • Si GitHub trouve un exécuteur en ligne et inactif qui correspond aux étiquettes runs-on et/ou aux groupes du travail, le travail est alors affecté et envoyé à l’exécuteur.
    • Si l’exécuteur ne récupère pas le travail affecté dans un délai de 60 secondes, le travail est remis en file d’attente afin qu’un nouvel exécuteur puisse l’accepter.
  • Si GitHub ne trouve pas d’exécuteur en ligne et inactif correspondant aux étiquettes runs-on et/ou aux groupes du travail, le travail reste en file d’attente jusqu’à ce qu’un exécuteur soit en ligne.
  • Si le travail reste en file d’attente plus de 24 heures, il échoue.