Note
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
Utilisez jobs.<job_id>.runs-on
pour définir le type de machine sur laquelle le travail doit être exécuté.
- La machine de destination peut être un exécuteur auto-hébergé.
- Vous pouvez cibler des exécuteurs en fonction des étiquettes qui leur sont affectées et/ou de leur appartenance au groupe.
-
Vous pouvez fournir
runs-on
sous la forme suivante :- Une seule chaîne
- Une seule variable contenant une chaîne
- Un tableau de chaînes, des variables contenant des chaînes ou une combinaison des deux
- Une paire
key: value
utilisant les clésgroup
oulabels
-
Si vous spécifiez un tableau de chaînes ou de variables, votre workflow s’exécute sur n’importe quel exécuteur correspondant à toutes les valeurs
runs-on
spécifiées. Par exemple, ici, le travail s’exécute uniquement sur un exécuteur auto-hébergé qui a les étiquetteslinux
,x64
etgpu
:runs-on: [self-hosted, linux, x64, gpu]
Pour plus d’informations, consultez « Choix d’exécuteurs auto-hébergés ».
-
Vous pouvez mélanger des chaînes et des variables dans un tableau. Par exemple :
on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world!
-
Si vous souhaitez exécuter votre workflow sur plusieurs machines, utilisez
jobs.<job_id>.strategy
.
Note
Les guillemets ne sont pas obligatoires autour de chaînes simples comme self-hosted
, mais ils sont requis pour des expressions comme "${{ inputs.chosen-os }}"
.
Choix des exécuteurs hébergés par GitHub
Note
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.
Choix des exécuteurs auto-hébergés
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é.
Les exécuteurs auto-hébergés sont susceptibles d’avoir l’étiquette self-hosted
. Lors de la configuration d’un exécuteur auto-hébergé, nous inclurons l’étiquette self-hosted
par défaut. Vous pouvez passer l’indicateur --no-default-labels
pour empêcher l’application de l’étiquette d’auto-hébergement. Les étiquettes peuvent être utilisées pour créer des options de ciblage pour les exécuteurs, telles que le système d’exploitation ou l’architecture. Nous recommandons de fournir un tableau d’étiquettes qui commence par self-hosted
(ceci doit être listé en premier) et inclut ensuite des étiquettes supplémentaires si nécessaire. 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.
Notez qu’Actions Runner Controller ne prend pas en charge plusieurs étiquettes et ne prend pas en charge l’étiquette self-hosted
.
Exemple : Utilisation d’étiquettes pour la sélection des exécuteurs
runs-on: [self-hosted, linux]
Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés » et « Utilisation d’exécuteurs auto-hébergés dans un workflow ».
Choix des exécuteurs dans un groupe
Vous pouvez utiliser runs-on
pour cibler des groupes d’exécuteurs, afin que le travail s’exécute sur n’importe quel exécuteur membre de ce groupe. Pour un contrôle plus précis, vous pouvez également combiner des groupes d’exécuteurs avec des étiquettes.
Exemple : utilisation de groupes pour contrôler où les travaux sont exécutés
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@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
Exemple : combinaison de groupes et d’étiquettes
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@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
Exemple : utilisation de préfixes pour différencier les groupes d’exécuteurs
Par exemple, si vous avez un groupe d’exécuteurs nommé my-group
dans l’organisation et un autre nommé my-group
dans l’entreprise, vous pouvez mettre à jour votre fichier de workflow pour utiliser org/my-group
ou ent/my-group
afin de les différencier.
Utilisation de org/
:
runs-on:
group: org/my-group
labels: [ self-hosted, label-1 ]
Utilisation de ent/
:
runs-on:
group: ent/my-group
labels: [ self-hosted, label-1 ]