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 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, vous CodePipeline n'êtes 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'action "elasticbeanstalk:DescribeEvents" n'en fait pas partie, utilisez la procédure indiquée dans Ajout d'autorisations au rôle de service CodePipeline pour l'ajouter à l'aide de la fonction Edit Policy (Modifier la stratégie) dans la console IAM.

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 rôle IAM du 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 plus d’informations, consultez 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 instance Amazon EC2, 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 utilisateur IAM sur un serveur Jenkins, une instance sur site ou une instance Amazon EC2 créée sans le rôle IAM requis, soit l'utilisateur IAM 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 d'instance Amazon EC2 ou l'utilisateur IAM est configuré avec la politique AWSCodePipelineCustomActionAccess gérée ou avec les autorisations équivalentes. Pour plus d’informations, consultez AWS politiques gérées pour AWS CodePipeline.

Si vous utilisez un utilisateur IAM, assurez-vous que le AWS profil configuré sur l'instance utilise l'utilisateur IAM configuré avec les autorisations appropriées. Vous devrez peut-être fournir les informations d'identification utilisateur IAM 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 utilise le protocole HTTPS au lieu de HTTP.

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 fichier ZIP contenant un fichier WAR a été déployé avec succès AWS Elastic Beanstalk, mais l'URL de l'application signale une erreur 404 introuvable

Problème : un fichier WAR est déployé avec succès dans un environnement AWS Elastic Beanstalk , mais l'URL de l'application renvoie une erreur « 404 - Non trouvé ».

Corrections AWS Elastic Beanstalk possibles : possibilité de décompresser un fichier ZIP, mais pas un fichier WAR contenu dans un fichier ZIP. Au lieu de spécifier un fichier WAR dans votre fichier buildspec.yml, 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 :

• Par défaut : l'action source produit un fichier zip contenant le code à CodeBuild télécharger.

• Clone Git : le code source peut être téléchargé directement dans l'environnement de génération.

  Le mode Clone Git vous permet d'interagir avec le code source en tant que référentiel Git fonctionnel. Pour utiliser ce mode, vous devez autoriser votre CodeBuild environnement à utiliser la connexion.

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 stratégie dans laquelle l'autorisation UseConnection est spécifiée dans le champ action et l'ARN de connexion est spécifié dans le champ Resource.

Pour utiliser la console pour ajouter les UseConnection autorisations

1. Pour trouver l'ARN de connexion de votre pipeline, ouvrez votre pipeline et cliquez sur l'icône (i) de votre action source. Vous ajoutez l'ARN de connexion à votre politique CodeBuild de rôle de service.

   Voici un exemple d'ARN de connexion :

   arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095

2. Pour trouver votre rôle CodeBuild de service, ouvrez le projet de construction utilisé dans votre pipeline et accédez à l'onglet Détails de la construction.

3. Sélectionnez le lien Rôle de service. Cela ouvre la console IAM où vous pouvez ajouter une nouvelle stratégie qui accorde l'accès à votre connexion.

4. Dans la console IAM, choisissez Attach policies (Attacher des stratégies), puis Créer une stratégie.

   Utilisez l'exemple de modèle de stratégie suivant. Ajoutez votre ARN de connexion dans le champ Resource, comme illustré dans cet exemple :

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "codestar-connections:UseConnection",
               "Resource": "insert connection ARN here"
           }
       ]
   }

   Sous l'onglet JSON, collez votre stratégie.

5. Choisissez Examiner une politique. Entrez un nom pour la stratégie (par exemple, connection-permissions), puis choisissez Créer une stratégie.

6. Revenez à la page où vous attachiez les autorisations, actualisez la liste des stratégies et sélectionnez la stratégie que vous venez de créer. Choisissez Attach Policies (Attacher des politiques).

   

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 :

• Par défaut — L'action source produit un fichier zip contenant le code à CodeBuild télécharger.

• Clone complet — Le code source peut être directement téléchargé dans l'environnement de construction.

  L'option Full clone vous permet d'interagir avec le code source en tant que dépôt Git fonctionnel. Pour utiliser ce mode, vous devez ajouter des autorisations permettant à votre CodeBuild environnement d'extraire des données de votre référentiel.

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.

