Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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, gehen Sie wie unter beschrieben vor, Hinzufügen von Berechtigungen zur CodePipeline-Servicerolle um sie mithilfe der Funktion „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 Stellen Sie sicher, dass die IAM Pipeline-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 EC2 Amazon-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 EC2 Amazon-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 Rolle oder der IAM Benutzer der EC2 Amazon-Instanz mit der AWSCodePipelineCustomActionAccess verwalteten Richtlinie oder 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 IAM Benutzer verwendet, der mit den richtigen Berechtigungen konfiguriert ist. Möglicherweise müssen Sie die IAM Benutzeranmeldedaten, 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, stellen Sie sicher, dass der Jenkins-Server gesichert ist und stattdessen verwendet. HTTPS HTTP

Pipeline-Fehler: Eine Pipeline, die in einer AWS Region mithilfe eines in einer anderen AWS Region erstellten Buckets erstellt wurde, gibt ein "InternalError" mit dem Code "“ 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 Anwendung URL meldet den Fehler 404 Not Found

Problem: Eine WAR Datei wurde erfolgreich in einer AWS Elastic Beanstalk Umgebung bereitgestellt, aber die Anwendung URL gibt den Fehler 404 Not Found zurück.

Mögliche Lösungen: AWS Elastic Beanstalk kann eine ZIP Datei entpacken, aber keine WAR Datei, die in einer ZIP Datei enthalten ist. Anstatt eine WAR Datei in Ihrer buildspec.yml Datei anzugeben, geben Sie einen Ordner an, der den Inhalt enthält, der bereitgestellt werden soll. 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:

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 die Verbindung im Resource Feld angegeben ARN wird.

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:

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.

<source artifact name>Pipeline-Fehler: Eine Bereitstellung mit der CodeDeployTo ECS Aktion gibt die folgende Fehlermeldung zurück: „Ausnahme beim Versuch, die Aufgabendefinitionsartefaktdatei zu lesen aus:“

Problem:

Die Aufgabendefinitionsdatei ist ein erforderliches Artefakt für die CodePipeline Bereitstellungsaktion an Amazon ECS über CodeDeploy (die CodeDeployToECS Aktion). Die maximale ZIP Artefaktgröße in der CodeDeployToECS Bereitstellungsaktion beträgt 3 MB. Die folgende Fehlermeldung wird zurückgegeben, wenn die Datei nicht gefunden wird oder die Artefaktgröße 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: CodePipeline Service Role < ARN > erhält 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 Servicerolle „arn:aws:iam::AccountID:Rolle/Dienstrole/RoleID„wird der S3-Zugriff für den S3-Bucket verweigert“BucketName"

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

Mögliche Korrekturen: Gehen Sie wie folgt vor:

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 S3ECR, Amazon oder CodeCommit Quelle werden nicht mehr automatisch gestartet

Problem:

Nach einer Änderung der Konfigurationseinstellungen für eine Aktion, die Ereignisregeln (EventBridgeoder CloudWatch Ereignisse) zur Erkennung von Änderungen 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 Erkennung von Änderungen verwenden:

Mögliche Lösungen:

Führen Sie eine der folgenden Aktionen aus:

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 auf QUEUED oder PARALLEL 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 Informationen zum QUEUED PARALLEL Ausführungsmodus finden Sie unterCodePipeline Konzepte .

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

Problem: Bei Pipelines im Parallelmodus wird die Pipeline-Definition für den Modus nicht aktualisiertSUPERSEDED, wenn der PARALLEL Pipeline-Ausführungsmodus auf QUEUED oder geändert wird. Die aktualisierte Pipelinedefinition, wenn der PARALLEL Aktualisierungsmodus nicht im Modus SUPERSEDED oder QUEUED verwendet wird

Mögliche Lösungen: Vermeiden Sie bei Pipelines im Parallelmodus, wenn Sie den Pipeline-Ausführungsmodus auf QUEUED oder bearbeitenSUPERSEDED, die Pipeline-Definition gleichzeitig zu aktualisieren.

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

Bei Pipelines, die aus dem PARALLEL Modus gewechselt wurden, wird ein früherer Ausführungsmodus angezeigt

Problem: Wenn Sie bei Pipelines im PARALLEL Modus den Pipeline-Ausführungsmodus auf QUEUED oder ändernSUPERSEDED, wird im Pipeline-Status nicht der aktualisierte Status als angezeigt. PARALLEL Wenn die Pipeline von PARALLEL zu QUEUED oder geändert wurdeSUPERSEDED, ist der Status der Pipeline im QUEUED Modus SUPERSEDED oder 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 ändernSUPERSEDED, dass in der Anzeige des Ausführungsmodus der PARALLEL Status nicht angezeigt wird.

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

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

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, immer HEAD zum Zeitpunkt des Starts. 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: