View a markdown version of this page

Les remplacements d'étiquettes sont pris en charge avec le lanceur d' CodeBuild-hosted GitHub actions - AWS CodeBuild

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les remplacements d'étiquettes sont pris en charge avec le lanceur d' CodeBuild-hosted GitHub actions

Dans votre flux de travail GitHub Actions YAML, vous pouvez proposer une variété de remplacements d'étiquettes qui modifient la version de votre coureur auto-hébergée. Toutes les versions non reconnues par CodeBuild seront ignorées mais votre demande de webhook n'échouera pas. Le flux de travail YAML suivant définit deux tâches : job1 utilise des remplacements pour l'image, la taille de l'instance, le parc et la spécification de génération, et job2 utilise uniquement un remplacement d'image. Attribuez à chaque tâche une étiquette (job1etjob2) unique afin GitHub qu'elle soit redirigée vers le coureur créé pour elle :

name: Hello World on: [push] jobs: job1: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - image:arm-3.0 - instance-size:small - fleet:myFleet - buildspec-override:true - job1 steps: - run: echo "Hello from Job 1!" job2: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - image:linux-5.0 - job2 steps: - run: echo "Hello from Job 2!"

Vous pouvez également utiliser une stratégie matricielle pour exécuter une seule tâche dans plusieurs configurations. Les extensions d'une même tâche matricielle comportent toujours le même nombre d'étiquettes, de sorte que le problème de correspondance des coureurs ne les affecte pas. Toutefois, si l'exécution d'un flux de travail contient plusieurs tâches matricielles, attribuez à chaque tâche matricielle son propre libellé personnalisé (par exemple, matrix-job-1 etmatrix-job-2) afin qu' GitHub aucune tâche ne corresponde à une tâche créée pour une tâche matricielle différente :

name: Hello World on: [push] jobs: Hello-World-Job: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - image:${{ matrix.os }} - instance-size:${{ matrix.size }} - fleet:myFleet - buildspec-override:true - matrix-job-1 strategy: matrix: include: - os: arm-3.0 size: small - os: linux-5.0 size: large steps: - run: echo "Hello World!"
Note

Si votre tâche de flux de travail est en suspens GitHub, consultez Résoudre les problèmes liés au webhook la section Utilisation d'étiquettes personnalisées pour acheminer les tâches.

codebuild-<project-name>-${{github.run_id}}-${{github.run_attempt}} (obligatoire)

  • Exemple : codebuild-fake-project-${{ github.run_id }}-${{ github.run_attempt }}

  • Obligatoire pour tous les GitHub fichiers YAML du flux de travail Actions. <project name>doit être égal au nom du projet pour lequel le webhook du runner auto-hébergé est configuré.

image:<environment-type>-<image-identifier>

instance-size:<instance-size>

fleet:<fleet-name>

buildspec-override:<boolean>

  • Exemple : buildspec-override:true

  • Permet à la compilation d'exécuter les commandes buildspec dans les POST_BUILD phases INSTALLPRE_BUILD, et si elle est définie sur. true

<unique-label>(recommandé lorsqu'un flux de travail comporte plusieurs tâches)

  • Exemple : job1

  • Une étiquette personnalisée que vous définissez et qu'aucune autre tâche du même flux de travail n'utilise. L'attribution d'une étiquette unique à chaque tâche garantit que chaque tâche est GitHub acheminée uniquement vers le coureur qui a été créé pour elle. Dans le cas contraire, lorsque les tâches exécutées dans le même flux de travail comportent un nombre différent de remplacements d'étiquettes, une tâche comportant moins d'étiquettes peut être reprise par une tâche créée pour une tâche comportant plus d'étiquettes, laissant la deuxième tâche sans liste. Pour de plus amples informations, veuillez consulter Résoudre les problèmes liés au webhook.

Remplacement d'une seule étiquette

CodeBuild vous permet de fournir plusieurs remplacements dans une seule étiquette en utilisant les éléments suivants :

Note

Comme toutes les dérogations sont combinées en une seule étiquette, le responsable de chaque tâche s'enregistre avec exactement une seule étiquette. Cela signifie que le problème de correspondance entre plusieurs exécuteurs de tâches décrit dans Résoudre les problèmes liés au webhook ne peut pas se produire avec ce format, même sans une étiquette unique sur chaque tâche. Utilisez le format à étiquette unique si vous préférez ce comportement et que vos tâches n'ont besoin que de remplacements qu'il prend en charge. Ne l'utilisez pas lorsque vous avez besoin d'une dérogation qu'il ne prend pas en charge. Par exemple, les images personnalisées (y compris les images d'un registre privé) ne peuvent être spécifiées qu'à l'aide du format image:custom-<environment-type>-<custom-image-identifier> d'étiquette. Pour ces remplacements, utilisez le format d'étiquette séparée décrit plus haut dans cette rubrique.

  • Pour modifier les paramètres de votre environnement pour une version de EC2/Lambda calcul Amazon, utilisez la syntaxe suivante :

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<environment-type>-<image-identifier>-<instance-size>
  • Pour modifier les paramètres de votre flotte pour la génération de calcul d'Amazon EC2, utilisez la syntaxe suivante :

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-fleet-<fleet-name>
  • Pour remplacer à la fois la flotte et l'image utilisées pour la génération, utilisez la syntaxe suivante :

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-image-<image-version>-fleet-<fleet-name>
  • Pour exécuter les commandes buildspec pendant la compilation, -with-buildspec vous pouvez ajouter un suffixe à l'étiquette :

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<image>-<image-version>-<instance-size>-with-buildspec
  • Vous pouvez éventuellement proposer une modification de la taille de l'instance sans remplacer l'image. Pour les versions Amazon EC2, vous pouvez exclure à la fois le type d'environnement et l'identifiant d'image. Pour les versions Lambda, vous pouvez exclure l'identifiant de l'image.