Pour utiliser la console pour ajouter les GitPull autorisations

1. Pour trouver votre rôle CodeBuild de service, ouvrez le projet de construction utilisé dans votre pipeline et accédez à l'onglet Détails de la construction.

2. Sélectionnez le lien Rôle de service. Cela ouvre la console IAM dans laquelle vous pouvez ajouter une nouvelle politique qui accorde l'accès à votre référentiel.

3. Dans la console IAM, choisissez Attach policies (Attacher des stratégies), puis Créer une stratégie.

4. Dans l'onglet JSON, collez l'exemple de politique suivant.

   {
       "Action": [
           "codecommit:GitPull"
       ],
       "Resource": "*",
       "Effect": "Allow"
   },

5. Choisissez Examiner une politique. Entrez un nom pour la stratégie (par exemple, codecommit-gitpull), puis choisissez Créer une stratégie.

6. Revenez à la page où vous attachiez les autorisations, actualisez la liste des stratégies et sélectionnez la stratégie que vous venez de créer. Choisissez Attach Policies (Attacher des politiques).

<source artifact name>Erreur de pipeline : un déploiement avec l'action CodeDeployTo ECS 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 taille maximale du ZIP d'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.

Corrections 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 le rôle de service « arn:aws:iam : : accountID:role/service-role/ RoleID » se voit refuser l'accès S3 pour le compartiment S3. « » BucketName

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

Corrections possibles : Procédez comme suit :

• Pour la politique associée à votre rôle CodePipeline de service, s3:ListBucket ajoutez-la à la liste des actions de votre stratégie. Pour obtenir des instructions sur la consultation de votre politique en matière de rôles de service, consultezAfficher l'ARN du pipeline et l'ARN du rôle de service (console). Modifiez la déclaration de politique relative à votre rôle de service, comme indiqué dansAjout d'autorisations au rôle de service CodePipeline.

• Pour la politique basée sur les ressources attachée au compartiment d'artefacts Amazon S3 pour votre pipeline, également appelée politique de compartiment d'artefacts, ajoutez une déclaration autorisant l'utilisation de l's3:ListBucketautorisation par votre rôle de service. CodePipeline

  Pour ajouter votre politique au compartiment d'artefacts

  1. Suivez les étapes décrites Afficher l'ARN du pipeline et l'ARN du rôle de service (console) pour choisir votre compartiment d'artefacts sur la page des paramètres du pipeline, puis consultez-le dans la console Amazon S3.

  2. Choisissez Permissions.

  3. Sous Politique de compartiment, choisissez Modifier.

  4. Dans le champ de texte Politique, entrez une nouvelle politique de compartiment ou modifiez la politique existante comme indiqué dans l'exemple suivant. La politique du bucket étant un fichier JSON, vous devez saisir un JSON valide.

     L'exemple suivant montre une déclaration de politique de compartiment pour un compartiment d'artefacts où l'ID de rôle d'exemple pour le rôle de service est AROAEXAMPLEID.

     {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::BucketName",
         "Condition": {
             "StringLike": {
                 "aws:userid": "AROAEXAMPLEID:*"
             }
         }
     }

     L'exemple suivant montre la même déclaration de politique de compartiment après l'ajout de l'autorisation.

     {
         "Version": "2012-10-17",
         "Id": "SSEAndSSLPolicy",
         "Statement": [
             {
                 "Effect": "Allow",
                 "Principal": "*",
                 "Action": "s3:ListBucket",
                 "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890",
                 "Condition": {
                     "StringLike": {
                         "aws:userid": "AROAEXAMPLEID:*"
                     }
                 }
             },
             {
                 "Sid": "DenyUnEncryptedObjectUploads",
                 "Effect": "Deny",
                 "Principal": "*",
                 "Action": "s3:PutObject",
                 "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
                 "Condition": {
                     "StringNotEquals": {
                         "s3:x-amz-server-side-encryption": "aws:kms"
                     }
                 }
             },
             {
                 "Sid": "DenyInsecureConnections",
                 "Effect": "Deny",
                 "Principal": "*",
                 "Action": "s3:*",
                 "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
                 "Condition": {
                     "Bool": {
                         "aws:SecureTransport": false
                     }
                 }
             }
         ]
     }

     Pour plus d'informations, suivez la procédure de la section https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/.

  5. Choisissez Enregistrer.

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 dotés d'un Amazon S3, d'Amazon ECR ou d' CodeCommitune 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 les événements CWE pour détecter les modifications, comme suit :

