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ésolution des problèmes AWS CodeBuild Utilisez les informations de cette rubrique pour identifier, diagnostiquer et résoudre des problèmes. Pour savoir comment enregistrer et surveiller les CodeBuild versions afin de résoudre les problèmes, consultez[Journalisation et surveillance](logging-monitoring.md). **Topics** + [Apache Maven génère des artefacts de référence à partir du mauvais répertoire](#troubleshooting-maven-repos) + [Les commandes de génération s'exécutent en tant que racine par défaut](#troubleshooting-root-build-commands) + [Les builds peuvent échouer lorsque les noms de fichiers ne sont pas américains. Caractères anglais](#troubleshooting-utf-8) + [Les builds peuvent échouer lors de l'obtention de paramètres depuis Amazon EC2 Parameter Store](#troubleshooting-parameter-store) + [Impossible d'accéder au filtre de branche dans la CodeBuild console](#troubleshooting-webhook-filter) + [Impossible d'afficher la réussite ou l'échec de la génération](#no-status-when-build-triggered) + [État du build non communiqué au fournisseur source](#build-status-not-reported) + [Impossible de trouver et de sélectionner l'image de base de la plate-forme Windows Server Core 2019](#windows-image-not-available) + [Les commandes antérieures des fichiers buildspec ne sont pas reconnues par les commandes ultérieures](#troubleshooting-build-spec-commands) + [Erreur : accès refusé lors de la tentative de téléchargement du cache](#troubleshooting-dependency-caching) + [Erreur : « BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE » lors de l'utilisation d'une image de génération personnalisée](#troubleshooting-unable-to-pull-image) + [Erreur : « Le conteneur de construction a été trouvé mort avant de terminer la construction. Le conteneur de construction est mort parce qu'il n'y avait plus de mémoire ou parce que l'image Docker n'est pas prise en charge. ErrorCode: 500 pouces](#windows-server-core-version) + [Erreur : « Cannot connect to the Docker daemon » lors de l'exécution d'une génération](#troubleshooting-cannot-connect-to-docker-daemon) + [Erreur : « n'CodeBuild est pas autorisé à exécuter : sts : AssumeRole » lors de la création ou de la mise à jour d'un projet de construction](#troubleshooting-assume-role) + [Erreur : « Erreur lors de l'appel GetBucketAcl : soit le propriétaire du compartiment a changé, soit le rôle de service n'est plus autorisé à appeler s3 : GetBucketAcl »](#troubleshooting-calling-bucket-error) + [Erreur : « Failed to upload artifacts: Invalid arn » lors de l'exécution d'une génération](#troubleshooting-output-bucket-different-region) + [Erreur : « Git clone failed: Unable to access `'your-repository-URL'`: SSL certificate problem: Self signed certificate »](#troubleshooting-self-signed-certificate) + [Erreur : « The bucket you are attempting to access must be addressed using the specified endpoint... » lors de l'exécution d'une génération](#troubleshooting-input-bucket-different-region) + [Erreur : « This build image requires selecting at least one runtime version. »](#troubleshooting-build-must-specify-runtime) + [Erreur : « QUEUED: INSUFFICIENT\$1SUBNET » lorsqu'une génération dans une file d'attente échoue](#queued-insufficient-subnet-error) + [Erreur : « Impossible de télécharger le cache RequestError : échec de l'envoi de la demande en raison de : x509 : échec du chargement des racines du système et aucune racine n'a été fournie »](#troubleshooting-cache-image) + [Erreur : « Impossible de télécharger le certificat depuis S3. AccessDenied»](#troubleshooting-certificate-in-S3) + [Erreur : « Unable to locate credentials »](#troubleshooting-versions) + [RequestError erreur de temporisation lors de l'exécution CodeBuild sur un serveur proxy](#code-request-timeout-error) + [Le shell bourne (sh) doit exister dans les images de génération](#troubleshooting-sh-build-images) + [Avertissement : « Skipping install of runtimes. runtime version selection is not supported by this build image » lors de l'exécution d'une génération](#troubleshooting-skipping-all-runtimes-warning) + [Erreur : « Impossible de vérifier l' JobWorker identité » lors de l'ouverture de la CodeBuild console](#troubleshooting-unable-to-verify-jobworker) + [La construction n'a pas pu démarrer](#troubleshooting-build-failed-to-start) + [Accès aux GitHub métadonnées dans les versions mises en cache localement](#troubleshooting-github-metadata) + [AccessDenied: Le propriétaire du compartiment du groupe de rapports ne correspond pas au propriétaire du compartiment S3...](#troubleshooting-bucket-owner) + [Erreur : « Vos informations d'identification ne disposent pas d'une ou de plusieurs étendues de privilèges requises » lors de la création d'un CodeBuild projet avec CodeConnections](#troubleshooting-permission-bitbucket) + [Erreur : « Désolé, aucun terminal n'a été demandé, impossible d'obtenir des informations » lors de la compilation avec la commande d'installation d'Ubuntu](#troubleshooting-nvidia-container-toolkit) ## Apache Maven génère des artefacts de référence à partir du mauvais répertoire **Problème :** [Lorsque vous utilisez Maven avec un environnement de génération Java AWS CodeBuild fourni, Maven extrait les dépendances de build et de plugin du référentiel central sécurisé de Maven à l'adresse https://repo1.maven.org/maven2.](https://repo1.maven.org/maven2) Cela se produit même si le fichier `pom.xml` de votre projet de génération déclare explicitement d'autres emplacements à utiliser. **Cause possible :** les environnements de génération Java CodeBuild fournis incluent un fichier nommé `settings.xml` qui est préinstallé dans le répertoire de l'environnement de `/root/.m2` construction. Ce fichier `settings.xml` contient les déclarations suivantes qui demandent à Maven de toujours extraire les dépendances de génération et de plug-in du référentiel Maven central sécurisé situé à l'adresse [https://repo1.maven.org/maven2](https://repo1.maven.org/maven2). ``` securecentral securecentral central https://repo1.maven.org/maven2 true central https://repo1.maven.org/maven2 true ``` **Solution recommandée :** effectuez les opérations suivantes : 1. Ajoutez un fichier `settings.xml` à votre code source. 1. Dans ce fichier `settings.xml`, utilisez le format de fichier `settings.xml` précédent comme guide pour déclarer les référentiels desquels vous voulez que Maven extraie plutôt les dépendances de génération et de plug-in. 1. Au cours de la `install` phase de votre projet de construction, demandez CodeBuild de copier votre `settings.xml` fichier dans le `/root/.m2` répertoire de l'environnement de construction. Par exemple, examinez l'extrait de code suivant d'un fichier `buildspec.yml` qui illustre ce comportement. ``` version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml ``` ## Les commandes de génération s'exécutent en tant que racine par défaut **Problème :** AWS CodeBuild exécute vos commandes de compilation en tant qu'utilisateur root. Cela se produit même si votre Dockerfile d'image de génération associé définit l'instruction `USER` sur un autre utilisateur. **Cause :** Par défaut, CodeBuild exécute toutes les commandes de compilation en tant qu'utilisateur root. **Solution recommandée :** aucune. ## Les builds peuvent échouer lorsque les noms de fichiers ne sont pas américains. Caractères anglais **Problème :** lorsque vous exécutez une version qui utilise des fichiers dont le nom contient des informations non américaines Caractères anglais (par exemple, caractères chinois), la compilation échoue. **Cause possible :** les environnements de construction fournis par AWS CodeBuild ont leurs paramètres régionaux par défaut définis sur`POSIX`. `POSIX`les paramètres de localisation sont moins compatibles avec les noms de fichiers non américains CodeBuild et les noms de fichiers contenant des informations non américaines Caractères anglais et peuvent entraîner l'échec des versions associées. **Solution recommandée :** ajoutez les commandes suivantes à la section `pre_build` de votre fichier buildspec. Ces commandes font en sorte que l'environnement de construction utilise l'UTF-8 en anglais américain pour ses paramètres de localisation, ce qui est plus compatible avec CodeBuild les noms de fichiers contenant des informations non américaines. Caractères anglais. Pour les environnements de génération basés sur Ubuntu : ``` pre_build: commands: - export LC_ALL="en_US.UTF-8" - locale-gen en_US en_US.UTF-8 - dpkg-reconfigure -f noninteractive locales ``` Pour les environnements de création basés sur Amazon Linux : ``` pre_build: commands: - export LC_ALL="en_US.utf8" ``` ## Les builds peuvent échouer lors de l'obtention de paramètres depuis Amazon EC2 Parameter Store **Problème :** lorsqu'un build essaie d'obtenir la valeur d'un ou de plusieurs paramètres stockés dans le magasin de paramètres Amazon EC2, le build échoue dans la `DOWNLOAD_SOURCE` phase d'erreur. `Parameter does not exist` **Cause possible :** le rôle de service sur lequel repose le projet de génération n'est pas autorisé à appeler l'`ssm:GetParameters`action ou le projet de génération utilise un rôle de service généré par AWS CodeBuild et permettant d'appeler l'`ssm:GetParameters`action, mais les paramètres ont des noms qui ne commencent pas par`/CodeBuild/`. **Solutions recommandées :** + Si le rôle de service n'a pas été généré par CodeBuild, mettez à jour sa définition CodeBuild pour permettre d'appeler l'`ssm:GetParameters`action. Par exemple, la déclaration de stratégie suivante permet d'appeler l'action `ssm:GetParameters` pour obtenir des paramètres avec des noms commençant par `/CodeBuild/` : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/CodeBuild/*" } ] } ``` ------ + Si le rôle de service a été généré par CodeBuild, mettez à jour sa définition pour autoriser l'accès CodeBuild aux paramètres dans Amazon EC2 Parameter Store avec des noms autres que ceux commençant par. `/CodeBuild/` Par exemple, la déclaration de stratégie suivante permet d'appeler l'action `ssm:GetParameters` pour obtenir des paramètres avec le nom spécifié : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/PARAMETER_NAME" } ] } ``` ------ ## Impossible d'accéder au filtre de branche dans la CodeBuild console **Problème :** L'option de filtre de branche n'est pas disponible dans la console lorsque vous créez ou mettez à jour un AWS CodeBuild projet. **Cause possible :** l'option de filtre de branche est obsolète. Elle a été remplacée par les groupes de filtres webhook, qui fournissent davantage de contrôle sur les événements webhook qui déclenchent une nouvelle génération CodeBuild. **Solution recommandée :** pour migrer un filtre de branche créé avant l'introduction des filtres webhook, créez un groupes de filtres webhook avec un filtre `HEAD_REF` avec l'expression régulière `^refs/heads/branchName$`. Par exemple, si votre expression régulière de filtre de branche était `^branchName$`, l'expression régulière mise à jour que vous placez dans le filtre `HEAD_REF` est `^refs/heads/branchName$`. Pour plus d’informations, consultez [Événements du webhook Bitbucket](bitbucket-webhook.md) et [Filtrer les événements du GitHub webhook (console)](github-webhook-events-console.md). ## Impossible d'afficher la réussite ou l'échec de la génération **Problème :** vous ne pouvez pas consulter l'état de réussite ou d'échec lorqu'une génération a fait l'objet d'une nouvelle tentative. **Cause possible :** l'option qui permet de signaler le statut de votre génération n'est pas activée. **Solutions recommandées :** Activez **le statut de génération du rapport** lorsque vous créez ou mettez à jour un CodeBuild projet. Cette option indique à CodeBuild de renvoyer l'état lorsque vous déclenchez une génération. Pour plus d’informations, consultez [reportBuildStatus](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-reportBuildStatus) dans la *Référence d’API AWS CodeBuild *. ## État du build non communiqué au fournisseur source **Problème :** Après avoir autorisé le signalement de l'état du build à un fournisseur source, tel que GitHub Bitbucket, le statut du build n'est pas mis à jour. **Cause possible :** L'utilisateur associé au fournisseur de source n'a pas accès en écriture au dépôt. **Solutions recommandées :** Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). ## Impossible de trouver et de sélectionner l'image de base de la plate-forme Windows Server Core 2019 **Problème :** Impossible de trouver ou de sélectionner l'image de base de la plateforme Windows Server Core 2019. **Cause possible :** vous utilisez une AWS région qui ne prend pas en charge cette image. **Solutions recommandées :** utilisez l'une des AWS régions suivantes où l'image de base de la plateforme Windows Server Core 2019 est prise en charge : + USA Est (Virginie du Nord) + USA Est (Ohio) + USA Ouest (Oregon) + Europe (Irlande) ## Les commandes antérieures des fichiers buildspec ne sont pas reconnues par les commandes ultérieures **Problème :** les résultats d'une ou plusieurs commandes dans votre fichier buildspec ne sont pas reconnus par des commandes ultérieures dans le même fichier buildspec. Par exemple, une commande peut définir une variable d'environnement local, mais une commande exécutée ultérieurement ne parvient pas à obtenir la valeur de cette variable d'environnement local. **Cause possible :** dans le fichier buildspec version 0.1, AWS CodeBuild exécute chaque commande dans une instance distincte du shell par défaut dans l'environnement de génération. Cela signifie que chaque commande s'exécute isolée de toutes les autres commandes. Par défaut, vous ne pouvez pas exécuter une commande unique qui s'appuie sur l'état de commandes précédentes. **Solutions recommandées :** nous vous recommandons d'utiliser la version 0.2 de buildspec afin de résoudre ce problème. Si vous devez utiliser la version 0.1 de buildspec pour une raison quelconque, nous vous recommandons d'exploiter l'opérateur de chaînage de commande shell (par exemple, `&&` dans Linux) pour combiner plusieurs commandes en une seule. Ou incluez dans votre code source un script shell contenant plusieurs commandes, puis appelez ce script shell à partir d'une commande unique dans le fichier buildspec. Pour plus d’informations, consultez [Shells et commandes dans les environnements de génération](build-env-ref-cmd.md) et [Variables d'environnement dans les environnements de génération](build-env-ref-env-vars.md). ## Erreur : accès refusé lors de la tentative de téléchargement du cache **Problème :** lors de la tentative de téléchargement du cache sur un projet de génération dont le cache est activé, vous recevez l'erreur `Access denied`. **Causes possibles :** + vous venez de configurer la mise en cache dans le cadre de votre projet de génération. + Le cache a récemment été invalidé par le biais de l'API `InvalidateProjectCache`. + Le rôle de service utilisé par CodeBuild n'a aucune `s3:PutObject` autorisation `s3:GetObject` d'accès au compartiment S3 qui contient le cache. **Solution recommandée :** pour la première utilisation, il est normal de voir cela immédiatement après la mise à jour de la configuration du cache. Si cette erreur persiste, vérifiez si le rôle de service a les autorisations `s3:GetObject` et `s3:PutObject` pour le compartiment S3 qui contient le cache. Pour plus d'informations, consultez [Spécifier les autorisations S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html) dans le manuel *Amazon S3 Developer Guide*. ## Erreur : « BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE » lors de l'utilisation d'une image de génération personnalisée **Problème :** lorsque vous essayez d'exécuter une génération qui utilise une version de génération personnalisée, la génération échoue avec l'erreur `BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE`. ***Cause possible :** la taille globale non compressée de l'image de génération est supérieure à l'espace disque disponible du type de calcul de l'environnement de génération. Pour vérifier la taille de votre image de génération, utilisez Docker pour exécuter la commande `docker images REPOSITORY:TAG`. Pour obtenir une liste de l'espace disque disponible par type de calcul, reportez-vous à la section [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md).* **Solution recommandée :** utilisez un type de calcul plus important avec plus d'espace disque disponible, ou réduisez la taille de votre image de construction personnalisée. ***Cause possible :** AWS CodeBuild n'est pas autorisé à extraire l'image de compilation de votre Amazon Elastic Container Registry (Amazon ECR).* **Solution recommandée :** mettez à jour les autorisations de votre référentiel dans Amazon ECR afin de CodeBuild pouvoir intégrer votre image de construction personnalisée dans l'environnement de création. Pour de plus amples informations, veuillez consulter [Exemple Amazon ECR](sample-ecr.md). ***Cause possible :** L'image Amazon ECR que vous avez demandée n'est pas disponible dans la AWS région utilisée par votre AWS compte. * **Solution recommandée :** utilisez une image Amazon ECR située dans la même AWS région que celle utilisée par votre AWS compte. ***Cause possible :** vous utilisez un registre privé dans un VPC qui ne dispose pas d'un accès public à Internet. CodeBuild Impossible d'extraire une image d'une adresse IP privée dans un VPC. Pour de plus amples informations, veuillez consulter [Registre privé avec AWS Secrets Manager échantillon pour CodeBuild](sample-private-registry.md). * **Solution recommandée :** Si vous utilisez un registre privé dans un VPC, assurez-vous que celui-ci dispose d'un accès public à Internet. ***Cause possible :** si le message d'erreur contient **toomanyrequests**« » et que l'image provient de Docker Hub, cette erreur signifie que la limite d'attraction de Docker Hub a été atteinte. * **Solution recommandée :** utilisez un registre privé Docker Hub ou procurez-vous votre image auprès d'Amazon ECR. Pour plus d'informations sur l'utilisation d'un registre privé, consultez[Registre privé avec AWS Secrets Manager échantillon pour CodeBuild](sample-private-registry.md). Pour plus d'informations sur l'utilisation d'Amazon ECR, consultez[Exemple Amazon ECR pour CodeBuild](sample-ecr.md). ## Erreur : « Le conteneur de construction a été trouvé mort avant de terminer la construction. Le conteneur de construction est mort parce qu'il n'y avait plus de mémoire ou parce que l'image Docker n'est pas prise en charge. ErrorCode: 500 pouces **Problème :** Lorsque vous essayez d'utiliser un conteneur Microsoft Windows ou Linux dans AWS CodeBuild, cette erreur se produit pendant la phase de PROVISIONING. **Causes possibles :** + La version du système d'exploitation du conteneur n'est pas prise en charge par CodeBuild. + `HTTP_PROXY`, `HTTPS_PROXY`, ou les deux sont spécifiés dans le conteneur. **Solutions recommandées :** + Pour Microsoft Windows, utilisez un conteneur Windows avec un système d'exploitation de conteneur de version : microsoft/windowsservercore:10.0.x (for example, microsoft/windowsservercore 10.0.14393.2125). + Pour Linux, effacez les paramètres `HTTP_PROXY` et `HTTPS_PROXY` de votre image Docker, ou spécifiez la configuration du VPC dans votre projet. ## Erreur : « Cannot connect to the Docker daemon » lors de l'exécution d'une génération **Problème :** la génération échoue et vous recevez une erreur similaire à `Cannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running?` dans le journal de génération. **Cause possible :** vous n’exécutez pas la génération en mode privilégié. **Solution recommandée :** pour corriger cette erreur, vous devez activer le mode privilégié et mettre à jour votre buildspec en suivant les instructions suivantes. Pour exécuter votre build en mode privilégié, procédez comme suit : 1. Ouvrez la CodeBuild console à l'adresse [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/). 1. Dans le volet de navigation, choisissez **Build projects**, puis choisissez votre projet de build. 1. Dans **Modifier**, choisissez **Environnement**. 1. Sélectionnez **Additional configuration (Configuration supplémentaire)**. 1. Dans **Privileged**, sélectionnez **Activer cet indicateur si vous souhaitez créer des images Docker ou si vous souhaitez que vos builds bénéficient de privilèges élevés**. . 1. Choisissez **Mettre à jour l'environnement**. 1. Choisissez **Démarrer la génération** pour réessayer de créer votre génération. Vous devrez également démarrer le démon Docker dans votre conteneur. La `install` phase de votre buildspec peut ressembler à ceci. ``` phases: install: commands: - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 & - timeout 15 sh -c "until docker info; do echo .; sleep 1; done" ``` Pour plus d'informations sur le pilote de stockage OverlayFS référencé dans le fichier buildspec, consultez [Utilisation du pilote de stockage OverlayFS](https://docs.docker.com/storage/storagedriver/overlayfs-driver/) sur le site web Docker. **Note** Si le système d'exploitation de base est Alpine Linux, dans `buildspec.yml` ajoutez l'argument `-t` à `timeout` : ``` - timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done" ``` Pour en savoir plus sur la création et l'exécution d'une image Docker à l'aide AWS CodeBuild de. [Docker dans un exemple d'image personnalisé pour CodeBuild](sample-docker-custom-image.md) ## Erreur : « n'CodeBuild est pas autorisé à exécuter : sts : AssumeRole » lors de la création ou de la mise à jour d'un projet de construction **Problème :** lorsque vous essayez de créer ou de mettre à jour un projet de génération, vous recevez l'erreur `Code:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-name`. **Causes possibles :** + Le AWS Security Token Service (AWS STS) a été désactivé pour la AWS région dans laquelle vous essayez de créer ou de mettre à jour le projet de construction. + Le rôle AWS CodeBuild de service associé au projet de construction n'existe pas ou ne dispose pas d'autorisations suffisantes pour être approuvé CodeBuild. + Le boîtier AWS CodeBuild de rôle de service associé au projet de construction ne correspond pas au rôle IAM réel. **Solutions recommandées :** + Assurez-vous qu' AWS STS il est activé pour la AWS région dans laquelle vous essayez de créer ou de mettre à jour le projet de construction. Pour plus d'informations, consultez la section [Activation et désactivation AWS STS dans une AWS région](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le guide de l'*utilisateur IAM*. + Assurez-vous que le rôle CodeBuild de service cible existe dans votre AWS compte. Si vous n'utilisez pas la console, vérifiez que vous avez bien orthographié l'Amazon Resource Name (ARN) du rôle de service lorsque vous avez créé ou mis à jour le projet de génération. Notez que les rôles IAM distinguent les majuscules et minuscules. Vérifiez donc que le boîtier du rôle IAM est correct. + Assurez-vous que le rôle de CodeBuild service cible dispose d'autorisations suffisantes pour être fiable CodeBuild. Pour plus d'informations, consultez la déclaration de stratégie de relation d'approbation dans [CodeBuild Autoriser l'interaction avec d'autres AWS services](setting-up-service-role.md). ## Erreur : « Erreur lors de l'appel GetBucketAcl : soit le propriétaire du compartiment a changé, soit le rôle de service n'est plus autorisé à appeler s3 : GetBucketAcl » **Problème :** lorsque vous exécutez une génération, vous recevez une erreur sur une modification de la propriété d'un compartiment S3 et d'autorisations `GetBucketAcl`. **Cause possible :** vous avez ajouté les `s3:GetBucketLocation` autorisations `s3:GetBucketAcl` et à votre rôle IAM. Ces autorisations protègent le compartiment S3 de votre projet et garantissent que vous seul pouvez y accéder. Après l'ajout de ces autorisations, le propriétaire du compartiment S3 a changé. **Solution recommandée :** vérifiez que vous êtes propriétaire du compartiment S3, puis ajoutez de nouveau des autorisations à votre rôle IAM. Pour de plus amples informations, veuillez consulter [Accès sécurisé aux compartiments S3](auth-and-access-control-iam-access-control-identity-based.md#secure-s3-buckets). ## Erreur : « Failed to upload artifacts: Invalid arn » lors de l'exécution d'une génération **Problème :** lorsque vous exécutez une génération, la phase `UPLOAD_ARTIFACTS` de la génération échoue avec l'erreur `Failed to upload artifacts: Invalid arn`. **Cause possible :** votre compartiment de sortie S3 (le compartiment AWS CodeBuild dans lequel sont stockés les résultats de la génération) se trouve dans une AWS région différente de celle du projet de CodeBuild construction. **Solution recommandée :** mettez à jour les paramètres du projet de génération pour qu'ils pointent vers un compartiment de sortie situé dans la même AWS région que le projet de construction. ## Erreur : « Git clone failed: Unable to access `'your-repository-URL'`: SSL certificate problem: Self signed certificate » **Problème :** lorsque vous essayez d'exécuter un projet de génération, la génération échoue avec cette erreur. **Cause possible :** Votre référentiel source possède un certificat auto-signé, mais vous n'avez pas choisi d'installer le certificat depuis votre compartiment S3 dans le cadre de votre projet de génération. **Solutions recommandées :** + modifiez votre projet. Pour **Certificat**, choisissez **Installer le certificat à partir de votre compartiment S3**. Pour **Compartiment de certificat**, choisissez le compartiment S3 dans lequel votre certificat SSL est stocké. Pour **Object key of certificate (Clé d'objet de certificat)**, tapez le nom de la clé d'objet S3. + modifiez votre projet. Sélectionnez **SSL non sécurisé** pour ignorer les avertissements SSL lors de la connexion au référentiel de votre projet GitHub Enterprise Server. **Note** Nous vous recommandons de n'utiliser **Insecure SSL** que pour les tests. Cette option ne doit pas être utilisée dans un environnement de production. ## Erreur : « The bucket you are attempting to access must be addressed using the specified endpoint... » lors de l'exécution d'une génération **Problème :** lorsque vous exécutez une génération, la phase `DOWNLOAD_SOURCE` de la génération échoue avec l'erreur `The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint`. **Cause possible :** votre code source prédéfini est stocké dans un compartiment S3, et ce compartiment se trouve dans une AWS région différente de celle du projet de AWS CodeBuild génération. **Solution recommandée :** mettez à jour les paramètres du projet de génération pour pointer vers un compartiment qui contient votre code source précompilé. Assurez-vous que le bucket se trouve dans la même AWS région que le projet de construction. ## Erreur : « This build image requires selecting at least one runtime version. » **Problème :** lorsque vous exécutez une génération, la phase `DOWNLOAD_SOURCE` de la génération échoue avec l'erreur `YAML_FILE_ERROR: This build image requires selecting at least one runtime version`. **Cause possible :** votre build utilise la version 1.0 ou ultérieure de l'image standard Amazon Linux 2 (AL2), ou la version 2.0 ou ultérieure de l'image standard Ubuntu, et aucun environnement d'exécution n'est spécifié dans le fichier buildspec. **Solution recommandée :** Si vous utilisez l'image `aws/codebuild/standard:2.0` CodeBuild gérée, vous devez spécifier une version d'exécution dans la `runtime-versions` section du fichier buildspec. Par exemple, vous pouvez utiliser le fichier buildspec suivant pour un projet qui utilise PHP : ``` version: 0.2 phases: install: runtime-versions: php: 7.3 build: commands: - php --version artifacts: files: - README.md ``` **Note** 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`. Pour de plus amples informations, veuillez consulter [Specify runtime versions in the buildspec file](build-spec-ref.md#runtime-versions-buildspec-file). ## Erreur : « QUEUED: INSUFFICIENT\$1SUBNET » lorsqu'une génération dans une file d'attente échoue **Problème :** une génération dans une file d'attente échoue avec une erreur similaire à `QUEUED: INSUFFICIENT_SUBNET`. **Causes possibles :** Le bloc IPv4 CIDR spécifié pour votre VPC utilise une adresse IP réservée. Les quatre premières adresses IP et la dernière adresse IP du bloc d'adresse CIDR de chaque sous-réseau ne sont pas disponibles pour utilisation, et ne peuvent donc pas être affectées à une instance. Par exemple, dans un sous-réseau avec le bloc d'adresse CIDR `10.0.0.0/24`, les cinq adresses IP suivantes sont réservées : + `10.0.0.0:` : Adresse réseau. + `10.0.0.1`: Réservé par AWS pour le routeur VPC. + `10.0.0.2`: Réservé par AWS. L'adresse IP du serveur DNS est toujours la base de la plage d'adresses du réseau VPC, plus deux ; cependant, nous réservons également la base de chaque sous-réseau, plus deux. Dans le VPCs cas de plusieurs blocs d'adresse CIDR, l'adresse IP du serveur DNS se trouve dans le CIDR principal. Pour plus d’informations, consultez [Serveur Amazon DNS](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS) dans le *Guide de l’utilisateur Amazon VPC*. + `10.0.0.3`: Réservé par AWS pour une utilisation future. + `10.0.0.255` : Adresse de diffusion réseau. Nous ne prenons pas en charge la diffusion dans un VPC. Cette adresse est réservée. **Solutions recommandées :** vérifiez si votre VPC utilise une adresse IP réservée. Remplacez toute adresse IP réservée par une adresse non réservée. Pour plus d'informations, consultez [Dimensionnement des VPC et des sous-réseaux](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing) dans le *Amazon VPC Guide de l'utilisateur*. ## Erreur : « Impossible de télécharger le cache RequestError : échec de l'envoi de la demande en raison de : x509 : échec du chargement des racines du système et aucune racine n'a été fournie » **Problème :** lorsque vous essayez d'exécuter un projet de génération, la génération échoue avec cette erreur. **Cause possible :** vous avez configuré la mise en cache dans le cadre de votre projet de génération et vous utilisez une ancienne image Docker qui inclut un certificat racine expiré. **Solution recommandée :** mettez à jour l'image Docker utilisée dans votre AWS CodeBuild projet. Pour de plus amples informations, veuillez consulter [Images Docker fournies par CodeBuild](build-env-ref-available.md). ## Erreur : « Impossible de télécharger le certificat depuis S3. AccessDenied» **Problème :** lorsque vous essayez d'exécuter un projet de génération, la génération échoue avec cette erreur. **Causes possibles :** + vous avez choisi le mauvais compartiment S3 pour votre certificat. + Vous avez entré la mauvaise clé d'objet pour votre certificat. **Solutions recommandées :** + modifiez votre projet. Pour **Compartiment de certificat**, choisissez le compartiment S3 dans lequel votre certificat SSL est stocké. + modifiez votre projet. Pour **Object key of certificate (Clé d'objet de certificat)**, tapez le nom de la clé d'objet S3. ## Erreur : « Unable to locate credentials » **Problème :** Lorsque vous essayez d'exécuter le AWS CLI, d'utiliser un AWS SDK ou d'appeler un autre composant similaire dans le cadre d'une compilation, vous obtenez des erreurs de génération directement liées au AWS CLI AWS SDK ou au composant. Par exemple, vous pouvez obtenir l'erreur de génération `Unable to locate credentials`. **Causes possibles :** + La version du AWS CLI AWS SDK ou du composant de l'environnement de construction est incompatible avec AWS CodeBuild. + Vous exécutez un conteneur Docker dans un environnement de génération qui utilise Docker, et le conteneur n'a pas accès aux AWS informations d'identification par défaut. **Solutions recommandées :** + Assurez-vous que votre environnement de génération dispose de la version suivante ou supérieure du AWS CLI AWS SDK ou du composant. + AWS CLI : 1.10.47 + AWS SDK pour C\$1\$1 : 0.2.19 + AWS SDK pour Go : 1.2.5 + AWS SDK pour Java : 1.11.16 + AWS SDK pour JavaScript : 2.4.7 + AWS SDK pour PHP : 3.18.28 + AWS SDK pour Python (Boto3) : 1.4.0 + AWS SDK pour Ruby : 2.3.22 + Botocore : 1.4.37 + CoreCLR : 3.2.6-beta + Node.js : 2.4.7 + Si vous devez exécuter un conteneur Docker dans un environnement de génération et que le conteneur nécessite des AWS informations d'identification, vous devez transmettre les informations d'identification de l'environnement de génération au conteneur. Dans votre fichier buildspec, incluez une commande Docker `run` telle que la suivante. Cet exemple utilise la commande `aws s3 ls` pour répertorier les compartiments S3 disponibles. L'`-e`option passe par les variables d'environnement requises pour que votre conteneur puisse accéder aux AWS informations d'identification. ``` docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls ``` + Si vous créez une image Docker et que la compilation nécessite des AWS informations d'identification (par exemple, pour télécharger un fichier depuis Amazon S3), vous devez transmettre les informations d'identification de l'environnement de génération au processus de génération Docker comme suit. 1. Dans votre Dockerfile de code source pour l'image Docker, spécifiez les instructions `ARG` suivantes. ``` ARG AWS_DEFAULT_REGION ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ``` 1. Dans votre fichier buildspec, incluez une commande Docker `build` telle que la suivante. Les `--build-arg` options définissent les variables d'environnement requises pour que votre processus de création de Docker puisse accéder aux AWS informations d'identification. ``` docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag . ``` ## RequestError erreur de temporisation lors de l'exécution CodeBuild sur un serveur proxy **Problème :** Vous recevez une erreur `RequestError` similaire à l'une des erreurs suivantes : + `RequestError: send request failed caused by: Post https://logs..amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout`de CloudWatch Logs. + `Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refused`depuis Amazon S3. **Causes possibles :** + `ssl-bump` n'est pas configuré correctement. + La stratégie de sécurité de votre organisation ne vous permet pas d'utiliser `ssl_bump`. + Votre fichier buildspec n'a pas de paramètres proxy spécifiés à l'aide d'un élément `proxy`. **Solutions recommandées :** + assurez-vous que `ssl-bump` est configuré correctement. Si vous utilisez Squid pour votre serveur proxy, consultez [Configuration de Squid en tant que serveur proxy explicite](run-codebuild-in-explicit-proxy-server.md#use-proxy-server-explicit-squid-configure). + Pour utiliser des points de terminaison privés pour Amazon S3 et CloudWatch Logs, procédez comme suit : 1. Dans la table de routage de votre sous-réseau privé, supprimez la règle que vous avez ajoutée qui achemine le trafic destiné à Internet vers votre serveur proxy. Pour plus d'informations, consultez [la section Création d'un sous-réseau dans votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet) dans le guide de l'utilisateur *Amazon VPC.* 1. Créez un point de terminaison Amazon S3 et un point de terminaison CloudWatch Logs privés et associez-les au sous-réseau privé de votre Amazon VPC. Pour plus d'informations, consultez la section [Services de point de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) dans le guide de l'*utilisateur Amazon VPC*. 1. Vérifiez que l'**option Activer le nom DNS privé** dans votre Amazon VPC est sélectionnée. Pour plus d’informations, consultez [Création d’un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) dans le *Guide de l’utilisateur Amazon VPC*. + Si vous n'utilisez pas `ssl-bump` pour un serveur proxy explicite, ajoutez une configuration proxy à votre fichier buildspec à l'aide d'un élément `proxy`. Pour plus d’informations, consultez [Exécuter CodeBuild sur un serveur proxy explicite](run-codebuild-in-explicit-proxy-server.md) et [Syntaxe d'un fichier buildspec](build-spec-ref.md#build-spec-ref-syntax). ``` version: 0.2 proxy: upload-artifacts: yes logs: yes phases: build: commands: ``` ## Le shell bourne (sh) doit exister dans les images de génération **Problème :** vous utilisez une image de build qui n'est pas fournie par AWS CodeBuild, et vos builds échouent avec le message`Build container found dead before completing the build`. **Cause possible :** Le shell Bourne (`sh`) n'est pas inclus dans votre image de construction. CodeBuild doit `sh` exécuter des commandes et des scripts de construction. **Solution recommandée :** S'il `sh` n'est pas présent dans votre image de construction, assurez-vous de l'inclure avant de commencer toute autre génération utilisant votre image. (inclut CodeBuild déjà des images `sh` dans sa version.) ## Avertissement : « Skipping install of runtimes. runtime version selection is not supported by this build image » lors de l'exécution d'une génération **Problème :** lorsque vous exécutez une génération, le journal de génération contient cet avertissement. **Cause possible :** votre build n'utilise pas la version 1.0 ou ultérieure de l'image standard Amazon Linux 2 (AL2), ni la version 2.0 ou ultérieure de l'image standard Ubuntu, et un environnement d'exécution est spécifié dans une `runtime-versions` section de votre fichier buildspec. **Solution recommandée :** vérifiez que votre fichier buildspec ne contient pas une section `runtime-versions`. La `runtime-versions` section n'est obligatoire que si vous utilisez l'image standard Amazon Linux 2 (AL2) ou version ultérieure ou l'image standard Ubuntu version 2.0 ou ultérieure. ## Erreur : « Impossible de vérifier l' JobWorker identité » lors de l'ouverture de la CodeBuild console **Problème :** Lorsque vous ouvrez la CodeBuild console, le message d'erreur « Impossible de vérifier l' JobWorker identité » s'affiche. **Cause possible :** le rôle IAM utilisé pour accéder à la console possède une balise utilisée `jobId` comme clé. Cette clé de balise est réservée CodeBuild et provoquera cette erreur si elle est présente. **Solution recommandée :** modifiez toutes les balises de rôle IAM personnalisées contenant la clé `jobId` pour qu'elles aient une clé différente, par exemple`jobIdentifier`. ## La construction n'a pas pu démarrer **Problème :** Lorsque vous démarrez une compilation, vous recevez un message d'erreur indiquant que la **compilation n'a pas pu démarrer**. **Cause possible :** le nombre de versions simultanées a été atteint. **Solutions recommandées :** attendez que les autres versions soient terminées ou augmentez la limite de génération simultanée pour le projet, puis recommencez la génération. Pour de plus amples informations, veuillez consulter [Configuration du projet](create-project.md#create-project-console-project-config). ## Accès aux GitHub métadonnées dans les versions mises en cache localement **Problème :** Dans certains cas, le répertoire .git d'une version mise en cache est un fichier texte et non un répertoire. **Causes possibles :** lorsque la mise en cache des sources locales est activée pour une compilation, CodeBuild crée un gitlink pour le `.git` répertoire. Cela signifie que le `.git` répertoire est en fait un fichier texte contenant le chemin d'accès au répertoire. **Solutions recommandées :** Dans tous les cas, utilisez la commande suivante pour obtenir le répertoire de métadonnées Git. Cette commande fonctionnera quel que soit le format de `.git` : ``` git rev-parse --git-dir ``` ## AccessDenied: Le propriétaire du compartiment du groupe de rapports ne correspond pas au propriétaire du compartiment S3... **Problème :** lors du téléchargement de données de test dans un compartiment Amazon S3, CodeBuild il est impossible d'écrire les données de test dans le compartiment. **Causes possibles :** + Le compte spécifié pour le propriétaire du compartiment du groupe de rapports ne correspond pas au propriétaire du compartiment Amazon S3. + Le rôle de service ne dispose pas d'un accès en écriture au compartiment. **Solutions recommandées :** + Modifiez le propriétaire du compartiment du groupe de rapports pour qu'il corresponde au propriétaire du compartiment Amazon S3. + Modifiez le rôle de service pour autoriser l'accès en écriture au compartiment Amazon S3. ## Erreur : « Vos informations d'identification ne disposent pas d'une ou de plusieurs étendues de privilèges requises » lors de la création d'un CodeBuild projet avec CodeConnections **Problème :** lorsque vous créez un CodeBuild projet avec CodeConnections, vous n'êtes pas autorisé à installer un webhook Bitbucket. **Causes possibles :** + La nouvelle étendue d'autorisation n'a peut-être pas été acceptée dans votre compte Bitbucket. **Solutions recommandées :** + Pour accepter la nouvelle autorisation, vous devez avoir reçu un e-mail avec un objet intitulé **Action requise - Scopes for AWS CodeStar have changed** envoyé par Bitbucket,. `notifications-noreply@bitbucket.org` L'e-mail contient un lien pour autoriser le webhook à accéder à votre installation d'application CodeConnections Bitbucket existante. + Si vous ne trouvez pas l'e-mail, vous pouvez accorder l'autorisation en accédant ou `https://bitbucket.org/site/addons/reauthorize?addon_key=aws-codestar` en sélectionnant l'espace de travail auquel vous souhaitez autoriser le webhook. `https://bitbucket.org/site/addons/reauthorize?account=&addon_key=aws-codestar` ![\[Accordez au webhook l'autorisation d'accéder à votre espace de travail.\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/images/bitbucket-csc.png) ## Erreur : « Désolé, aucun terminal n'a été demandé, impossible d'obtenir des informations » lors de la compilation avec la commande d'installation d'Ubuntu **Problème :** si vous utilisez des versions privilégiées du conteneur GPU, vous êtes peut-être en train d'installer le NVIDIA Container Toolkit en suivant cette [procédure](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html#installing-with-apt). Dans la dernière version CodeBuild d'image, CodeBuild préinstalle et configure docker `nvidia-container-toolkit` avec l'image la `amazonlinux` plus récente et organisée. `ubuntu` Si vous suivez cette procédure, les builds utilisant la commande d'installation d'Ubuntu échoueront avec l'erreur suivante : ``` Running command curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor --no-tty -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg gpg: Sorry, no terminal at all requested - can't get input curl: (23) Failed writing body ``` **Causes possibles :** La clé GPG existe déjà au même endroit. **Solutions recommandées :** `nvidia-container-toolkit` Il est déjà installé dans l'image. Si cette erreur s'affiche, vous pouvez ignorer le processus d'installation et de redémarrage de docker dans votre buildspec.