Problembehebung CodePipeline

Die folgenden Informationen helfen Ihnen möglicherweise bei der Lösung häufiger Probleme in AWS CodePipeline.

Pipeline-Fehler: Eine mit AWS Elastic Beanstalk konfigurierte Pipeline gibt eine Fehlermeldung zurück: „Bereitstellung fehlgeschlagen. Die angegebene Rolle verfügt nicht über ausreichende Berechtigungen: Service:AmazonElasticLoadBalancing“

Problem: Die Servicerolle für CodePipeline verfügt nicht über ausreichende Berechtigungen für AWS Elastic Beanstalk, einschließlich, aber nicht beschränkt auf, einige Operationen in Elastic Load Balancing. Die Servicerolle für CodePipeline wurde am 6. August 2015 aktualisiert, um dieses Problem zu beheben. Kunden, die ihre Service-Rolle vor diesem Datum erstellt haben, müssen Sie Richtlinienanweisung für ihre Service-Rolle ändern, um die erforderlichen Berechtigungen hinzuzufügen.

Mögliche Fehlerbehebungen: Die einfachste Lösung besteht darin, die Richtlinienanweisung für Ihre Servicerolle zu bearbeiten, wie unter Hinzufügen von Berechtigungen zur CodePipeline-Servicerolle beschrieben.

Nachdem Sie die bearbeitete Richtlinie angewendet haben, folgen Sie den Schritten unter, Manuelles Starten einer Pipeline um alle Pipelines, die Elastic Beanstalk verwenden, manuell erneut auszuführen.

Abhängig von Ihren Sicherheitsanforderungen können Sie die Berechtigungen auch auf andere Arten ändern.

Bereitstellungsfehler: Eine mit einer AWS Elastic Beanstalk Bereitstellungsaktion konfigurierte Pipeline bleibt hängen und schlägt nicht fehl, wenn die "" DescribeEvents -Berechtigung fehlt

Problem: Die Servicerolle für CodePipeline muss die "elasticbeanstalk:DescribeEvents" Aktion für alle Pipelines enthalten, die verwenden AWS Elastic Beanstalk. Ohne diese Berechtigung bleiben AWS Elastic Beanstalk Bereitstellungsaktionen hängen, ohne dass sie fehlschlagen oder auf einen Fehler hinweisen. Wenn diese Aktion in Ihrer Servicerolle fehlt, CodePipeline verfügt sie nicht über die erforderlichen Berechtigungen, um die Pipeline-Bereitstellungsphase in AWS Elastic Beanstalk Ihrem Namen auszuführen.

Mögliche Lösungen: Überprüfen Sie Ihre CodePipeline Servicerolle. Wenn die "elasticbeanstalk:DescribeEvents"-Aktion fehlt, folgen Sie den Schritten in Hinzufügen von Berechtigungen zur CodePipeline-Servicerolle, um sie unter Verwendung der Funktion Edit Policy (Richtlinie bearbeiten) in der IAM-Konsole hinzuzufügen.

Nachdem Sie die bearbeitete Richtlinie angewendet haben, folgen Sie den Schritten unter, Manuelles Starten einer Pipeline um alle Pipelines, die Elastic Beanstalk verwenden, manuell erneut auszuführen.

Pipeline-Fehler: Eine Quellaktion gibt die Meldung mit unzureichenden Berechtigungen zurück: „Auf das Repository konnte nicht zugegriffen werden. CodeCommit repository-name Überprüfen Sie, ob die Pipeline-IAM-Rolle über ausreichende Berechtigungen für den Zugriff auf das Repository verfügt.“

Problem: Die Servicerolle für CodePipeline verfügt nicht über ausreichende Berechtigungen für CodeCommit und wurde wahrscheinlich erstellt, bevor die Unterstützung für die Verwendung von CodeCommit Repositorys am 18. April 2016 hinzugefügt wurde. Kunden, die ihre Service-Rolle vor diesem Datum erstellt haben, müssen Sie Richtlinienanweisung für ihre Service-Rolle ändern, um die erforderlichen Berechtigungen hinzuzufügen.

