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 CodePipeline

Les informations suivantes peuvent vous aider à résoudre les problèmes courants dans AWS CodePipeline.

Erreur de pipeline : Un pipeline configuré avec AWS Elastic Beanstalk renvoie un message d'erreur : « Échec du déploiement. Le rôle fourni ne dispose pas d'autorisations suffisantes : Service : AmazonElasticLoadBalancing »

Problème : le rôle de service pour CodePipeline ne dispose pas d'autorisations suffisantes pour AWS Elastic Beanstalk, notamment, mais sans s'y limiter, certaines opérations dans Elastic Load Balancing. Le rôle de service pour CodePipeline a été mis à jour le 6 août 2015 pour résoudre ce problème. Les clients ayant créé leur rôle de service avant cette date doivent modifier la déclaration de stratégie de leur rôle de service afin d'ajouter les autorisations requises.

Correctifs possibles : la solution la plus simple consiste à modifier la déclaration de stratégie pour votre rôle de service, comme indiqué dans Ajout d'autorisations au rôle de service CodePipeline.

Après avoir appliqué la politique modifiée, suivez les étapes décrites pour Lancement manuel d'un pipeline réexécuter manuellement tous les pipelines utilisant Elastic Beanstalk.

Vous pouvez modifier les autorisations par différents moyens, selon vos besoins en termes de sécurité.

Erreur de déploiement : un pipeline configuré avec une action de AWS Elastic Beanstalk déploiement se bloque au lieu d'échouer si l'autorisation « DescribeEvents » est manquante

Problème : le rôle de service pour CodePipeline doit inclure l'"elasticbeanstalk:DescribeEvents"action pour tous les pipelines qui l'utilisent AWS Elastic Beanstalk. Sans cette autorisation, les actions de AWS Elastic Beanstalk déploiement se bloquent sans échouer ni indiquer d'erreur. Si cette action est absente de votre rôle de service, cela CodePipeline signifie qu'il n'est pas autorisé à exécuter la phase de déploiement du pipeline AWS Elastic Beanstalk en votre nom.

Correctifs possibles : passez en revue votre rôle CodePipeline de service. Si l'"elasticbeanstalk:DescribeEvents"action est absente, suivez les étapes ci-dessous pour l'ajouter Ajout d'autorisations au rôle de service CodePipeline à l'aide de la fonctionnalité Modifier la politique de la IAM console.

Après avoir appliqué la politique modifiée, suivez les étapes décrites pour Lancement manuel d'un pipeline réexécuter manuellement tous les pipelines utilisant Elastic Beanstalk.

Erreur de pipeline : une action source renvoie le message d'autorisations insuffisantes : « Impossible d'accéder au CodeCommit référentielrepository-name. Assurez-vous que le IAM rôle de pipeline dispose des autorisations suffisantes pour accéder au référentiel. »

Problème : le rôle de service pour CodePipeline ne dispose pas d'autorisations suffisantes CodeCommit et a probablement été créé avant l'ajout de la prise en charge de l'utilisation CodeCommit des référentiels le 18 avril 2016. Les clients ayant créé leur rôle de service avant cette date doivent modifier la déclaration de stratégie de leur rôle de service afin d'ajouter les autorisations requises.

Correctifs possibles : ajoutez les autorisations requises CodeCommit pour la politique CodePipeline de votre rôle de service. Pour de plus amples informations, veuillez consulter Ajout d'autorisations au rôle de service CodePipeline.

Erreur de pipeline : Une action Jenkins de génération ou de test s'exécute pendant une longue durée puis échoue, en raison d'informations d'identification ou d'autorisations insuffisantes

Problème : si le serveur Jenkins est installé sur une EC2 instance Amazon, l'instance n'a peut-être pas été créée avec un rôle d'instance disposant des autorisations requises pour CodePipeline. Si vous utilisez un IAM utilisateur sur un serveur Jenkins, une instance sur site ou une EC2 instance Amazon créée sans le IAM rôle requis, soit l'IAMutilisateur ne dispose pas des autorisations requises, soit le serveur Jenkins ne peut pas accéder à ces informations d'identification via le profil configuré sur le serveur.

