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, consultezJournalisation et surveillance.

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 des builds et des plugins depuis le référentiel central sécurisé de Maven à l'adresse 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.

<settings>
  <activeProfiles>
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

Solution recommandée : effectuez les opérations suivantes :

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 les noms de fichiers contiennent 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 surPOSIX. POSIXles 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'anglais américain UTF -8 pour ses paramètres de localisation, ce qui est plus compatible avec CodeBuild les noms de fichiers contenant des caractères non américains. Personnages en 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 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 Amazon EC2 Parameter Store, le build échoue pendant la DOWNLOAD_SOURCE phase d'erreurParameter 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:GetParametersaction 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:GetParametersaction, mais les paramètres ont des noms qui ne commencent pas par/CodeBuild/.

Solutions recommandées :

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. Il a été remplacé par des groupes de filtres Webhook, qui permettent de mieux contrôler les événements Webhook qui déclenchent une nouvelle intégration. 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 et Filtrer les événements du GitHub webhook (console).

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 signaler l'état lorsque vous déclenchez une compilation. Pour plus d'informations, reportez-vous reportBuildStatusà la section AWS CodeBuild APIRéférence.

L'état du build n'a pas été 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.

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 :

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 et Variables d'environnement dans les environnements de génération.

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 :

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 dans le manuel Amazon S3 Developer Guide.

Erreur : « BUILD _ _ CONTAINER UNABLE _TO_ PULL _ IMAGE » lors de l'utilisation d'une image de construction 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.

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 PROVISIONING phase.

Causes possibles :

Solutions recommandées :

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 :

Vous devrez également démarrer le démon Docker à l'intérieur de 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 sur le site web Docker.

- 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

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 :

Solutions recommandées :

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 IAM rôle. 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 IAM rôle. Pour de plus amples informations, veuillez consulter Accès sécurisé aux compartiments S3.

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 : « Échec du clonage Git : accès impossible 'your-repository-URL' : problème de SSL certificat : certificat auto-signé »

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 :

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

Pour de plus amples informations, veuillez consulter Specify runtime versions in the buildspec file.

Erreur : « QUEUED : INSUFFICIENT _ SUBNET » en cas d'échec d'une compilation dans une file d'attente de génération

Problème : une génération dans une file d'attente échoue avec une erreur similaire à QUEUED: INSUFFICIENT_SUBNET.

Causes possibles : Le IPv4 CIDR blocage spécifié pour vous VPC utilise une adresse IP réservée. Les quatre premières adresses IP et la dernière adresse IP de chaque CIDR bloc de sous-réseau ne sont pas disponibles et ne peuvent pas être attribuées à une instance. Par exemple, dans un sous-réseau avec CIDR bloc10.0.0.0/24, les cinq adresses IP suivantes sont réservées :

Solutions recommandées : Vérifiez si vous VPC utilisez 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 la section relative au dimensionnement VPC des sous-réseaux dans le guide de VPCl'utilisateur Amazon.

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.

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 :

Solutions recommandées :

Erreur : « Unable to locate credentials »

Problème : Lorsque vous essayez d'exécuter AWS CLI AWS SDK, d'utiliser un ou d'appeler un autre composant similaire dans le cadre d'une génération, vous obtenez des erreurs de génération directement liées au AWS CLI composant ou. AWS SDK Par exemple, vous pouvez obtenir l'erreur de génération Unable to locate credentials.

Causes possibles :

Solutions recommandées :

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 :

Causes possibles :

Solutions recommandées :

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 messageBuild 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 IAM rôle utilisé pour accéder à la console possède une balise dont jobId la clé est la 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 IAM rôle personnalisées contenant la clé jobId pour qu'elles aient une clé différente, telle quejobIdentifier.

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.

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 pour le 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 :

Solutions recommandées :