Exécution de travaux sur des exécuteurs de plus grande taille

Une fois que votre type d’exécuteur a été défini, vous pouvez mettre à jour vos fichiers YAML de workflow pour envoyer des travaux aux instances de l’exécuteur qui viennent d’être créées afin de les traiter. Vous pouvez utiliser des groupes d’exécuteurs ou des étiquettes pour définir l’emplacement d’exécution de vos travaux.

Seuls les comptes de propriétaire ou d’administrateur peuvent voir les paramètres de l’exécuteur. Les utilisateurs non administratifs peuvent contacter le propriétaire de l’organisation pour savoir quels exécuteurs sont activés. Le propriétaire de votre organisation peut créer de nouveaux exécuteurs et groupes d’exécuteurs, ainsi que configurer des autorisations pour spécifier quels référentiels peuvent accéder à un groupe d’exécuteurs. Pour plus d’informations, consultez « Gestion des exécuteurs de plus grande taille ».

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@v6
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Utilisation d’étiquettes pour contrôler où les travaux sont exécutés

Vous pouvez transmettre implicitement une étiquette à la clé runs-on à l’aide de la syntaxe runs-on: LABEL. Vous pouvez également utiliser la clé labels, comme illustré dans l’exemple ci-dessous.

Dans cet exemple, la clé runs-on envoie la tâche à n’importe quel exécuteur disponible ayant l’étiquette ubuntu-24.04-16core :

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

Toute personne disposant d’un accès en écriture à un référentiel avec Actions activées peut trouver les étiquettes des exécuteurs disponibles dans ce référentiel. Consultez Exécution de travaux sur des exécuteurs de plus grande taille.

Utilisation d’étiquettes et de groupes pour contrôler où les travaux sont exécutés

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-24.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-24.04-16core
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Si vous remarquez que les travaux qui ciblent vos exécuteur plus grand sont retardés ou ne sont pas en cours d’exécution, plusieurs facteurs peuvent en être à l’origine.

• Paramètres de concurrence : vous avez peut-être atteint votre limite maximale de concurrence. Si vous voulez permettre l’exécution en parallèle de plus de travaux, vous pouvez mettre à jour vos paramètres de mise à l’échelle automatique sur un nombre plus élevé. Pour plus d’informations, consultez « Gestion des exécuteurs de plus grande taille ».
• Autorisations de dépôt : vérifiez que les autorisations de dépôt appropriées sont activées pour vos exécuteur plus grand. Par défaut, les exécuteurs d’entreprise ne sont pas disponibles au niveau du dépôt et doivent être activés manuellement par un administrateur d’organisation. Pour plus d’informations, consultez « Gestion des exécuteurs de plus grande taille ».
• Informations de facturation : vous devez avoir une carte de crédit valide dans le fichier pour pouvoir utiliser des exécuteur plus grand. Après avoir ajouté une carte de crédit à votre compte, il peut être nécessaire d’attendre jusqu’à 10 minutes avant de pouvoir activer vos exécuteur plus grand. Pour plus d’informations, consultez « Gestion de vos informations de paiement et de facturation ».
• Limite de dépense : votre limite de dépense GitHub Actions doit être définie sur une valeur supérieure à zéro. Pour plus d’informations, consultez « Configurer des budgets pour contrôler les dépenses liées aux produits facturés à l’usage ».
• Stratégie d’utilisation équitable : GitHub a une stratégie d’utilisation équitable qui commence à limiter les travaux en fonction de plusieurs facteurs, comme le nombre de travaux que vous exécutez ou le nombre de travaux exécutés dans tout GitHub Actions.
• Durée entre la mise en file d’attente et l’attribution de la tâche : la durée entre la mise en file d’attente et l’attribution de la tâche correspond au temps qui s’écoule entre la demande d’une tâche et l’attribution par GitHub d’une machine virtuelle pour l’exécution de la tâche. Les exécuteurs standard hébergés par GitHub qui utilisent les étiquettes de flux de travail YAML prescrites (telles que ubuntu-latest) sont toujours dans un état « chaud ». Avec des exécuteurs de plus grande taille, une machine virtuelle préchauffée peut ne pas être prête à traiter une tâche dès la première demande, car les pools pour ces machines sont plus petits. Par conséquent, GitHub peut avoir besoin de créer une nouvelle machine virtuelle, ce qui augmente la durée entre la mise en file d’attente et l’attribution. Une fois qu’un exécuteur est utilisé, les machines virtuelles sont prêtes pour les exécutions de flux de travail suivantes dans les 5 minutes. Si elles ne sont pas réutilisées dans ce délai, un sous-ensemble de ces machines reste préchauffé, ce qui réduit le temps d’attente pour l’assignation des futures exécutions de flux de travail au cours des 24 heures suivantes. Plus le volume de tâches que vous exécutez est élevé, plus de machines virtuelles restent dans le pool préchauffé.