Correctifs possibles : assurez-vous que le rôle ou IAM l'utilisateur de l'EC2instance Amazon est configuré avec la politique AWSCodePipelineCustomActionAccess gérée ou avec les autorisations équivalentes. Pour de plus amples informations, veuillez consulter AWS politiques gérées pour AWS CodePipeline.

Si vous utilisez un IAM utilisateur, assurez-vous que le AWS profil configuré sur l'instance utilise l'IAMutilisateur configuré avec les autorisations appropriées. Vous devrez peut-être fournir les informations IAM d'identification utilisateur que vous avez configurées pour l'intégration entre Jenkins et CodePipeline directement dans l'interface utilisateur de Jenkins. Ce n'est pas recommandé. Si vous devez le faire, assurez-vous que le serveur Jenkins est sécurisé et qu'il utilise à la HTTPS place deHTTP.

Erreur de pipeline : un pipeline créé dans une AWS région à l'aide d'un bucket créé dans une autre AWS région renvoie un InternalError « » avec le code « JobFailed »

Problème : le téléchargement d'un artefact stocké dans un compartiment Amazon S3 échouera si le pipeline et le compartiment sont créés dans des AWS régions différentes.

Corrections possibles : assurez-vous que le compartiment Amazon S3 dans lequel votre artefact est stocké se trouve dans la même AWS région que le pipeline que vous avez créé.

Erreur de déploiement : un ZIP fichier contenant un WAR fichier est déployé avec succès AWS Elastic Beanstalk, mais l'application URL signale une erreur 404 introuvable

Problème : un WAR fichier est déployé avec succès dans un AWS Elastic Beanstalk environnement, mais l'application URL renvoie une erreur 404 Not Found.

Corrections possibles : AWS Elastic Beanstalk permet de ZIP décompresser un fichier, mais pas un WAR fichier contenu dans un ZIP fichier. Au lieu de spécifier un WAR fichier dans votre buildspec.yml fichier, spécifiez un dossier contenant le contenu à déployer. Par exemple :

version: 0.2

phases:
  post_build:
    commands:
      - mvn package
      - mv target/my-web-app ./
artifacts:
  files:
    - my-web-app/**/*
 discard-paths: yes

Pour obtenir un exemple, consultez Exemple AWS Elastic Beanstalk pour CodeBuild.

Les noms des dossiers d'artefact du pipeline semblent tronqués

Problème : lorsque vous affichez les noms des artefacts du pipeline dans CodePipeline, ils semblent tronqués. Les noms peuvent sembler similaires ou ne plus contenir l'intégralité du nom du pipeline.

Explication : CodePipeline tronque les noms des artefacts pour garantir que le chemin complet d'Amazon S3 ne dépasse pas les limites de taille fixées par la politique lors de la génération d'informations d' CodePipeline identification temporaires pour les travailleurs.

Même si le nom de l'artefact semble tronqué, il est CodePipeline mappé vers le compartiment d'artefacts d'une manière qui n'est pas affectée par les artefacts dont le nom est tronqué. Le pipeline peut fonctionner normalement. Ce n'est pas un problème avec le dossier ou les artefacts. Les noms de pipeline sont limités à 100 caractères. Bien que le nom du dossier de l'artefact puisse apparaître raccourci, il est toujours unique à votre pipeline.

Ajoutez CodeBuild GitClone des autorisations pour les connexions à Bitbucket GitHub, GitHub Enterprise Server ou .com GitLab

Lorsque vous utilisez une AWS CodeStar connexion dans une action source et une CodeBuild action, l'artefact d'entrée peut être transmis au build de deux manières :

Pour ajouter des autorisations à votre politique CodeBuild de rôle de service, vous créez une politique gérée par le client que vous associez à votre rôle de CodeBuild service. Les étapes suivantes créent une politique dans laquelle l'UseConnectionautorisation est spécifiée dans le action champ et la connexion ARN est spécifiée dans le Resource champ.