Mögliche Lösungen: Fügen Sie der Richtlinie für Ihre CodeCommit CodePipeline Servicerolle die erforderlichen Berechtigungen für hinzu. Weitere Informationen finden Sie unter Hinzufügen von Berechtigungen zur CodePipeline-Servicerolle.

Pipeline-Fehler: Ein Jenkins-Build oder eine Testaktion werden über eine lange Zeit ausgeführt und schlagen dann aufgrund fehlender Anmeldeinformationen oder Berechtigungen fehl.

Problem: Wenn der Jenkins-Server auf einer Amazon EC2 EC2-Instance installiert ist, wurde die Instance möglicherweise nicht mit einer Instance-Rolle erstellt, die über die erforderlichen Berechtigungen verfügt. CodePipeline Wenn Sie einen IAM-Benutzer auf einem Jenkins-Server, einer lokalen Instance oder einer Amazon EC2 EC2-Instance verwenden, die ohne die erforderliche IAM-Rolle erstellt wurde, verfügt der IAM-Benutzer entweder nicht über die erforderlichen Berechtigungen, oder der Jenkins-Server kann nicht über das auf dem Server konfigurierte Profil auf diese Anmeldeinformationen zugreifen.

Mögliche Lösungen: Stellen Sie sicher, dass die Amazon EC2 EC2-Instance-Rolle oder der IAM-Benutzer mit der AWSCodePipelineCustomActionAccess verwalteten Richtlinie oder mit den entsprechenden Berechtigungen konfiguriert ist. Weitere Informationen finden Sie unter AWS verwaltete Richtlinien für AWS CodePipeline.

Wenn Sie einen IAM-Benutzer verwenden, stellen Sie sicher, dass das auf der Instance konfigurierte AWS Profil den mit den richtigen Berechtigungen konfigurierten IAM-Benutzer verwendet. Möglicherweise müssen Sie die IAM-Benutzeranmeldeinformationen, die Sie für die Integration zwischen Jenkins konfiguriert haben, CodePipeline direkt in die Jenkins-Benutzeroberfläche eingeben. Dies ist keine empfohlene bewährte Methode. Wenn Sie dies tun müssen, müssen Sie sicherstellen, dass der Jenkins-Server geschützt ist und HTTPS statt HTTP verwendet.

Pipeline-Fehler: Eine Pipeline, die in einer AWS Region mithilfe eines in einer anderen AWS Region erstellten Buckets erstellt wurde, gibt ein "" mit dem Code InternalError "“ zurück JobFailed

Problem: Der Download eines in einem Amazon S3 S3-Bucket gespeicherten Artefakts schlägt fehl, wenn die Pipeline und der Bucket in verschiedenen AWS Regionen erstellt werden.

Mögliche Lösungen: Stellen Sie sicher, dass sich der Amazon S3 S3-Bucket, in dem Ihr Artefakt gespeichert ist, in derselben AWS Region befindet wie die Pipeline, die Sie erstellt haben.

Bereitstellungsfehler: Eine ZIP-Datei, die eine WAR-Datei enthält, wurde erfolgreich bereitgestellt AWS Elastic Beanstalk, aber die Anwendungs-URL meldet den Fehler 404 Not Found

Problem: Eine WAR-Datei wird erfolgreich für eine AWS Elastic Beanstalk -Umgebung bereitgestellt, die Anwendungs-URL gibt jedoch den Fehler "404 Not Found" (404 Nicht gefunden) zurück.

Mögliche Korrekturen: AWS Elastic Beanstalk kann eine ZIP-Datei entpacken, aber keine WAR-Datei, die in einer ZIP-Datei enthalten ist. Geben Sie statt einer WAR-Datei in Ihrer Datei buildspec.yml einen Ordner an, der die Inhalte enthält, die bereitgestellt werden sollen. Beispielsweise:

version: 0.2

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

Ein Beispiel hierfür finden Sie unter AWS Elastic Beanstalk -Beispiel für CodeBuild.

Pipeline-Artefakt-Ordnernamen werden gekürzt

