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. # Référence de spécification de construction pour CodeBuild Cette rubrique fournit des informations de référence importantes sur les fichiers de spécification de génération (buildspec). Un *buildspec* est un ensemble de commandes de construction et de paramètres associés, au format YAML, qui est CodeBuild utilisé pour exécuter un build. Vous pouvez inclure une spécification de construction dans le code source ou vous pouvez définir une spécification de construction lorsque vous créez un projet de construction. Pour plus d'informations sur le fonctionnement des spécifications de génération, consultez [Comment CodeBuild fonctionne](concepts.md#concepts-how-it-works). **Topics** + [Nom de fichier buildspec et emplacement de stockage](#build-spec-ref-name-storage) + [Syntaxe d'un fichier buildspec](#build-spec-ref-syntax) + [Exemple de fichier buildspec](#build-spec-ref-example) + [Versions de fichier buildspec](#build-spec-ref-versions) + [Référence Batch Build Buildspec](batch-build-buildspec.md) ## Nom de fichier buildspec et emplacement de stockage Si vous incluez une spécification de build dans le cadre du code source, par défaut, le fichier de spécification de build doit être nommé `buildspec.yml` et être placé à la racine de votre répertoire source. Vous pouvez remplacer le nom et l'emplacement par défaut du fichier de spécification de build. Par exemple, vous pouvez effectuer les actions suivantes : + Utiliser un fichier de spécification de build distinct pour différentes builds dans le même référentiel, comme par exemple `buildspec_debug.yml` et `buildspec_release.yml`. + Stocker un fichier de spécification de build ailleurs qu'à la racine de votre répertoire source, par exemple `config/buildspec.yml` ou dans un compartiment S3. Le compartiment S3 doit se trouver dans la même AWS région que votre projet de construction. Spécifiez le fichier buildspec à l'aide de son nom ARN (par exemple, `arn:aws:s3:::/buildspec.yml`). Vous pouvez spécifier une seule spécification de build pour un projet de build, quel que soit le nom du fichier de spécification de build. Pour remplacer le nom, l'emplacement, ou les deux, du fichier de spécification de build par défaut, effectuez l'une des actions suivantes : + Exécutez la `update-project` commande AWS CLI `create-project` or en définissant la `buildspec` valeur sur le chemin du fichier buildspec alternatif par rapport à la valeur de la variable d'environnement intégrée. `CODEBUILD_SRC_DIR` Vous pouvez également faire l'équivalent avec l'`create project`opération dans le AWS SDKs. Pour plus d’informations, consultez [Création d'un projet de génération](create-project.md) ou [Modifier les paramètres du projet de construction](change-project.md). + Exécutez la AWS CLI `start-build` commande en définissant la `buildspecOverride` valeur sur le chemin du fichier buildspec alternatif par rapport à la valeur de la variable d'environnement intégrée. `CODEBUILD_SRC_DIR` Vous pouvez également faire l'équivalent avec l'`start build`opération dans le AWS SDKs. Pour de plus amples informations, veuillez consulter [Exécuter les builds manuellement](run-build.md). + Dans un AWS CloudFormation modèle, définissez la `BuildSpec` propriété de `Source` in a resource of type `AWS::CodeBuild::Project` sur le chemin d'accès au fichier buildspec alternatif par rapport à la valeur de la variable d'environnement intégrée. `CODEBUILD_SRC_DIR` Pour plus d'informations, consultez la BuildSpec propriété dans la [source AWS CodeBuild du projet](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html) dans le *guide de AWS CloudFormation l'utilisateur*. ## Syntaxe d'un fichier buildspec Les fichiers de spécification de build doivent être créés au format [YAML](http://yaml.org/). Si une commande contient un caractère ou une chaîne de caractères qui ne sont pas pris en charge par YAML, vous devez placer la commande entre guillemets (""). La commande suivante est placée entre guillemets car un deux-points (:) suivi d'un espace n'est pas autorisé dans YAML. Dans la commande, le guillemet est échappé (\$1"). ``` "export PACKAGE_NAME=$(cat package.json | grep name | head -1 | awk -F: '{ print $2 }' | sed 's/[\",]//g')" ``` La spécification de build a la syntaxe suivante : ``` version: 0.2 run-as: Linux-user-name env: shell: shell-tag variables: key: "value" key: "value" parameter-store: key: "value" key: "value" exported-variables: - variable - variable secrets-manager: key: secret-id:json-key:version-stage:version-id git-credential-helper: no | yes proxy: upload-artifacts: no | yes logs: no | yes batch: fast-fail: false | true # build-list: # build-matrix: # build-graph: # build-fanout: phases: install: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex runtime-versions: runtime: version runtime: version commands: - command - command finally: - command - command pre\$1build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command post\$1build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command reports: report-group-name-or-arn: files: - location - location base-directory: location discard-paths: no | yes file-format: report-format artifacts: files: - location - location name: artifact-name discard-paths: no | yes base-directory: location exclude-paths: excluded paths enable-symlinks: no | yes s3-prefix: prefix secondary-artifacts: artifactIdentifier: files: - location - location name: secondary-artifact-name discard-paths: no | yes base-directory: location artifactIdentifier: files: - location - location discard-paths: no | yes base-directory: location cache: key: key fallback-keys: - fallback-key - fallback-key action: restore | save paths: - path - path ``` La spécification de build contient les éléments suivants : ### version Mappage obligatoire. Représente la version de la spécification de build. Nous vous recommandons d'utiliser `0.2`. **Note** Bien que la version 0.1 soit toujours prise en charge, nous vous recommandons d'utiliser la version 0.2 dans la mesure du possible. Pour de plus amples informations, veuillez consulter [Versions de fichier buildspec](#build-spec-ref-versions). ### run-as Séquence facultative. Disponible uniquement pour les utilisateurs Linux. Spécifie un utilisateur Linux qui exécute des commandes dans ce fichier buildspec. `run-as`accorde à l'utilisateur spécifié des autorisations de lecture et d'exécution. Lorsque vous spécifiez `run-as` en haut du fichier buildspec, il s'applique globalement à toutes les commandes. Si vous ne voulez pas spécifier un utilisateur pour toutes les commandes de fichier buildspec, vous pouvez en spécifier un pour les commandes dans une phase à l'aide de `run-as` dans l'un des blocs `phases`. Si `run-as` n'est pas spécifié, toutes les commandes sont exécutées en tant qu'utilisateur racine. ### env Séquence facultative. Représente les informations pour une ou plusieurs variables d'environnement personnalisées. **Note** Pour protéger les informations sensibles, les informations suivantes sont masquées dans CodeBuild les journaux : AWS clé d'accès IDs. Pour plus d'informations, consultez [la section Gestion des clés d'accès pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) dans le *guide de l'Gestion des identités et des accès AWS utilisateur*. Chaînes spécifiées à l'aide du stockage de paramètres. Pour plus d'informations, consultez la [procédure pas à pas de la console Systems Manager Parameter [Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) et Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console) dans le guide de l'*utilisateur d'Amazon EC2 Systems Manager*. Chaînes spécifiées à l'aide de AWS Secrets Manager. Pour de plus amples informations, veuillez consulter [Gestion des clés](security-key-management.md). **env/ coque** Séquence facultative. Spécifie le shell pris en charge pour les systèmes d'exploitation Linux ou Windows. Pour les systèmes d'exploitation Linux, les balises shell prises en charge sont les suivantes : + `bash` + `/bin/sh` Pour les systèmes d'exploitation Windows, les balises shell prises en charge sont les suivantes : + `powershell.exe` + `cmd.exe` env/**variables** Obligatoire si `env` est spécifié, et que vous voulez définir des variables d'environnement personnalisées en texte brut. Contient un mappage de*key*/*value*scalaires, où chaque mappage représente une variable d'environnement personnalisée unique en texte brut. *key*est le nom de la variable d'environnement personnalisée et *value* la valeur de cette variable. Nous déconseillons vivement le stockage de valeurs sensibles dans les variables d'environnement. Les variables d'environnement peuvent être affichées en texte brut à l'aide d'outils tels que la CodeBuild console et le AWS CLI. Pour les valeurs sensibles, nous vous recommandons d'utiliser à la place le mappage `parameter-store` ou `secrets-manager`, comme décrit plus loin dans cette section. Les variables d'environnement que vous définissez remplacent les variables d'environnement existantes. Par exemple, si l'image Docker contient déjà une variable d'environnement nommée `MY_VAR` avec la valeur `my_value` et que vous définissez une variable d'environnement nommée `MY_VAR` avec la valeur `other_value`, la valeur `my_value` est remplacée par `other_value`. De même, si l'image Docker contient déjà une variable d'environnement nommée `PATH` avec la valeur `/usr/local/sbin:/usr/local/bin` et que vous définissez une variable d'environnement nommée `PATH` avec la valeur `$PATH:/usr/share/ant/bin`, la valeur `/usr/local/sbin:/usr/local/bin` est remplacée par la valeur littérale `$PATH:/usr/share/ant/bin`. Ne définissez pas de variables d'environnement avec un nom commençant par `CODEBUILD_`. Ce préfixe est réservé à une utilisation interne . Si une variable d'environnement avec le même nom est définie dans plusieurs emplacements, la valeur est déterminée comme suit : + La valeur de l'appel d'opération de démarrage de génération a une priorité plus élevée. Vous pouvez ajouter ou remplacer des variables d'environnement lorsque vous créez une génération. Pour de plus amples informations, veuillez consulter [Exécuter AWS CodeBuild les builds manuellement](run-build.md). + La valeur de la définition de projet de génération vient ensuite dans l'ordre des priorités. Vous pouvez ajouter des variables d'environnement au niveau d'un projet lorsque vous créez ou modifiez celui-ci. Pour plus d’informations, consultez [Créez un projet de construction dans AWS CodeBuild](create-project.md) et [Modifier les paramètres du projet de construction dans AWS CodeBuild](change-project.md). + La valeur figurant dans la déclaration buildspec a la priorité la plus faible. env/**magasin de paramètres** Obligatoire si cela `env` est spécifié et si vous souhaitez récupérer des variables d'environnement personnalisées stockées dans Amazon EC2 Systems Manager Parameter Store. Contient un mappage de*key*/*value*scalars, où chaque mappage représente une variable d'environnement personnalisée unique stockée dans le magasin de paramètres Amazon EC2 Systems Manager. *key*est le nom que vous utiliserez ultérieurement dans vos commandes de compilation pour faire référence à cette variable d'environnement personnalisée, ainsi *value* que le nom de la variable d'environnement personnalisée stockée dans le magasin de paramètres Amazon EC2 Systems Manager. Pour stocker des valeurs sensibles, consultez la section [Stockage des paramètres de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) et [procédure pas à pas : création et test d'un paramètre de chaîne (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-console.html) dans le guide de l'*utilisateur d'Amazon EC2 Systems Manager*. CodeBuild Pour permettre de récupérer des variables d'environnement personnalisées stockées dans Amazon EC2 Systems Manager Parameter Store, vous devez ajouter `ssm:GetParameters` l'action à CodeBuild votre rôle de service. Pour de plus amples informations, veuillez consulter [CodeBuild Autoriser l'interaction avec d'autres AWS services](setting-up-service-role.md). Toutes les variables d'environnement que vous récupérez depuis Amazon EC2 Systems Manager Parameter Store remplacent les variables d'environnement existantes. Par exemple, si l'image Docker contient déjà une variable d'environnement nommée `MY_VAR` avec une valeur `my_value`, et que vous récupérez une variable d'environnement nommée `MY_VAR` avec une valeur `other_value`, la valeur `my_value` est alors remplacée par `other_value`. De même, si l'image Docker contient déjà une variable d'environnement nommée `PATH` avec une valeur `/usr/local/sbin:/usr/local/bin`, et que vous récupérez une variable d'environnement nommée `PATH` avec une valeur `$PATH:/usr/share/ant/bin`, la valeur `/usr/local/sbin:/usr/local/bin` est alors remplacée par la valeur littérale `$PATH:/usr/share/ant/bin`. Ne stockez pas de variables d'environnement avec un nom commençant par `CODEBUILD_`. Ce préfixe est réservé à une utilisation interne . Si une variable d'environnement avec le même nom est définie dans plusieurs emplacements, la valeur est déterminée comme suit : + La valeur de l'appel d'opération de démarrage de génération a une priorité plus élevée. Vous pouvez ajouter ou remplacer des variables d'environnement lorsque vous créez une génération. Pour de plus amples informations, veuillez consulter [Exécuter AWS CodeBuild les builds manuellement](run-build.md). + La valeur de la définition de projet de génération vient ensuite dans l'ordre des priorités. Vous pouvez ajouter des variables d'environnement au niveau d'un projet lorsque vous créez ou modifiez celui-ci. Pour plus d’informations, consultez [Créez un projet de construction dans AWS CodeBuild](create-project.md) et [Modifier les paramètres du projet de construction dans AWS CodeBuild](change-project.md). + La valeur figurant dans la déclaration buildspec a la priorité la plus faible. env/**Secrets Manager** Obligatoire si vous souhaitez récupérer des variables d'environnement personnalisées stockées dans AWS Secrets Manager. Spécifiez un Gestionnaire de Secrets `reference-key` en utilisant le modèle suivant : ``: `:::` ** (Obligatoire) Nom de la variable d'environnement locale. Utilisez ce nom pour accéder à la variable lors de la génération. ** (Obligatoire) Le nom ou Amazon Resource Name (ARN) qui sert d'identifiant unique pour le secret. Pour accéder à un secret dans votre compte AWS , spécifiez simplement le nom secret. Pour accéder à un secret dans un autre AWS compte, spécifiez l'ARN du secret. ** (Facultatif) Spécifie le nom de clé de la paire clé-valeur de Secrets Manager dont vous souhaitez récupérer la valeur. Si vous ne spécifiez pas de`json-key`, CodeBuild récupère l'intégralité du texte secret. ** (Facultatif) Spécifie la version secrète que vous souhaitez récupérer à l'aide de l'étiquette intermédiaire attachée à la version. Les étiquettes intermédiaires sont utilisées pour assurer le suivi des différentes versions au cours du processus de rotation. Si vous utilisez la `version-stage`, ne spécifiez pas l’`version-id`. Si vous ne spécifiez pas d'étape de version ni d'ID de version, par défaut, vous devez récupérer la version avec la valeur d'étape de version de `AWSCURRENT`. ** (Facultatif) Spécifie l'identifiant unique de la version du secret que vous souhaitez utiliser. Si vous spécifiez `version-id`, ne spécifiez pas `version-stage`. Si vous ne spécifiez pas d'étape de version ni d'ID de version, par défaut, vous devez récupérer la version avec la valeur d'étape de version de `AWSCURRENT`. Dans l'exemple suivant, `TestSecret` c'est le nom de la paire clé-valeur stockée dans Secrets Manager. La clé pour `TestSecret` nous`MY_SECRET_VAR`. Vous pouvez accéder à la variable pendant la construction en utilisant le `LOCAL_SECRET_VAR` nom. ``` env: secrets-manager: LOCAL_SECRET_VAR: "TestSecret:MY_SECRET_VAR" ``` Pour plus d’informations, consultez [Présentation de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. env/**variables exportées** Mappage facultatif. Permet de répertorier les variables d'environnement que vous souhaitez exporter. Spécifiez le nom de chaque variable que vous souhaitez exporter sur une ligne distincte sous `exported-variables`. La variable que vous souhaitez exporter doit être disponible dans votre conteneur pendant la génération. La variable que vous exportez peut être une variable d'environnement. Les variables d'environnement exportées sont utilisées conjointement AWS CodePipeline pour exporter les variables d'environnement de la phase de construction actuelle vers les étapes suivantes du pipeline. Pour plus d'informations, consultez la section [Utilisation des variables](https://docs.aws.amazon.com//codepipeline/latest/userguide/actions-variables.html) dans le *Guide de AWS CodePipeline l'utilisateur*. Lors d'une génération, la valeur d'une variable est disponible dès la phase `install`. Elle peut être mise à jour entre le début de la phase `install` et la fin de la phase `post_build`. Lorsque la phase `post_build` est terminée, la valeur des variables exportées ne peut pas changer. Les éléments suivants ne peuvent pas être exportés : + Les secrets du magasin de paramètres Amazon EC2 Systems Manager sont spécifiés dans le projet de construction. + Secrets Manager : secrets spécifiés dans le projet de construction + Les variables d'environnement qui commencent par `AWS_`. env/ **git-credential-helper** Mappage facultatif. Utilisé pour indiquer s'il CodeBuild utilise son assistant d'identification Git pour fournir des informations d'identification Git. `yes`s'il est utilisé. Sinon, `no` ou non spécifié. Pour plus d'informations, consultez [gitcredentials](https://git-scm.com/docs/gitcredentials) sur le site web de Git. `git-credential-helper` n’est pas pris en charge pour les générations qui sont déclenchées par un webhook pour un référentiel Git public. ### proxy Séquence facultative. Utilisé pour représenter les paramètres si vous exécutez votre génération dans un serveur proxy explicite. Pour de plus amples informations, veuillez consulter [Exécuter CodeBuild sur un serveur proxy explicite](run-codebuild-in-explicit-proxy-server.md). proxy/**charger les artefacts** Mappage facultatif. Définissez ce paramètre sur `yes` si vous souhaitez que votre build dans un serveur proxy explicite charge des artefacts. La valeur par défaut est `no`. proxy/**journaux** Mappage facultatif. Définissez ce `yes` paramètre pour intégrer un serveur proxy explicite afin de créer des CloudWatch journaux. La valeur par défaut est `no`. ### phases Séquence obligatoire. Représente les CodeBuild commandes exécutées pendant chaque phase de la génération. **Note** Dans la version 0.1 de buildspec, CodeBuild exécute chaque commande dans une instance distincte du shell par défaut dans l'environnement de construction. Cela signifie que chaque commande s'exécute isolée de toutes les autres commandes. Par conséquent, par défaut, vous ne pouvez pas exécuter une commande unique qui s'appuie sur l'état de commandes précédentes (par exemple, pour le changement de répertoire ou la définition de variables d'environnement). Pour contourner ce problème, nous vous recommandons d'utiliser la version 0.2, qui permet de résoudre ce problème. Si vous devez utiliser la spécification de build de version 0.1, nous vous recommandons les approches figurant dans [Shells et commandes dans les environnements de génération](build-env-ref-cmd.md). phases/\$1/**run-as** Séquence facultative. Utilisez-le dans une phase de build pour spécifier un utilisateur Linux qui exécute ses commandes. Si `run-as` est également spécifié globalement pour toutes les commandes en haut du fichier buildspec, alors l'utilisateur au niveau de phase est prioritaire. Par exemple, si `run-as` spécifie globalement l'utilisateur-1, et pour la phase `install` seule une instruction `run-as` spécifie l'utilisateur 2, alors toutes les commandes dans le fichier buildspec sont exécutées en tant qu'utilisateur-1, *sauf* les commandes dans la phase `install`, qui sont exécutées en tant qu'utilisateur-2. **phases/\$1/ en cas de défaillance** Séquence facultative. Spécifie l'action à entreprendre en cas de panne pendant la phase. Il peut s’agir de l’une des valeurs suivantes : + `ABORT`- Annulation de la construction. + `CONTINUE`- Passez à la phase suivante. + `RETRY`- Réessayez la compilation jusqu'à 3 fois avec un message d'erreur correspondant à l'expression `.*` régulière. + `RETRY-count`- Réessayez la compilation un certain nombre de fois, comme indiqué par un message *count* d'erreur correspondant à l'expression `.*` régulière. Notez qu'*count*il doit être compris entre 0 et 100. Par exemple, les valeurs valides incluent `RETRY-4` et`RETRY-8`. + `RETRY-regex`- Réessayez la compilation jusqu'à 3 fois et utilisez-la *regex* pour inclure une expression régulière correspondant à un message d'erreur spécifié. Par exemple, les valeurs valides incluent `Retry-.*Error: Unable to connect to database.*` et`RETRY-invalid+`. + `RETRY-count-regex`- Réessayez de compiler un certain nombre de fois, comme indiqué par*count*. Notez qu'*count*il doit être compris entre 0 et 100. Vous pouvez également l'utiliser *regex* pour inclure une expression régulière correspondant au message d'erreur. Par exemple, les valeurs valides incluent `Retry-3-.*connection timed out.*` et`RETRY-8-invalid+`. Si cette propriété n'est pas spécifiée, le processus d'échec suit les phases de transition, comme indiqué dans[Transitions des phases de génération](view-build-details-phases.md). L'`on-failure`attribut n'est pas pris en charge lors de l'utilisation du calcul Lambda ou de la capacité réservée. Cet attribut ne fonctionne qu'avec les images de calcul EC2 fournies par CodeBuild. **phases/\$1/ enfin** Bloc facultatif. Les commandes spécifiées dans un `finally` bloc sont exécutées après les commandes du `commands` bloc. Les commandes d'un `finally` bloc sont exécutées même si une commande du `commands` bloc échoue. Par exemple, si le `commands` bloc contient trois commandes et que la première échoue, CodeBuild ignore les deux commandes restantes et exécute toutes les commandes du `finally` bloc. La phase est réussie lorsque toutes les commandes des blocs `commands` et `finally` s'exécutent avec succès. Si une commande d'une phase échoue, la phase échoue. Les noms de phase de génération autorisés sont : phases/**installer** Séquence facultative. Représente les commandes, le cas échéant, CodeBuild exécutées pendant l'installation. Nous vous recommandons d'utiliser la phase `install` uniquement pour l'installation de packages dans l'environnement de génération. Par exemple, vous pouvez utiliser cette phase pour installer un framework de test de code tel que Mocha ou RSpec. phases/installer/**versions d'exécution** Séquence facultative. Une version d'exécution est prise en charge avec l'image standard Ubuntu 5.0 ou ultérieure et l'image standard Amazon Linux 2 4.0 ou version ultérieure. Si cette valeur est spécifiée, au moins une exécution doit être incluse dans cette section. Spécifiez un environnement d'exécution utilisant une version spécifique, une version majeure suivie de `.x` pour spécifier qui CodeBuild utilise cette version majeure avec sa dernière version mineure, ou `latest` pour utiliser les versions majeure et mineure les plus récentes (par exemple`ruby: 3.2`,`nodejs: 18.x`, ou`java: latest`). Vous pouvez spécifier l’exécution à l'aide d'un nombre ou d'une variable d'environnement. Par exemple, si vous utilisez l'image standard 4.0 d'Amazon Linux 2, ce qui suit indique que la version 17 de Java, la dernière version mineure de python version 3 et une version contenue dans une variable d'environnement de Ruby sont installées. Pour de plus amples informations, veuillez consulter [Images Docker fournies par CodeBuild](build-env-ref-available.md). ``` phases: install: runtime-versions: java: corretto8 python: 3.x ruby: "$MY_RUBY_VAR" ``` Vous pouvez spécifier un ou plusieurs runtimes dans la section `runtime-versions` de votre fichier buildspec. Si votre runtime dépend d'un autre runtime, vous pouvez également spécifier son runtime dépendant dans le fichier buildspec. Si vous ne spécifiez aucun environnement d'exécution dans le fichier buildspec, CodeBuild choisissez les environnements d'exécution par défaut disponibles dans l'image que vous utilisez. Si vous spécifiez un ou plusieurs environnements d'exécution, utilisez uniquement CodeBuild ces environnements d'exécution. Si aucun environnement d'exécution dépendant n'est spécifié, CodeBuild tente de le choisir pour vous. Si aucune version d'exécution n'est spécifiée, CodeBuild utilise la version par défaut. La version par défaut peut changer lorsqu'une version par défaut arrive en fin de vie (EOL). Pour éviter des modifications inattendues de l'environnement de génération, nous vous recommandons de spécifier une version d'exécution dans le fichier buildspec. Si deux exécutions spécifiées entrent en conflit, la génération échoue. Par exemple, `android: 29` et `java: openjdk11` sont en conflit, par conséquent si les deux sont spécifiés, la génération échoue. Pour plus d'informations sur les environnements d'exécution disponibles, consultez[Runtimes disponibles](available-runtimes.md). Si vous spécifiez une `runtime-versions` section et utilisez une image autre qu'Ubuntu Standard Image 2.0 ou version ultérieure, ou l'image standard Amazon Linux 2 (AL2) 1.0 ou version ultérieure, le build émet l'avertissement « »`Skipping install of runtimes. Runtime version selection is not supported by this build image`. phases/installer/**commandes** Séquence facultative. Contient une séquence de scalaires, où chaque scalaire représente une commande unique CodeBuild exécutée pendant l'installation. CodeBuild exécute chaque commande, une par une, dans l'ordre indiqué, du début à la fin. phases/**prégénération** Séquence facultative. Représente les commandes, le cas échéant, CodeBuild exécutées avant la génération. Par exemple, vous pouvez utiliser cette phase pour vous connecter à Amazon ECR, ou vous pouvez installer des dépendances npm. phases/prégénération/**commandes** Séquence obligatoire si `pre_build` est spécifié. Contient une séquence de scalaires, où chaque scalaire représente une commande unique CodeBuild exécutée avant la génération. CodeBuildexécute chaque commande, une par une, dans l'ordre indiqué, du début à la fin. phases/**génération** Séquence facultative. Représente les commandes, le cas échéant, CodeBuild exécutées pendant la génération. Par exemple, vous pouvez utiliser cette phase pour exécuter Mocha ou sbt. RSpec phases/génération/**commandes** Obligatoire si cela `build` est spécifié. Contient une séquence de scalaires, où chaque scalaire représente une commande unique CodeBuild exécutée pendant la génération. CodeBuild exécute chaque commande, une par une, dans l'ordre indiqué, du début à la fin. phases/**post-génération** Séquence facultative. Représente les commandes, le cas échéant, CodeBuild exécutées après la génération. Par exemple, vous pouvez utiliser Maven pour empaqueter les artefacts de construction dans un fichier JAR ou WAR, ou vous pouvez transférer une image Docker dans Amazon ECR. Vous pouvez ensuite envoyer une notification de build via Amazon SNS. phases/post-génération/**commandes** Obligatoire si cela `post_build` est spécifié. Contient une séquence de scalaires, où chaque scalaire représente une commande unique CodeBuild exécutée après la génération. CodeBuild exécute chaque commande, une par une, dans l'ordre indiqué, du début à la fin. ### rapports **report-group-name-or-fil** Séquence facultative. Spécifie le groupe de rapports auquel les rapports sont envoyés. Un projet peut comporter un maximum de cinq groupes de rapports. Spécifiez l'ARN d'un groupe de rapports existant ou le nom d'un nouveau groupe de rapports. Si vous spécifiez un nom, CodeBuild crée un groupe de rapports en utilisant le nom de votre projet et le nom que vous spécifiez dans le format`-`. Le nom du groupe de rapports peut également être défini à l'aide d'une variable d'environnement dans la spécification de construction, telle que. `$REPORT_GROUP_NAME` Pour de plus amples informations, veuillez consulter [Attribution des noms des groupes de rapports](test-report-group-naming.md). rapports//**fichiers** Séquence obligatoire. Représente les emplacements qui contiennent les données brutes des résultats de test générés par le rapport. Contient une séquence de scalaires, chaque scalaire représentant un emplacement distinct où se CodeBuild trouvent les fichiers de test, par rapport à l'emplacement de construction d'origine ou, s'il est défini, au. `base-directory` Il peut s'agir notamment des emplacements suivants : + Un fichier unique (par exemple, `my-test-report-file.json`). + Un fichier unique dans un sous-répertoire (par exemple, `my-subdirectory/my-test-report-file.json` ou `my-parent-subdirectory/my-subdirectory/my-test-report-file.json`). + `'**/*'` représente tous les fichiers de manière récursive. + `my-subdirectory/*`représente tous les fichiers d'un sous-répertoire nommé*my-subdirectory*. + `my-subdirectory/**/*`représente tous les fichiers de manière récursive à partir d'un sous-répertoire nommé. *my-subdirectory* rapports//**format de fichier** Mappage facultatif. Représente le format du fichier de rapport. Si non spécifié, `JUNITXML` est utilisé. Cette valeur ne distingue pas les majuscules et minuscules. Les valeurs possibles sont : **Rapports d'essais** `CUCUMBERJSON` Cucumber JSON `JUNITXML` JUnit XML `NUNITXML` NUnit XML `NUNIT3XML` NUnit 3 XML `TESTNGXML` TestNG XML `VISUALSTUDIOTRX` Visual Studio TRX **Rapports de couverture du code** `CLOVERXML` Clover XML `COBERTURAXML` Cobertura XML `JACOCOXML` JaCoCo XML `SIMPLECOV` SimpleCov JSON CodeBuild [accepte les rapports de couverture du code JSON générés par [simplecov, et non par simplecov-json](https://github.com/simplecov-ruby/simplecov).](https://github.com/vicentllongo/simplecov-json) rapports//**répertoire de base** Mappage facultatif. Représente un ou plusieurs répertoires de niveau supérieur, relatifs à l'emplacement de construction d'origine, qui CodeBuild permettent de déterminer où trouver les fichiers de test bruts. rapports//**annuler les chemins** Facultatif. Spécifie si les répertoires de fichiers de rapport sont aplatis dans la sortie. Si cela n'est pas spécifié ou si `no` est défini, les fichiers de rapport sont générés avec leur structure de répertoire intacte. Si `yes` est défini, tous les fichiers de test sont placés dans le même répertoire de sortie. Par exemple, si un chemin d'accès à un résultat de test est `com/myapp/mytests/TestResult.xml`, la définition de `yes` place ce fichier dans `/TestResult.xml`. ### artefacts Séquence facultative. Représente des informations indiquant où se CodeBuild trouve la sortie de compilation et comment CodeBuild la préparer pour le téléchargement vers le compartiment de sortie S3. Cette séquence n'est pas obligatoire si, par exemple, vous créez et transférez une image Docker vers Amazon ECR, ou si vous exécutez des tests unitaires sur votre code source, mais que vous ne le créez pas. **Note** Les métadonnées Amazon S3 ont un CodeBuild en-tête nommé `x-amz-meta-codebuild-buildarn` qui contient le nom `buildArn` de la CodeBuild version qui publie les artefacts sur Amazon S3. Le `buildArn` est ajouté pour permettre le suivi de la source des notifications et pour indiquer à partir de quelle version l'artefact est généré. artefacts/**fichiers** Séquence obligatoire. Représente les emplacements qui contiennent les artefacts de sortie de génération dans l'environnement de génération. Contient une séquence de scalaires, où chaque scalaire représente un emplacement distinct où CodeBuild peut trouver des artefacts de sortie de génération, par rapport à l'emplacement de génération d'origine ou, si défini, au répertoire de base. Il peut s'agir notamment des emplacements suivants : + Un fichier unique (par exemple, `my-file.jar`). + Un fichier unique dans un sous-répertoire (par exemple, `my-subdirectory/my-file.jar` ou `my-parent-subdirectory/my-subdirectory/my-file.jar`). + `'**/*'` représente tous les fichiers de manière récursive. + `my-subdirectory/*`représente tous les fichiers d'un sous-répertoire nommé*my-subdirectory*. + `my-subdirectory/**/*`représente tous les fichiers de manière récursive à partir d'un sous-répertoire nommé. *my-subdirectory* Lorsque vous spécifiez les emplacements des artefacts de sortie de construction, vous CodeBuild pouvez localiser l'emplacement de construction d'origine dans l'environnement de construction. Vous n'avez pas besoin de préfixer les emplacements d'artefact de sortie de génération avec le chemin de l'emplacement de génération d'origine, ni de spécifier `./` ou un élément similaire. Si vous souhaitez connaître le chemin d'accès à cet emplacement, vous pouvez exécuter une commande comme `echo $CODEBUILD_SRC_DIR` pendant une génération. L'emplacement de chaque environnement de génération peut être légèrement différent. artefacts/**nom** Nom facultatif. Spécifie un nom pour votre artefact de génération. Ce nom est utilisé lorsque l'une des conditions suivantes est vraie. + Vous utilisez l' CodeBuild API pour créer vos versions et l'`overrideArtifactName`indicateur est défini sur l'`ProjectArtifacts`objet lorsqu'un projet est mis à jour, qu'un projet est créé ou qu'un build est lancé. + Vous utilisez la CodeBuild console pour créer vos versions, un nom est spécifié dans le fichier buildspec et vous sélectionnez **Activer le versionnement sémantique** lorsque vous créez ou mettez à jour un projet. Pour de plus amples informations, veuillez consulter [Création d'un projet de génération (console)](create-project.md#create-project-console). Vous pouvez spécifier un nom dans le fichier de spécification de build qui est calculé au moment de la génération. Le nom spécifié dans un fichier de spécification de build utilise le langage de commandes Shell. Par exemple, vous pouvez ajouter une date et une heure au nom de votre artefact afin qu'il soit toujours unique. Les noms d'artefact uniques empêchent les artefacts d'être écrasés. Pour de plus amples informations, veuillez consulter [Langage de commandes Shell](http://pubs.opengroup.org/onlinepubs/9699919799/). + Ceci est un exemple de nom d'artefact suivi de la date à laquelle l'artefact a été créé. ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(date +%Y-%m-%d) ``` + Il s'agit d'un exemple de nom d'artefact qui utilise une variable d' CodeBuild environnement. Pour de plus amples informations, veuillez consulter [Variables d'environnement dans les environnements de génération](build-env-ref-env-vars.md). ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$AWS_REGION ``` + Voici un exemple de nom d'artefact qui utilise une variable d' CodeBuild environnement à laquelle est ajoutée la date de création de l'artefact. ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $AWS_REGION-$(date +%Y-%m-%d) ``` Vous pouvez ajouter des informations de chemin au nom afin que les artefacts nommés soient placés dans des répertoires en fonction du chemin indiqué dans le nom. Dans cet exemple, les artefacts de construction sont placés dans la sortie sous`builds//my-artifacts`. ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts ``` artefacts/**ignorer les chemins** Facultatif. Spécifie si les répertoires d'artefacts de génération sont aplatis dans la sortie. Si cela n'est pas spécifié, si `no` est défini, les artefacts de génération sont générés avec leur structure de répertoire intacte. Si `yes` est défini, tous les artefacts de génération sont placés dans le même répertoire de sortie. Par exemple, si un chemin d'accès à un fichier dans l'artefact de sortie de génération est `com/mycompany/app/HelloWorld.java`, la définition de `yes` permet de placer ce fichier dans `/HelloWorld.java`. artefacts/**répertoire de base** Mappage facultatif. Représente un ou plusieurs répertoires de niveau supérieur, relatifs à l'emplacement de génération d'origine, qui permettent CodeBuild de déterminer les fichiers et sous-répertoires à inclure dans l'artefact de sortie de génération. Les valeurs valides sont les suivantes : + Un répertoire unique de niveau supérieur (par exemple, `my-directory`). + `'my-directory*'` représente tous les répertoires de niveau supérieur avec les noms commençant par `my-directory`. Les répertoires de niveau supérieur correspondants ne sont pas inclus dans l'artefact de sortie de génération, seulement leurs fichiers et sous-répertoires. Vous pouvez utiliser `files` et `discard-paths` pour limiter encore plus les fichiers et sous-répertoires inclus. Par exemple, pour la structure de répertoire suivante : ``` . ├── my-build-1 │ └── my-file-1.txt └── my-build-2 ├── my-file-2.txt └── my-subdirectory └── my-file-3.txt ``` Et pour la séquence `artifacts` suivante : ``` artifacts: files: - '*/my-file-3.txt' base-directory: my-build-2 ``` Le sous-répertoire et le fichier suivants seront inclus dans l'artefact de sortie de génération : ``` . └── my-subdirectory └── my-file-3.txt ``` Alors que pour la séquence `artifacts` suivante : ``` artifacts: files: - '**/*' base-directory: 'my-build*' discard-paths: yes ``` Les fichiers suivants seront inclus dans l'artefact de sortie de génération : ``` . ├── my-file-1.txt ├── my-file-2.txt └── my-file-3.txt ``` **artéfacts/ chemins d'exclusion** Mappage facultatif. Représente un ou plusieurs chemins, relatifs à`base-directory`, qui CodeBuild seront exclus de la construction des artefacts. L'astérisque (`*`) correspond à zéro ou plusieurs caractères d'un composant de nom sans dépasser les limites d'un dossier. Un double astérisque (`**`) correspond à zéro ou plusieurs caractères d'un composant de nom dans tous les répertoires. Voici des exemples de chemins d'exclusion : + Pour exclure un fichier de tous les répertoires : `"**/file-name/**/*"` + Pour exclure tous les dossiers à points : `"**/.*/**/*"` + Pour exclure tous les fichiers à points : `"**/.*"` **artéfacts/ activer les liens symboliques** Facultatif. Si le type de sortie est`ZIP`, indique si les liens symboliques internes sont conservés dans le fichier ZIP. Si tel est le cas`yes`, tous les liens symboliques internes de la source seront conservés dans le fichier ZIP des artefacts. **artéfacts/ préfixe s3** Facultatif. Spécifie un préfixe utilisé lorsque les artefacts sont envoyés vers un compartiment Amazon S3 et que le type d'espace de noms est. `BUILD_ID` Lorsqu'il est utilisé, le chemin de sortie dans le compartiment est`//.zip`. artefacts/**artefacts secondaires** Séquence facultative. Représente une ou plusieurs définitions d'artefacts comme correspondance entre l'identificateur d'un artefact et la définition d'un artefact. Chaque identifiant d'artefact de ce bloc doit correspondre à un artefact défini dans l'attribut `secondaryArtifacts` de votre projet. Chaque définition distincte a la même syntaxe que le bloc `artifacts` ci-dessus. La [`artifacts/files`](#build-spec.artifacts.files)séquence est toujours requise, même lorsque seuls des artefacts secondaires sont définis. Par exemple, si la structure de votre projet est la suivante : ``` { "name": "sample-project", "secondaryArtifacts": [ { "type": "S3", "location": "", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "", "artifactIdentifier": "artifact2", "name": "secondary-artifact-name-2" } ] } ``` Votre fichier buildspec ressemble alors à ceci : ``` version: 0.2 phases: build: commands: - echo Building... artifacts: files: - '**/*' secondary-artifacts: artifact1: files: - directory/file1 name: secondary-artifact-name-1 artifact2: files: - directory/file2 name: secondary-artifact-name-2 ``` ### cache Séquence facultative. Représente des informations sur l'endroit où CodeBuild préparer les fichiers pour le téléchargement du cache dans un compartiment de cache S3. Cette séquence n'est pas requise si le type de cache du projet est `No Cache`. **cache/clé** Séquence facultative. Représente la clé primaire utilisée lors de la recherche ou de la restauration d'un cache. CodeBuild correspond exactement à la clé primaire. Voici un exemple de clé : ``` key: npm-key-$(codebuild-hash-files package-lock.json) } ``` **clés de cache ou de secours** Séquence facultative. Représente une liste de clés de secours utilisées de manière séquentielle lorsqu'un cache est introuvable à l'aide de la clé primaire. Jusqu'à cinq clés de secours sont prises en charge, et chacune est mise en correspondance à l'aide d'une recherche par préfixe. Cette séquence sera ignorée si la **clé** n'est pas fournie. Voici un exemple pour les clés de secours : ``` fallback-keys: - npm-key-$(codebuild-hash-files package-lock.json) } - npm-key- - npm- ``` **cache/action** Séquence facultative. Spécifie l'action à effectuer sur le cache. Les valeurs valides sont les suivantes : + `restore`qui restaure uniquement le cache sans enregistrer les mises à jour. + `save`qui enregistre uniquement le cache sans restaurer une version précédente. Si aucune valeur n'est fournie, la fonction CodeBuild par défaut consiste à effectuer à la fois la restauration et la sauvegarde. cache/**chemins** Séquence obligatoire. Représente les emplacements du cache. Contient une séquence de scalaires, chaque scalaire représentant un emplacement distinct où CodeBuild peuvent trouver les artefacts de sortie de construction, par rapport à l'emplacement de construction d'origine ou, s'il est défini, au répertoire de base. Il peut s'agir notamment des emplacements suivants : + Un fichier unique (par exemple, `my-file.jar`). + Un fichier unique dans un sous-répertoire (par exemple, `my-subdirectory/my-file.jar` ou `my-parent-subdirectory/my-subdirectory/my-file.jar`). + `'**/*'` représente tous les fichiers de manière récursive. + `my-subdirectory/*`représente tous les fichiers d'un sous-répertoire nommé*my-subdirectory*. + `my-subdirectory/**/*`représente tous les fichiers de manière récursive à partir d'un sous-répertoire nommé. *my-subdirectory* **Important** Comme une déclaration de spécification de build doit être dans un format YAML valide, les espaces sont importants dans une déclaration de spécification de build. Si le nombre d'espaces dans votre déclaration de spécification de build n'est pas valide, les builds peuvent échouer immédiatement. Vous pouvez utiliser un validateur YAML pour tester si vos déclarations de spécification de build sont dans un format YAML valide. Si vous utilisez le AWS CLI, ou le AWS SDKs pour déclarer une spécification de construction lorsque vous créez ou mettez à jour un projet de construction, la spécification de construction doit être une chaîne unique exprimée au format YAML, avec les espaces blancs et les caractères d'échappement de nouvelle ligne requis. Vous trouverez un exemple dans la section suivante. Si vous utilisez les AWS CodePipeline consoles CodeBuild ou au lieu d'un fichier buildspec.yml, vous pouvez insérer des commandes pour la phase uniquement. `build` Au lieu d'utiliser la syntaxe précédente, vous répertoriez, sur une seule ligne, toutes les commandes que vous souhaitez exécuter lors de la phase de génération (build). Pour plusieurs commandes, séparez celles-ci avec `&&` (par exemple, `mvn test && mvn package`). Vous pouvez utiliser les CodePipeline consoles CodeBuild ou au lieu d'un fichier buildspec.yml pour spécifier les emplacements des artefacts de sortie de génération dans l'environnement de génération. Au lieu d'utiliser la syntaxe précédente, vous répertoriez, sur une seule ligne, tous les emplacements. Pour plusieurs emplacements, séparez ceux-ci avec une virgule (par exemple, `buildspec.yml, target/my-app.jar`). ## Exemple de fichier buildspec Voici un exemple de fichier buildspec.yml. ``` version: 0.2 env: variables: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" parameter-store: LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword phases: install: commands: - echo Entered the install phase... - apt-get update -y - apt-get install -y maven finally: - echo This always runs even if the update or install command fails pre_build: commands: - echo Entered the pre_build phase... - docker login -u User -p $LOGIN_PASSWORD finally: - echo This always runs even if the login command fails build: commands: - echo Entered the build phase... - echo Build started on `date` - mvn install finally: - echo This always runs even if the install command fails post_build: commands: - echo Entered the post_build phase... - echo Build completed on `date` reports: arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1: files: - "**/*" base-directory: 'target/tests/reports' discard-paths: no reportGroupCucumberJson: files: - 'cucumber/target/cucumber-tests.xml' discard-paths: yes file-format: CUCUMBERJSON # default is JUNITXML artifacts: files: - target/messageUtil-1.0.jar discard-paths: yes secondary-artifacts: artifact1: files: - target/artifact-1.0.jar discard-paths: yes artifact2: files: - target/artifact-2.0.jar discard-paths: yes cache: paths: - '/root/.m2/**/*' ``` Voici un exemple de la spécification de construction précédente, exprimée sous forme de chaîne unique, à utiliser avec le AWS CLI, ou le. AWS SDKs ``` "version: 0.2\n\nenv:\n variables:\n JAVA_HOME: \"/usr/lib/jvm/java-8-openjdk-amd64\\"\n parameter-store:\n LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n phases:\n\n install:\n commands:\n - echo Entered the install phase...\n - apt-get update -y\n - apt-get install -y maven\n finally:\n - echo This always runs even if the update or install command fails \n pre_build:\n commands:\n - echo Entered the pre_build phase...\n - docker login -u User -p $LOGIN_PASSWORD\n finally:\n - echo This always runs even if the login command fails \n build:\n commands:\n - echo Entered the build phase...\n - echo Build started on `date`\n - mvn install\n finally:\n - echo This always runs even if the install command fails\n post_build:\n commands:\n - echo Entered the post_build phase...\n - echo Build completed on `date`\n\n reports:\n reportGroupJunitXml:\n files:\n - \"**/*\"\n base-directory: 'target/tests/reports'\n discard-paths: false\n reportGroupCucumberJson:\n files:\n - 'cucumber/target/cucumber-tests.xml'\n file-format: CUCUMBERJSON\n\nartifacts:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n secondary-artifacts:\n artifact1:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n artifact2:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n cache:\n paths:\n - '/root/.m2/**/*'" ``` Voici un exemple des commandes de la `build` phase, à utiliser avec les CodePipeline consoles CodeBuild or. ``` echo Build started on `date` && mvn install ``` Dans les exemples suivants : + Une variable d'environnement personnalisée, en texte brut, avec la clé `JAVA_HOME` et la valeur `/usr/lib/jvm/java-8-openjdk-amd64` est définie. + Une variable d'environnement personnalisée nommée `dockerLoginPassword` you stockée dans Amazon EC2 Systems Manager Parameter Store est référencée ultérieurement dans les commandes de construction à l'aide de la `LOGIN_PASSWORD` clé. + Vous ne pouvez pas modifier ces noms de phase de génération. Les commandes exécutées dans cet exemple sont `apt-get update -y` et `apt-get install -y maven` (pour installer Apache Maven), `mvn install` (pour compiler, tester et empaqueter le code source dans un artefact de sortie de build et pour installer l'artefact de sortie de build dans son référentiel interne), `docker login` (pour se connecter à Docker avec le mot de passe correspondant à la valeur de la variable d'environnement personnalisée que `dockerLoginPassword` vous avez définie dans Amazon EC2 Systems Manager Parameter Store) et plusieurs commandes. `echo` Les `echo` commandes sont incluses ici pour montrer comment les CodeBuild commandes sont exécutées et l'ordre dans lequel elles sont exécutées. + `files` représente les fichiers à charger dans l'emplacement de sortie de génération. Dans cet exemple, CodeBuild télécharge le fichier `messageUtil-1.0.jar` unique. Le fichier `messageUtil-1.0.jar` peut être trouvé dans le répertoire relatif nommé `target` dans l'environnement de génération. Comme `discard-paths: yes` est spécifié, `messageUtil-1.0.jar` est chargé directement (et non dans un répertoire `target` intermédiaire). Le nom de fichier `messageUtil-1.0.jar` et le nom de répertoire relatif de `target` sont basés sur la façon dont Apache crée et stocke les artefacts de sortie de génération pour cet exemple uniquement. Dans votre propres scénarios, ces noms de fichier et ces répertoires seront différents. + `reports` représente deux groupes de rapports qui génèrent des rapports pendant la génération : + `arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1` spécifie l'ARN d'un groupe de rapports. Les résultats des tests générés par le framework de test se trouvent dans le répertoire `target/tests/reports`. Le format de fichier est `JunitXml` et le chemin d'accès n'est pas supprimé des fichiers contenant les résultats du test. + `reportGroupCucumberJson` spécifie un nouveau groupe de rapports. Si le nom du projet est `my-project`, un groupe de rapports portant le nom `my-project-reportGroupCucumberJson` est créé lors de l'exécution d'une génération. Les résultats des tests générés par le framework de test sont dans `cucumber/target/cucumber-tests.xml`. Le format de fichier test est `CucumberJson` et le chemin d'accès est supprimé des fichiers contenant les résultats du test. ## Versions de fichier buildspec Le tableau suivant répertorie les versions de spécification de build et les modifications entre les versions. | Version | Modifications | | --- | --- | | 0.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/build-spec-ref.html) | | 0.1 | Il s'agit de la définition initiale du format de spécification de génération. | # Référence Batch Build Buildspec Cette rubrique contient la référence buildspec pour les propriétés de construction par lots. ## lot Mappage facultatif. Les paramètres de génération par lots pour le projet. **batch ou échec rapide** Facultatif. Spécifie le comportement de la génération par lots lorsqu'une ou plusieurs tâches de génération échouent. `false` La valeur par défaut. Toutes les versions en cours seront terminées. `true` Toutes les versions en cours seront arrêtées en cas d'échec de l'une des tâches de génération. Par défaut, toutes les tâches de génération par lots sont exécutées avec les paramètres de génération tels que `env` et`phases`, spécifiés dans le fichier buildspec. Vous pouvez remplacer les paramètres de construction par défaut en spécifiant des `env` valeurs différentes ou un fichier de spécification de construction différent dans le paramètre. `batch//buildspec` Le contenu de la `batch` propriété varie en fonction du type de construction par lots spécifié. Les types de construction par lots possibles sont les suivants : + [`batch/build-graph`](#build-spec.batch.build-graph) + [`batch/build-list`](#build-spec.batch.build-list) + [`batch/build-matrix`](#build-spec.batch.build-matrix) + [`batch/build-fanout`](#build-spec.batch.build-fanout) ## `batch/build-graph` Définit un *graphe de construction*. Un graphe de génération définit un ensemble de tâches qui dépendent d'autres tâches du lot. Pour de plus amples informations, veuillez consulter [Construire un graphe](batch-build.md#batch_build_graph). Cet élément contient un ensemble de tâches de construction. Chaque tâche de génération contient les propriétés suivantes. **identifiant** Obligatoire. Identifiant de la tâche. **build spec** Facultatif. Le chemin et le nom du fichier buildspec à utiliser pour cette tâche. Si ce paramètre n'est pas spécifié, le fichier buildspec actuel est utilisé. **session de débogage** Facultatif. Valeur booléenne qui indique si le débogage de session est activé pour cette génération par lots. Pour plus d'informations sur le débogage de session, consultez[Déboguer les builds avec le gestionnaire de session](session-manager.md). `false` Le débogage de session est désactivé. `true` Le débogage de session est activé. **dépendre** Facultatif. Tableau d'identificateurs de tâches dont dépend cette tâche. Cette tâche ne sera pas exécutée tant que ces tâches ne seront pas terminées. **env** Facultatif. L'environnement de génération remplace la tâche. Cela peut contenir les propriétés suivantes : **type de calcul** Identifiant du type de calcul à utiliser pour la tâche. Voir **ComputeType** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) in pour les valeurs possibles. **flotte** Identifiant de la flotte à utiliser pour la tâche. Pour plus d’informations, consultez [Exécutez des builds sur des flottes à capacité réservée](fleets.md). **image** Identifiant de l'image à utiliser pour la tâche. Voir **Identifiant de l'image** dans [Images Docker fournies par CodeBuild](build-env-ref-available.md) pour les valeurs possibles. **mode privilégié** Valeur booléenne qui indique s'il faut exécuter le démon Docker dans un conteneur Docker. Défini sur `true` uniquement si le projet de génération est utilisé pour créer des images Docker. À défaut, une génération qui tente d'interagir avec le démon Docker échoue. Le paramètre par défaut est `false`. **type** Identifiant du type d'environnement à utiliser pour la tâche. Voir **Type d'environnement** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) pour les valeurs possibles. **variables** Les variables d'environnement qui seront présentes dans l'environnement de construction. Pour plus d’informations, consultez [env/variables](build-spec-ref.md#build-spec.env.variables). Notez que le **type de calcul** et le **parc** ne peuvent pas être fournis dans le même identifiant pour une seule version. **ignorer l'échec** Facultatif. Une valeur booléenne qui indique si l'échec de cette tâche de génération peut être ignoré. `false` La valeur par défaut. Si cette tâche de génération échoue, la génération par lots échouera. `true` Si cette tâche de génération échoue, la génération par lots peut toujours réussir. Voici un exemple d'entrée buildspec du graphe de construction : ``` batch: fast-fail: false build-graph: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 depend-on: - build1 - identifier: build3 env: variables: BUILD_ID: build3 depend-on: - build2 - identifier: build4 env: compute-type: ARM_LAMBDA_1GB - identifier: build5 env: fleet: fleet_name ``` ## `batch/build-list` Définit une *liste de build*. Une liste de construction est utilisée pour définir un certain nombre de tâches exécutées en parallèle. Pour de plus amples informations, veuillez consulter [Construire une liste](batch-build.md#batch_build_list). Cet élément contient un ensemble de tâches de construction. Chaque tâche de génération contient les propriétés suivantes. **identifiant** Obligatoire. Identifiant de la tâche. **build spec** Facultatif. Le chemin et le nom du fichier buildspec à utiliser pour cette tâche. Si ce paramètre n'est pas spécifié, le fichier buildspec actuel est utilisé. **session de débogage** Facultatif. Valeur booléenne qui indique si le débogage de session est activé pour cette génération par lots. Pour plus d'informations sur le débogage de session, consultez[Déboguer les builds avec le gestionnaire de session](session-manager.md). `false` Le débogage de session est désactivé. `true` Le débogage de session est activé. **env** Facultatif. L'environnement de génération remplace la tâche. Cela peut contenir les propriétés suivantes : **type de calcul** Identifiant du type de calcul à utiliser pour la tâche. Voir **ComputeType** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) in pour les valeurs possibles. **flotte** Identifiant de la flotte à utiliser pour la tâche. Pour plus d’informations, consultez [Exécutez des builds sur des flottes à capacité réservée](fleets.md). **image** Identifiant de l'image à utiliser pour la tâche. Voir **Identifiant de l'image** dans [Images Docker fournies par CodeBuild](build-env-ref-available.md) pour les valeurs possibles. **mode privilégié** Valeur booléenne qui indique s'il faut exécuter le démon Docker dans un conteneur Docker. Défini sur `true` uniquement si le projet de génération est utilisé pour créer des images Docker. À défaut, une génération qui tente d'interagir avec le démon Docker échoue. Le paramètre par défaut est `false`. **type** Identifiant du type d'environnement à utiliser pour la tâche. Voir **Type d'environnement** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) pour les valeurs possibles. **variables** Les variables d'environnement qui seront présentes dans l'environnement de construction. Pour plus d’informations, consultez [env/variables](build-spec-ref.md#build-spec.env.variables). Notez que le **type de calcul** et le **parc** ne peuvent pas être fournis dans le même identifiant pour une seule version. **ignorer l'échec** Facultatif. Une valeur booléenne qui indique si l'échec de cette tâche de génération peut être ignoré. `false` La valeur par défaut. Si cette tâche de génération échoue, la génération par lots échouera. `true` Si cette tâche de génération échoue, la génération par lots peut toujours réussir. Voici un exemple d'entrée buildspec de liste de construction : ``` batch: fast-fail: false build-list: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 ignore-failure: true - identifier: build3 env: compute-type: ARM_LAMBDA_1GB - identifier: build4 env: fleet: fleet_name - identifier: build5 env: compute-type: GENERAL_LINUX_XLAGRE ``` ## `batch/build-matrix` Définit une *matrice de construction*. Une matrice de génération définit les tâches avec différentes configurations qui s'exécutent en parallèle. CodeBuild crée une version distincte pour chaque combinaison de configuration possible. Pour de plus amples informations, veuillez consulter [Construire une matrice](batch-build.md#batch_build_matrix). **statique** Les propriétés statiques s'appliquent à toutes les tâches de génération. **ignorer l'échec** Facultatif. Une valeur booléenne qui indique si l'échec de cette tâche de génération peut être ignoré. `false` La valeur par défaut. Si cette tâche de génération échoue, la génération par lots échouera. `true` Si cette tâche de génération échoue, la génération par lots peut toujours réussir. **env** Facultatif. L'environnement de construction prévaut pour toutes les tâches. **mode privilégié** Valeur booléenne qui indique s'il faut exécuter le démon Docker dans un conteneur Docker. Défini sur `true` uniquement si le projet de génération est utilisé pour créer des images Docker. À défaut, une génération qui tente d'interagir avec le démon Docker échoue. Le paramètre par défaut est `false`. **type** Identifiant du type d'environnement à utiliser pour la tâche. Voir **Type d'environnement** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) pour les valeurs possibles. **dynamique** Les propriétés dynamiques définissent la matrice de construction. **build spec** Facultatif. Tableau contenant le chemin et les noms des fichiers buildspec à utiliser pour ces tâches. Si ce paramètre n'est pas spécifié, le fichier buildspec actuel est utilisé. **env** Facultatif. L'environnement de génération prévaut pour ces tâches. **type de calcul** Tableau contenant les identificateurs des types de calcul à utiliser pour ces tâches. Voir **ComputeType** [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) in pour les valeurs possibles. **image** Tableau contenant les identifiants des images à utiliser pour ces tâches. Voir **Identifiant de l'image** dans [Images Docker fournies par CodeBuild](build-env-ref-available.md) pour les valeurs possibles. **variables** Un tableau qui contient les variables d'environnement qui seront présentes dans les environnements de génération pour ces tâches. Pour plus d’informations, consultez [env/variables](build-spec-ref.md#build-spec.env.variables). Voici un exemple d'entrée buildspec de matrice de construction : ``` batch: build-matrix: static: ignore-failure: false dynamic: buildspec: - matrix1.yml - matrix2.yml env: variables: MY_VAR: - VALUE1 - VALUE2 - VALUE3 ``` Pour de plus amples informations, veuillez consulter [Construire une matrice](batch-build.md#batch_build_matrix). ## `batch/build-fanout` Définit un *ventilateur de construction.* Un fanout de construction est utilisé pour définir une tâche divisée en plusieurs versions exécutées en parallèle. Pour de plus amples informations, veuillez consulter [Exécuter des tests parallèles dans des builds par lots](parallel-test.md). Cet élément contient une tâche de génération qui peut être divisée en plusieurs versions. La `build-fanout` section contient les propriétés suivantes. **parallélisme** Obligatoire. Le nombre de versions qui exécuteront des tests en parallèle. **ignorer l'échec** Facultatif. Une valeur booléenne qui indique si l'échec de l'une des tâches de génération du fanout peut être ignoré. Cette valeur d'**ignore-failure** sera appliquée à toutes les versions de fanout. **false** La valeur par défaut. Si une tâche de génération de fanout échoue, la génération par lots échouera. **true** Si une tâche de génération de fanout échoue, la génération par lots peut toujours réussir. Voici un exemple d'entrée buildspec de build fanout : ``` version: 0.2 batch: fast-fail: false build-fanout: parallelism: 5 ignore-failure: false phases: install: commands: - npm install build: commands: - mkdir -p test-results - cd test-results - | codebuild-tests-run \ --test-command 'npx jest --runInBand --coverage' \ --files-search "codebuild-glob-search '**/test/**/*.test.js'" \ --sharding-strategy 'equal-distribution' ``` Pour plus d’informations, consultez [Construire un ventilateur](batch-build.md#batch_build_fanout) et [Utilisez la `codebuild-tests-run` commande CLI](parallel-test-tests-run.md).