Ajouter CodeBuild GitClone des autorisations pour les actions CodeCommit source

Lorsque votre pipeline comporte une action CodeCommit source, vous pouvez transmettre l'artefact d'entrée au build de deux manières :

Pour ajouter des autorisations à votre politique CodeBuild de rôle de service, vous créez une politique gérée par le client que vous associez à votre rôle de CodeBuild service. Les étapes suivantes créent une politique qui spécifie l'codecommit:GitPullautorisation dans le action champ.

<source artifact name>Erreur de pipeline : un déploiement avec l' CodeDeployToECSaction renvoie un message d'erreur : « Exception lors de la tentative de lecture du fichier d'artefact de définition de tâche depuis : »

Problème :

Le fichier de définition de tâche est un artefact obligatoire pour l'action de CodePipeline déploiement sur Amazon ECS via CodeDeploy (l'CodeDeployToECSaction). La ZIP taille maximale de l'artefact dans l'action de CodeDeployToECS déploiement est de 3 Mo. Le message d'erreur suivant est renvoyé lorsque le fichier est introuvable ou que la taille de l'artefact dépasse 3 Mo :

Exception while trying to read the task definition artifact file from: <nom artefact source> (Exception lors de la tentative de lecture du fichier d'artefact de définition de tâche à partir de : <nom artefact source>)

Corrections possibles : Assurez-vous que le fichier de définition de tâche est inclus en tant qu'artefact. Si le fichier existe déjà, assurez-vous que la taille compressée est inférieure à 3 Mo.

GitHub action source version 1 : la liste des référentiels montre les différents référentiels

Problème :

Après une autorisation réussie pour une action de GitHub version 1 dans la CodePipeline console, vous pouvez choisir parmi la liste de vos GitHub référentiels. Si la liste n'inclut pas les référentiels que vous vous attendiez à voir, vous pouvez résoudre les problèmes liés au compte utilisé pour l'autorisation.

Corrections possibles : La liste des référentiels fournie dans la CodePipeline console est basée sur l' GitHub organisation à laquelle appartient le compte autorisé. Vérifiez que le compte que vous utilisez pour l'autorisation GitHub est le compte associé à l' GitHub organisation dans laquelle votre référentiel est créé.

GitHub action source version 2 : impossible de terminer la connexion pour un référentiel

Problème :

Étant donné qu'une connexion à un GitHub référentiel utilise le AWS connecteur pour GitHub, vous devez disposer des autorisations du propriétaire de l'organisation ou des autorisations d'administrateur sur le référentiel pour créer la connexion.

Correctifs possibles : pour plus d'informations sur les niveaux d'autorisation pour un GitHub référentiel, consultez https://docs.github.com/en/free-pro-team@latest /github/ setting-up-and-managing -/organizations-and-teams-organization. permission-levels-for-an

Erreur Amazon S3 : le rôle de CodePipeline service < ARN > se voit refuser l'accès S3 pour le compartiment S3 < BucketName >

Problème :

En cours d'exécution, l' CodeCommit action CodePipeline vérifie que le bucket d'artefacts du pipeline existe. Si l'action n'est pas autorisée à être vérifiée, une AccessDenied erreur se produit dans Amazon S3 et le message d'erreur suivant s'affiche dans CodePipeline :

CodePipeline rôle de service « arn:aws:iam : :AccountID:role/service-role/RoleID« l'accès S3 est refusé pour le compartiment S3 »BucketName"

Les CloudTrail journaux de l'action enregistrent également l'AccessDeniederreur.

Corrections possibles : Procédez comme suit :

Après avoir appliqué la politique modifiée, suivez les étapes décrites Lancement manuel d'un pipeline pour réexécuter manuellement votre pipeline.

Les pipelines contenant un Amazon S3ECR, Amazon ou CodeCommit une source ne démarrent plus automatiquement

Problème :

Après avoir modifié les paramètres de configuration d'une action qui utilise des règles d'événements (EventBridgeou des CloudWatch événements) pour détecter les modifications, la console risque de ne pas détecter de modification lorsque les identificateurs de déclencheurs de la source sont similaires et comportent des caractères initiaux identiques. La nouvelle règle d'événement n'étant pas créée par la console, le pipeline ne démarre plus automatiquement.

Un exemple de modification mineure à la fin du nom du paramètre pour CodeCommit serait de changer le nom de votre CodeCommit branche MyTestBranch-1 enMyTestBranch-2. Comme la modification se trouve à la fin du nom de la branche, il est possible que la règle d'événement pour l'action source ne soit pas mise à jour ou ne crée pas de règle pour les nouveaux paramètres de source.

Cela s'applique aux actions source qui utilisent CWE des événements pour détecter les modifications, comme suit :

Correctifs possibles :

Effectuez l’une des actions suivantes :

Après avoir modifié la configuration de vos actions dans la console, acceptez les ressources de détection des modifications mises à jour créées par la console.

Erreur de connexion lors de la connexion à GitHub : « Un problème est survenu, assurez-vous que les cookies sont activés dans votre navigateur » ou « Le propriétaire d'une organisation doit installer l' GitHub application »

Problème :

Pour créer la connexion pour une action GitHub source dans CodePipeline, vous devez être le propriétaire de GitHub l'organisation. Pour les référentiels qui ne font pas partie d'une organisation, vous devez en être le propriétaire. Lorsqu'une connexion est créée par une personne autre que le propriétaire de l'organisation, une demande est créée pour le propriétaire de l'organisation et l'une des erreurs suivantes s'affiche :

Un problème est survenu, assurez-vous que les cookies sont activés dans votre navigateur

OU

Le propriétaire d'une organisation doit installer l' GitHub application

Correctifs possibles : pour les référentiels d'une GitHub organisation, le propriétaire de l'organisation doit créer la connexion au GitHub référentiel. Pour les référentiels qui ne font pas partie d'une organisation, vous devez être le propriétaire du référentiel.

Les pipelines dont le mode d'exécution est changé en PARALLEL mode QUEUED ou échouent lorsque la limite d'exécution est atteinte

Problème : le nombre maximum d'exécutions simultanées pour un pipeline en QUEUED mode est de 50 exécutions. Lorsque cette limite est atteinte, le pipeline échoue sans message d'état.

Corrections possibles : Lorsque vous modifiez la définition du pipeline pour le mode exécution, effectuez la modification séparément des autres actions de modification.

Pour plus d'informations sur QUEUED le mode PARALLEL d'exécution, consultezCodePipeline concepts .

Les pipelines en PARALLEL mode ont une définition de pipeline obsolète s'ils sont modifiés lors du passage au SUPERSEDED mode QUEUED ou

Problème : pour les pipelines en mode parallèle, lors de la modification du mode d'exécution du pipeline vers QUEUED ouSUPERSEDED, la définition du pipeline pour le PARALLEL mode ne sera pas mise à jour. La définition du pipeline mise à jour lorsque PARALLEL le mode de mise à jour n'est pas utilisé en QUEUED mode SUPERSEDED ou

Corrections possibles : pour les pipelines en mode parallèle, lorsque vous modifiez le mode d'exécution du pipeline pour QUEUED ouSUPERSEDED, évitez de mettre à jour la définition du pipeline en même temps.

Pour plus d'informations sur QUEUED le mode PARALLEL d'exécution, consultezCodePipeline concepts .

Les pipelines passés du PARALLEL mode afficheront un mode d'exécution précédent

Problème : pour les pipelines en PARALLEL mode, lorsque vous modifiez le mode d'exécution du pipeline en mode QUEUED ouSUPERSEDED, l'état du pipeline n'affichera pas l'état mis à jour sous la formePARALLEL. Si le pipeline est passé de PARALLEL à QUEUED ouSUPERSEDED, l'état du pipeline en QUEUED mode SUPERSEDED ou sera le dernier état connu dans l'un ou l'autre de ces modes. Si le pipeline n'a jamais été exécuté dans ce mode auparavant, l'état sera vide.

Corrections possibles : pour les pipelines en mode parallèle, lorsque vous modifiez le mode d'exécution du pipeline vers QUEUED ouSUPERSEDED, notez que l'affichage du mode d'exécution n'affichera pas l'PARALLELétat.

Pour plus d'informations sur QUEUED le mode PARALLEL d'exécution, consultezCodePipeline concepts .

Les pipelines avec des connexions qui utilisent le filtrage des déclencheurs par chemin de fichier peuvent ne pas démarrer lors de la création de la branche

Description : pour les pipelines dotés d'actions source qui utilisent des connexions, telles qu'une action BitBucket source, vous pouvez configurer un déclencheur avec une configuration Git qui vous permet de filtrer par chemin de fichier pour démarrer votre pipeline. Dans certains cas, pour les pipelines dont les déclencheurs sont filtrés sur les chemins de fichiers, le pipeline peut ne pas démarrer lorsqu'une branche avec un filtre de chemin de fichier est créée pour la première fois, car cela ne permet pas à la CodeConnections connexion de résoudre les fichiers modifiés. Lorsque la configuration Git du déclencheur est configurée pour filtrer les chemins de fichiers, le pipeline ne démarre pas lorsque la branche contenant le filtre vient d'être créée dans le référentiel source. Pour plus d'informations sur le filtrage des chemins de fichiers, consultezFiltrer les déclencheurs sur les requêtes push ou pull de code.

Résultat : Par exemple, les pipelines dotés CodePipeline d'un filtre de chemin de fichier sur une branche « B » ne seront pas déclenchés lors de la création de la branche « B ». S'il n'existe aucun filtre de chemin de fichier, le pipeline démarre quand même.

Les pipelines dont les connexions utilisent le filtrage des déclencheurs par chemin de fichier risquent de ne pas démarrer lorsque la limite de fichiers est atteinte

Description : pour les pipelines dotés d'actions source qui utilisent des connexions, telles qu'une action BitBucket source, vous pouvez configurer un déclencheur avec une configuration Git qui vous permet de filtrer par chemin de fichier pour démarrer votre pipeline. CodePipeline récupère jusqu'aux 100 premiers fichiers ; par conséquent, lorsque la configuration Git du déclencheur est configurée pour filtrer les chemins de fichiers, le pipeline peut ne pas démarrer s'il y a plus de 100 fichiers. Pour plus d'informations sur le filtrage des chemins de fichiers, consultezFiltrer les déclencheurs sur les requêtes push ou pull de code.

Résultat : par exemple, si un diff contient 150 fichiers, CodePipeline examine les 100 premiers fichiers (sans ordre particulier) pour vérifier qu'ils correspondent au filtre de chemin de fichier spécifié. Si le fichier correspondant au filtre de chemin de fichier ne figure pas parmi les 100 fichiers récupérés par CodePipeline, le pipeline ne sera pas invoqué.

CodeCommit ou les révisions de la source S3 en PARALLEL mode peuvent ne pas correspondre à EventBridge l'événement

Description : pour les exécutions de pipeline en PARALLEL mode, une exécution peut commencer par la modification la plus récente, telle que la validation du CodeCommit référentiel, qui peut être différente de la modification apportée à l' EventBridge événement. Dans certains cas, lorsqu'une fraction de seconde peut s'écouler entre les validations ou les balises d'image qui démarrent le pipeline, lorsqu'un autre commit ou une autre balise d'image a été envoyé CodePipeline (par exemple, l' CodeCommit action), le commit sera cloné à ce moment-là lors de la CodePipeline réception de l'HEADévénement et du démarrage de cette exécution.

Résultat : pour les pipelines en PARALLEL mode avec une source CodeCommit ou S3, quelle que soit la modification qui a déclenché l'exécution du pipeline, l'action source clonera toujours le pipeline HEAD au moment de son démarrage. Par exemple, pour un pipeline en PARALLEL mode, un commit est poussé, ce qui démarre le pipeline pour l'exécution 1, et la seconde exécution du pipeline utilise le second commit.

Besoin d'aide pour résoudre un autre problème ?

Essayez les ressources suivantes :