Problem: Wenn Sie sich die Namen von Pipeline-Artefakten in ansehen CodePipeline, scheinen die Namen gekürzt zu sein. Dadurch sehen manche Namen gleich aus oder enthalten augenscheinlich nicht mehr den gesamten Pipelinenamen.

Erklärung: CodePipeline Kürzt Artefaktnamen, um sicherzustellen, dass der vollständige Amazon S3-Pfad die Richtliniengrößenbeschränkungen nicht überschreitet, wenn temporäre Anmeldeinformationen für CodePipeline Jobarbeiter generiert werden.

Auch wenn der Artefaktname gekürzt zu sein scheint, wird er dem CodePipeline Artefakt-Bucket auf eine Weise zugeordnet, die nicht durch Artefakte mit gekürzten Namen beeinträchtigt wird. Die Pipeline kann normal ausgeführt werden. Dies ist kein Problem mit dem Ordner oder den Artefakten. Für Pipelinenamen besteht eine Längenbegrenzung auf 100 Zeichen. Auch wenn der Name des Artefaktordners gekürzt angezeigt wird, ist er für Ihre Pipeline eindeutig.

Fügen Sie CodeBuild GitClone Berechtigungen für Verbindungen zu Bitbucket, Enterprise Server oder .com GitHub hinzu GitHub GitLab

Wenn du eine AWS CodeStar Verbindung in einer Quellaktion und einer CodeBuild Aktion verwendest, gibt es zwei Möglichkeiten, wie das Eingabeartefakt an den Build übergeben werden kann:

• Standard: Die Quellaktion erzeugt eine ZIP-Datei, die den CodeBuild heruntergeladenen Code enthält.

• Git-Klon: Der Quellcode kann direkt in die Build-Umgebung heruntergeladen werden.

  Der Git-Klon-Modus ermöglicht es Ihnen, mit dem Quellcode als funktionierendes Git-Repository zu interagieren. Um diesen Modus verwenden zu können, müssen Sie Ihrer CodeBuild Umgebung Berechtigungen zur Verwendung der Verbindung erteilen.

Um Ihrer CodeBuild Servicerollenrichtlinie Berechtigungen hinzuzufügen, erstellen Sie eine vom Kunden verwaltete Richtlinie, die Sie Ihrer CodeBuild Servicerolle zuordnen. Mit den folgenden Schritten wird eine Richtlinie erstellt, bei der die UseConnection-Berechtigung im action-Feld und der Verbindungs-ARN im Resource-Feld angegeben wird.

So verwenden Sie die Konsole, um die UseConnection Berechtigungen hinzuzufügen

1. Um den Verbindungs-ARN für Ihre Pipeline zu finden, öffnen Sie die Pipeline und klicken Sie auf das (i)-Symbol in der Quellaktion. Sie fügen den Verbindungs-ARN zu Ihrer CodeBuild Servicerollenrichtlinie hinzu.

   Ein Beispiel für eine Verbindungs-ARN ist:

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

2. Um Ihre CodeBuild Servicerolle zu finden, öffnen Sie das in Ihrer Pipeline verwendete Build-Projekt und navigieren Sie zur Registerkarte Build-Details.

3. Wählen Sie den Link Service role (Servicerolle) . Dadurch wird die IAM-Konsole geöffnet, in der Sie eine neue Richtlinie hinzufügen können, die Zugriff auf Ihre Verbindung gewährt.

4. Wählen Sie in der IAM-Konsole Attach policies (Richtlinien anhängen) und dann Create policy (Richtlinie erstellen).

   Verwenden Sie die folgende Beispielrichtlinienvorlage. Fügen Sie Ihren Verbindungs-ARN in das Resource-Feld ein, wie in diesem Beispiel gezeigt:

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

   Fügen Sie auf der Registerkarte JSON Ihre Richtlinie ein.

5. Wählen Sie Richtlinie prüfen. Geben Sie einen Namen für die Richtlinie ein (beispielsweise connection-permissions) und wählen Sie dann Create policy (Richtlinie erstellen) aus.

