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@v4
      - 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

Dans cet exemple, un groupe d’exécuteurs est rempli avec des exécuteurs centraux Windows 16, qui ont également reçu l’étiquette windows-2022-16core. La clé runs-on envoie le travail à n’importe quel exécuteur disponible avec une étiquette correspondante :

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

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-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

Utilisation de noms uniques pour les groupes d’exécuteurs

GitHub Actions nécessite que les noms de groupes d’exécuteurs soient uniques au niveau de l’organisation. Cela signifie qu’une organisation ne peut plus créer de groupe d’exécuteurs portant le même nom qu’un autre au sein de l’entreprise. En outre, les utilisateurs voient une bannière d’avertissement sur tous les groupes d’exécuteurs qui partagent le même nom qu’un groupe dans l’entreprise, qui suggère que le groupe d’organisation doit être renommé.

Pour éviter toute ambiguïté, un workflow échoue s’il existe des groupes d’exécuteurs en double dans l’organisation et l’entreprise. Pour résoudre ce problème, vous pouvez renommer l’un de vos groupes d’exécuteurs dans l’organisation ou l’entreprise, ou mettre à jour votre fichier de workflow pour ajouter un préfixe au nom du groupe d’exécuteurs :

• org/ ou organization/
• ent/ ou enterprise/

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 ]

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 « Ajout ou modification d’un mode de paiement ».
• 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 « Gestion de votre limite de dépense pour GitHub Actions ».
• 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.