Action à la source	Paramètres/identifiants de déclenchement (console)
Amazon ECR	Nom du référentiel Balise d'image
Amazon S3	Compartiment Clé d'objet S3
CodeCommit	Nom du référentiel Nom de la succursale

Correctifs possibles :

Effectuez l’une des actions suivantes :

• Modifiez les paramètres de configuration CodeCommit /S3/ECR afin que des modifications soient apportées à la partie initiale de la valeur du paramètre.

  Exemple : remplacez le nom release-branch de votre succursale par2nd-release-branch. Évitez de modifier la fin du nom, par exemplerelease-branch-2.

• Modifiez les paramètres de configuration CodeCommit /S3/ECR pour chaque pipeline.

  Exemple : remplacez le nom myRepo/myBranch de votre succursale parmyDeployRepo/myDeployBranch. Évitez de modifier la fin du nom, par exemplemyRepo/myBranch2.

• Au lieu de la console, utilisez la CLI ou AWS CloudFormation pour créer et mettre à jour vos règles relatives aux événements de détection des modifications. Pour obtenir des instructions sur la création de règles d'événement pour une action source S3, consultezActions source Amazon S3 et EventBridge avec AWS CloudTrail. Pour obtenir des instructions sur la création de règles d'événement pour une action Amazon ECR, consultez Actions et ressources relatives aux sources Amazon ECR EventBridge . Pour obtenir des instructions sur la création de règles d'événement pour une CodeCommit action, consultez CodeCommit actions à la source et EventBridge.

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 passé en mode QUEUED ou PARALLEL échouent lorsque la limite d'exécution est atteinte

Problème : le nombre maximum d'exécutions simultanées pour un pipeline en mode QUEUED 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 le mode d'exécution QUEUED ou PARALLEL, consultez. CodePipeline concepts

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

Problème : pour les pipelines en mode parallèle, lorsque vous modifiez le mode d'exécution du pipeline sur QUEUED ou SUPERSEDED, la définition du pipeline pour le mode PARALLEL ne sera pas mise à jour. La définition de pipeline mise à jour lors de la mise à jour du mode PARALLÈLE n'est pas utilisée en mode SUPERSEDED ou QUEUED.

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

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

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

Problème : pour les pipelines en mode PARALLÈLE, lorsque vous modifiez le mode d'exécution du pipeline sur QUEUED ou SUPERSEDED, l'état du pipeline n'affichera pas l'état mis à jour en tant que PARALLÈLE. Si le pipeline est passé de PARALLÈLE à QUEUED ou SUPERSEDED, l'état du pipeline en mode SUPERSEDED ou QUEUED 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.

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

Pour plus d'informations sur le mode d'exécution QUEUED ou PARALLEL, consultez. CodePipeline 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 source S3 en mode PARALLÈLE peuvent ne pas correspondre à EventBridge l'événement

Description : pour les exécutions de pipeline en mode PARALLÈLE, 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 HEAD sera cloné à ce moment-là lors de la CodePipeline réception de l'événement et du démarrage de cette exécution.

Résultat : pour les pipelines en mode PARALLÈLE 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 HEAD au moment de son démarrage. Par exemple, pour un pipeline en mode PARALLÈLE, 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 :

• Contactez AWS Support.

• Posez une question CodePipelinesur le forum.

• Demandez une augmentation de quota. Pour plus d’informations, consultez Quotas dans AWS CodePipeline.

  Note

  Les demandes d'augmentation de quota sont traitées dans un délai de deux semaines maximum.