6. Kehren Sie zu der Seite zurück, auf der Sie Berechtigungen angehängt haben, aktualisieren Sie die Richtlinienliste und wählen Sie die gerade erstellte Richtlinie aus. Wählen Sie Richtlinien anfügen.

   

Fügen Sie CodeBuild GitClone Berechtigungen für CodeCommit Quellaktionen hinzu

Wenn Ihre Pipeline über eine CodeCommit Quellaktion verfügt, gibt es zwei Möglichkeiten, das Eingabeartefakt an den Build zu übergeben:

• Standard — Die Quellaktion erzeugt eine ZIP-Datei, die den CodeBuild heruntergeladenen Code enthält.

• Vollständiger Klon — Der Quellcode kann direkt in die Build-Umgebung heruntergeladen werden.

  Die Option Vollständiges Klonen ermöglicht es Ihnen, mit dem Quellcode als funktionierendes Git-Repository zu interagieren. Um diesen Modus zu verwenden, müssen Sie Ihrer CodeBuild Umgebung Berechtigungen zum Abrufen von Inhalten aus Ihrem Repository hinzufügen.

Um Ihrer CodeBuild Servicerollenrichtlinie Berechtigungen hinzuzufügen, erstellen Sie eine vom Kunden verwaltete Richtlinie, die Sie Ihrer CodeBuild Servicerolle zuordnen. Mit den folgenden Schritten wird eine Richtlinie erstellt, die die codecommit:GitPull Berechtigungen in dem action Feld festlegt.

Um die Konsole zum Hinzufügen der GitPull Berechtigungen zu verwenden

1. Um Ihre CodeBuild Servicerolle zu finden, öffnen Sie das in Ihrer Pipeline verwendete Build-Projekt und navigieren Sie zur Registerkarte Build-Details.

2. Wählen Sie den Link Service role (Servicerolle) . Dadurch wird die IAM-Konsole geöffnet, in der Sie eine neue Richtlinie hinzufügen können, die Zugriff auf Ihr Repository gewährt.

3. Wählen Sie in der IAM-Konsole Attach policies (Richtlinien anhängen) und dann Create policy (Richtlinie erstellen).

4. Fügen Sie auf der Registerkarte JSON die folgende Beispielrichtlinie ein.

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

5. Wählen Sie Richtlinie prüfen. Geben Sie einen Namen für die Richtlinie ein (beispielsweise codecommit-gitpull) und wählen Sie dann Create policy (Richtlinie erstellen) aus.

6. Kehren Sie zu der Seite zurück, auf der Sie Berechtigungen angehängt haben, aktualisieren Sie die Richtlinienliste und wählen Sie die gerade erstellte Richtlinie aus. Wählen Sie Richtlinien anfügen.

<source artifact name>Pipeline-Fehler: Bei einer Bereitstellung mit der CodeDeployTo ECS-Aktion wird die folgende Fehlermeldung zurückgegeben: „Ausnahme beim Versuch, die Artefaktdatei der Aufgabendefinition zu lesen aus:“

Problem:

Die Aufgabendefinitionsdatei ist ein erforderliches Artefakt für die CodePipeline Bereitstellungsaktion in Amazon ECS über CodeDeploy (die CodeDeployToECS Aktion). Die maximale ZIP-Größe des Artefakts in der Aktion „CodeDeployToECSBereitstellen“ beträgt 3 MB. Die folgende Fehlermeldung wird zurückgegeben, wenn die Datei nicht gefunden wird oder die Größe des Artefakts 3 MB überschreitet:

Ausnahme beim Versuch, die Taskdefinitions-Artefaktdatei aus folgender Quelle zu lesen von: <source artifact name>

Mögliche Korrekturen: Stellen Sie sicher, dass die Aufgabendefinitionsdatei als Artefakt enthalten ist. Wenn die Datei bereits existiert, stellen Sie sicher, dass die komprimierte Größe weniger als 3 MB beträgt.

GitHub Quellaktion für Version 1: Die Repository-Liste zeigt verschiedene Repositorys

Problem:

Nach erfolgreicher Autorisierung für eine Aktion für GitHub Version 1 in der CodePipeline Konsole können Sie aus einer Liste Ihrer GitHub Repositorys wählen. Wenn die Liste nicht die Repositorys enthält, die Sie erwartet haben, können Sie Probleme mit dem Konto beheben, das für die Autorisierung verwendet wurde.

Mögliche Korrekturen: Die Liste der Repositorys in der CodePipeline Konsole basiert auf der GitHub Organisation, zu der das autorisierte Konto gehört. Vergewissern Sie sich, dass es sich bei dem Konto, das Sie für die Autorisierung verwenden, um das Konto GitHub handelt, das der GitHub Organisation zugeordnet ist, in der Ihr Repository erstellt wurde.

GitHub Quellaktion für Version 2: Die Verbindung für ein Repository konnte nicht abgeschlossen werden

Problem:

Da eine Verbindung zu einem GitHub Repository den AWS Connector für verwendet GitHub, benötigen Sie zum Herstellen der Verbindung die Rechte des Organisationsinhabers oder Administratorberechtigungen für das Repository.

Mögliche Korrekturen: Informationen zu den Berechtigungsstufen für ein GitHub Repository finden Sie unter https://docs.github.com/en/ free-pro-team @latest /github/ setting-up-and-managing -organizations-and-teams/permission-levels-for-an-organization.

Amazon S3 S3-Fehler: Für die CodePipeline <ARN>Servicerolle wurde der S3-Zugriff für den S3-Bucket verweigert < BucketName >

Problem:

Während der Bearbeitung CodePipeline überprüft die CodeCommit Aktion in, ob der Pipeline-Artefakt-Bucket vorhanden ist. Wenn die Aktion nicht über die Berechtigung zur Überprüfung verfügt, tritt in Amazon S3 ein AccessDenied Fehler auf und die folgende Fehlermeldung wird angezeigt in CodePipeline:

CodePipeline Der Servicerolle „arn:aws:iam:: accountId:role/service-role/ roleID" wurde der S3-Zugriff für den S3-Bucket verweigert "“ BucketName

CloudTrail In den Protokollen für die Aktion wird auch AccessDenied der Fehler protokolliert.

Mögliche Korrekturen: Gehen Sie wie folgt vor:

• Fügen s3:ListBucket Sie die Richtlinie, die Ihrer CodePipeline Servicerolle zugeordnet ist, der Liste der Aktionen in Ihrer Richtlinie hinzu. Anweisungen zum Anzeigen Ihrer Richtlinie für Servicerollen finden Sie unterDen Pipeline-ARN und die Servicerolle ARN (Konsole) anzeigen. Bearbeiten Sie die Richtlinienerklärung für Ihre Servicerolle, wie unter beschriebenHinzufügen von Berechtigungen zur CodePipeline-Servicerolle.

• Fügen Sie für die ressourcenbasierte Richtlinie, die dem Amazon S3 S3-Artefakt-Bucket für Ihre Pipeline beigefügt ist, auch Artifact-Bucket-Richtlinie genannt, eine Erklärung hinzu, damit die s3:ListBucket Berechtigung von Ihrer Servicerolle verwendet werden kann. CodePipeline

  Um Ihre Richtlinie zum Artifact-Bucket hinzuzufügen

  1. Folgen Sie den Schritten unterDen Pipeline-ARN und die Servicerolle ARN (Konsole) anzeigen, um Ihren Artefakt-Bucket auf der Seite mit den Pipeline-Einstellungen auszuwählen und ihn dann in der Amazon S3 S3-Konsole anzuzeigen.

  2. Wählen Sie Permissions (Berechtigungen).

  3. Wählen Sie unter Bucket-Richtlinie Bearbeiten aus.

  4. Geben Sie im Textfeld Richtlinie eine neue Bucket-Richtlinie ein oder bearbeiten Sie die bestehende Richtlinie, wie im folgenden Beispiel gezeigt. Die Bucket-Richtlinie ist eine JSON-Datei, daher müssen Sie eine gültige JSON-Datei eingeben.

     Das folgende Beispiel zeigt eine Bucket-Richtlinienanweisung für einen Artefakt-Bucket, wobei die Beispielrollen-ID für die Servicerolle AROAEXAMPLEID lautet.

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

     Das folgende Beispiel zeigt dieselbe Bucket-Policy-Anweisung, nachdem die Berechtigung hinzugefügt wurde.

     {
         "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
                     }
                 }
             }
         ]
     }

     Weitere Informationen finden Sie in den Schritten unter https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/.

  5. Wählen Sie Speichern.

Nachdem Sie die bearbeitete Richtlinie angewendet haben, folgen Sie den Schritten unter, Manuelles Starten einer Pipeline um Ihre Pipeline manuell erneut auszuführen.

Pipelines mit Amazon S3, Amazon ECR oder CodeCommit Quelle werden nicht mehr automatisch gestartet

Problem:

Nach einer Änderung der Konfigurationseinstellungen für eine Aktion, die Ereignisregeln (EventBridgeoder CloudWatch Ereignisse) zur Änderungserkennung verwendet, erkennt die Konsole möglicherweise keine Änderung, wenn die Quell-Trigger-IDs ähnlich sind und identische Anfangszeichen haben. Da die neue Ereignisregel nicht von der Konsole erstellt wird, wird die Pipeline nicht mehr automatisch gestartet.

Ein Beispiel für eine geringfügige Änderung am Ende des Parameternamens für CodeCommit wäre die Änderung Ihres CodeCommit Zweignamens MyTestBranch-1 inMyTestBranch-2. Da sich die Änderung am Ende des Zweignamens befindet, aktualisiert oder erstellt die Ereignisregel für die Quellaktion möglicherweise keine Regel für die neuen Quelleinstellungen.

Dies gilt wie folgt für Quellaktionen, die CWE-Ereignisse zur Änderungserkennung verwenden:

Quellaktion	Parameter/Trigger-Identifikatoren (Konsole)
Amazon ECR	Repository-Name Bild-Tag
Amazon S3	Bucket S3-Objektschlüssel
CodeCommit	Repository-Name Name der Filiale

Mögliche Lösungen:

Führen Sie eine der folgenden Aktionen aus:

• Ändern Sie die CodeCommit /S3/ECR-Konfigurationseinstellungen so, dass Änderungen am Startteil des Parameterwerts vorgenommen werden.

  Beispiel: Ändern Sie Ihren Filialnamen in. release-branch 2nd-release-branch Vermeiden Sie eine Änderung am Ende des Namens, wie release-branch-2 z.

• Ändern Sie die CodeCommit /S3/ECR-Konfigurationseinstellungen für jede Pipeline.

  Beispiel: Ändern Sie Ihren Filialnamen in. myRepo/myBranch myDeployRepo/myDeployBranch Vermeiden Sie eine Änderung am Ende des Namens, wie myRepo/myBranch2 z.

• Verwenden Sie statt der Konsole die CLI oder AWS CloudFormation um Ihre Regeln für Änderungserkennungsereignisse zu erstellen und zu aktualisieren. Anweisungen zum Erstellen von Ereignisregeln für eine S3-Quellaktion finden Sie unter. Amazon S3 S3-Quellaktionen und EventBridge mit AWS CloudTrail Anweisungen zum Erstellen von Ereignisregeln für eine Amazon ECR-Aktion finden Sie unter Amazon ECR-Quellaktionen und Ressourcen EventBridge . Anweisungen zum Erstellen von Ereignisregeln für eine CodeCommit Aktion finden Sie unter CodeCommit Quellaktionen und EventBridge.

Nachdem Sie Ihre Aktionskonfiguration in der Konsole bearbeitet haben, akzeptieren Sie die aktualisierten Ressourcen zur Änderungserkennung, die von der Konsole erstellt wurden.

Verbindungsfehler beim Herstellen einer Verbindung zu GitHub: „Es ist ein Problem aufgetreten, stellen Sie sicher, dass Cookies in Ihrem Browser aktiviert sind“ oder „Ein Organisationsinhaber muss die GitHub App installieren“

Problem:

Um die Verbindung für eine GitHub Quellaktion in herzustellen CodePipeline, müssen Sie der Eigentümer der GitHub Organisation sein. Bei Repositorys, die keiner Organisation angehören, müssen Sie der Repository-Besitzer sein. Erstellt eine andere Person als der Organisationsbesitzer eine Verbindung, wird eine Anfrage für den Organisationsbesitzer erstellt, und einer der folgenden Fehler wird angezeigt:

Es ist ein Problem aufgetreten. Stellen Sie sicher, dass Cookies in Ihrem Browser aktiviert sind

ODER

Ein Organisationsinhaber muss die GitHub App installieren

Mögliche Lösungen: Für Repositorys in einer GitHub Organisation muss der Organisationsinhaber die Verbindung zum GitHub Repository herstellen. Bei Repositorys, die keiner Organisation angehören, müssen Sie der Repository-Besitzer sein.

Pipelines, deren Ausführungsmodus in den QUEUED- oder PARALLEL-Modus geändert wurde, schlagen fehl, wenn das Ausführungslimit erreicht ist

Problem: Die maximale Anzahl gleichzeitiger Ausführungen für eine Pipeline im QUEUED-Modus beträgt 50 Ausführungen. Wenn dieses Limit erreicht ist, schlägt die Pipeline ohne Statusmeldung fehl.

Mögliche Lösungen: Wenn Sie die Pipeline-Definition für den Ausführungsmodus bearbeiten, führen Sie die Bearbeitung getrennt von anderen Bearbeitungsaktionen durch.

Weitere Hinweise zum Ausführungsmodus QUEUED oder PARALLEL finden Sie unterCodePipeline Konzepte .

Pipelines im PARALLEL-Modus weisen eine veraltete Pipeline-Definition auf, wenn sie beim Wechsel in den QUEUED- oder SUPERSEDED-Modus bearbeitet werden

Problem: Wenn Sie für Pipelines im Parallelmodus den Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED ändern, wird die Pipeline-Definition für den PARALLEL-Modus nicht aktualisiert. Die beim Aktualisieren des PARALLEL-Modus aktualisierte Pipeline-Definition wird im Modus SUPERSEDED oder QUEUED nicht verwendet

Mögliche Lösungen: Wenn Sie bei Pipelines im Parallelmodus den Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED ändern, vermeiden Sie es, die Pipeline-Definition gleichzeitig zu aktualisieren.

Weitere Hinweise zum Ausführungsmodus QUEUED oder PARALLEL finden Sie unter. CodePipeline Konzepte

Bei Pipelines, die vom PARALLEL-Modus aus geändert wurden, wird ein früherer Ausführungsmodus angezeigt

Problem: Bei Pipelines im PARALLEL-Modus wird beim Ändern des Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED der aktualisierte Status nicht als PARALLEL angezeigt. Wenn die Pipeline von PARALLEL in QUEUED oder SUPERSEDED geändert wurde, ist der Status der Pipeline im Modus ABGELÖST oder WARTESCHLANGE der letzte bekannte Status in einem dieser Modi. Wenn die Pipeline noch nie in diesem Modus ausgeführt wurde, ist der Status leer.

Mögliche Korrekturen: Beachten Sie bei Pipelines im Parallelmodus, wenn Sie den Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED ändern, dass in der Anzeige des Ausführungsmodus nicht der Status PARALLEL angezeigt wird.

Weitere Hinweise zum Ausführungsmodus QUEUED oder PARALLEL finden Sie unter. CodePipeline Konzepte

Pipelines mit Verbindungen, die Triggerfilterung nach Dateipfaden verwenden, beginnen möglicherweise nicht bei der Erstellung von Zweigen

Beschreibung: Für Pipelines mit Quellaktionen, die Verbindungen verwenden, wie z. B. eine BitBucket Quellaktion, können Sie einen Trigger mit einer Git-Konfiguration einrichten, mit der Sie nach Dateipfaden filtern können, um Ihre Pipeline zu starten. In bestimmten Fällen wird bei Pipelines mit Triggern, die nach Dateipfaden gefiltert werden, die Pipeline möglicherweise nicht gestartet, wenn ein Zweig mit einem Dateipfadfilter zum ersten Mal erstellt wird, da die CodeConnections Verbindung dadurch nicht in der Lage ist, die geänderten Dateien aufzulösen. Wenn die Git-Konfiguration für den Trigger so eingerichtet ist, dass nach Dateipfaden gefiltert wird, startet die Pipeline nicht, wenn der Branch mit dem Filter gerade im Quell-Repository erstellt wurde. Weitere Informationen zum Filtern nach Dateipfaden finden Sie unterTrigger für Code-Push- oder Pull-Anfragen filtern.

Ergebnis: Beispielsweise werden Pipelines, CodePipeline die einen Dateipfadfilter für einen Zweig „B“ haben, nicht ausgelöst, wenn der Zweig „B“ erstellt wird. Wenn es keine Dateipfadfilter gibt, wird die Pipeline trotzdem gestartet.

Pipelines mit Verbindungen, die Triggerfilterung nach Dateipfaden verwenden, werden möglicherweise nicht gestartet, wenn das Dateilimit erreicht ist

Beschreibung: Für Pipelines mit Quellaktionen, die Verbindungen verwenden, wie z. B. eine BitBucket Quellaktion, können Sie einen Trigger mit einer Git-Konfiguration einrichten, mit der Sie nach Dateipfaden filtern können, um Ihre Pipeline zu starten. CodePipeline ruft bis zu die ersten 100 Dateien ab. Wenn die Git-Konfiguration für den Trigger so eingerichtet ist, dass nach Dateipfaden gefiltert wird, startet die Pipeline daher möglicherweise nicht, wenn mehr als 100 Dateien vorhanden sind. Weitere Informationen zum Filtern nach Dateipfaden finden Sie unterTrigger für Code-Push- oder Pull-Anfragen filtern.

Ergebnis: Wenn ein Diff beispielsweise 150 Dateien enthält, CodePipeline werden die ersten 100 Dateien (in keiner bestimmten Reihenfolge) anhand des angegebenen Dateipfadfilters geprüft. Wenn die Datei, die dem Dateipfadfilter entspricht, nicht zu den 100 abgerufenen Dateien gehört CodePipeline, wird die Pipeline nicht aufgerufen.

CodeCommit oder S3-Quellversionen im PARALLEL-Modus stimmen möglicherweise nicht mit dem Ereignis überein EventBridge

Beschreibung: Bei Pipeline-Ausführungen im PARALLEL-Modus kann eine Ausführung mit der letzten Änderung beginnen, z. B. dem CodeCommit Repository-Commit, die möglicherweise nicht mit der Änderung für das EventBridge Ereignis identisch ist. In einigen Fällen, in denen ein Sekundenbruchteil zwischen Commits oder Image-Tags liegt, die die Pipeline starten, wird, wenn das Ereignis CodePipeline empfangen und die Ausführung gestartet wird, ein weiterer Commit oder Image-Tag übertragen CodePipeline (z. B. die CodeCommit Aktion), der HEAD-Commit in diesem Moment geklont.

Ergebnis: Bei Pipelines im PARALLEL-Modus mit einer CodeCommit oder S3-Quelle klont die Quellaktion unabhängig von der Änderung, die die Pipeline-Ausführung ausgelöst hat, den HEAD immer zu dem Zeitpunkt, zu dem er gestartet wird. Bei einer Pipeline im PARALLEL-Modus wird beispielsweise ein Commit per Push übertragen, wodurch die Pipeline für Ausführung 1 gestartet wird, und die zweite Pipeline-Ausführung verwendet den zweiten Commit.

Benötigen Sie Hilfe für ein anderes Problem?

Sie haben folgende weitere Möglichkeiten:

• AWS Support kontaktieren.

• Stellen Sie eine Frage im CodePipelineForum.

• Anfordern einer Kontingenterhöhung. Weitere Informationen finden Sie unter Kontingente in AWS CodePipeline.

  Anmerkung

  Die Verarbeitung von Anträgen zur Kontingenterhöhung kann bis zu zwei Wochen dauern.