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 Pipeline, konfiguriert mit AWS Elastic Beanstalk gibt eine Fehlermeldung zurück: „Die Bereitstellung ist 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 Fügen Sie der CodePipeline Servicerolle Berechtigungen hinzu 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 Pipeline, die mit einem konfiguriert ist AWS Elastic Beanstalk Wenn die Berechtigung "DescribeEvents" fehlt, bleibt die Bereitstellungsaktion hängen und schlägt nicht fehl

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

Mögliche Korrekturen: Überprüfen Sie Ihre CodePipeline Servicerolle. Wenn die "elasticbeanstalk:DescribeEvents"-Aktion fehlt, folgen Sie den Schritten in Fügen Sie der CodePipeline Servicerolle Berechtigungen hinzu, 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 den Repository-Namen des Repositorys konnte nicht zugegriffen werden. CodeCommit Ü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 CodeCommit und wurde wahrscheinlich erstellt, bevor am 18. April 2016 die Unterstützung für die Verwendung von CodeCommit Repositorys 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 Korrekturen: Fügen Sie der Richtlinie für Ihre CodePipeline Servicerolle CodeCommit die erforderlichen Berechtigungen hinzu. Weitere Informationen finden Sie unter Fügen Sie der CodePipeline Servicerolle Berechtigungen hinzu.

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-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-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 Korrekturen: Stellen Sie sicher, dass die Amazon EC2-Instance-Rolle oder der IAM-Benutzer mit der verwalteten Richtlinie oder den entsprechenden Berechtigungen konfiguriert ist. AWSCodePipelineCustomActionAccess 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 angeben, die Sie für die Integration zwischen Jenkins konfiguriert haben, und zwar CodePipeline direkt in die Jenkins-Benutzeroberfläche. 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 erstellt wurde AWS Region, die einen Bucket verwendet, der in einem anderen erstellt wurde AWS Region gibt ein "InternalError" mit dem Code "JobFailed“ zurück

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

Mögliche Korrekturen: Stellen Sie sicher, dass sich der Amazon S3-Bucket, in dem Ihr Artefakt gespeichert ist, in derselben AWS Region wie die von Ihnen erstellte Pipeline befindet.

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

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: Eine ZIP-Datei AWS Elastic Beanstalk kann entpackt werden, 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. Beispiel:

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 die Namen von Pipeline-Artefakten in anzeigen 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 Größenbeschränkungen der Richtlinien nicht überschreitet, wenn temporäre Anmeldeinformationen für Mitarbeiter CodePipeline generiert werden.

Obwohl der Name des Artefakts abgeschnitten zu sein scheint, wird er dem Artefakt-Bucket so zugeordnet, dass er nicht CodePipeline von Artefakten mit verkürzten Namen beeinflusst 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üge CodeBuild GitClone Berechtigungen für Verbindungen zu Bitbucket, Enterprise Server oder hinzu GitHub GitHub GitLab.com

Wenn du eine Aktion AWS CodeConnections in einer Quelle und eine 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 angegeben wird, der Verbindungs-ARN im Resource Feld angegeben wird und die Quell-Repository-ID durch Condition begrenzt 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 Berechtigung in dem action Feld festlegt.

Pipeline-Fehler: Eine Bereitstellung mit der CodeDeployToECS Aktion gibt eine Fehlermeldung zurück: „Ausnahme beim Versuch, die Artefaktdatei der Aufgabendefinition von: < Quellartefaktname zu lesen“ >

Problem:

Die Aufgabendefinitionsdatei ist ein erforderliches Artefakt für die CodePipeline Bereitstellungsaktion für Amazon ECS über CodeDeploy (die CodeDeployToECS Aktion). Die maximale Artefakt-ZIP-Größ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 (über die OAuth-App): Die Repository-Liste zeigt verschiedene Repositorys

Problem:

Nach einer erfolgreichen Autorisierung für eine Aktion GitHub (über die OAuth-App) in der CodePipeline Konsole können Sie aus einer Liste Ihrer Repositorys auswählen. GitHub Wenn die Liste die Repositorys, die Sie erwartet haben, nicht enthält, können Sie Probleme mit dem für die Autorisierung verwendeten Konto beheben.

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 das Konto, mit dem Sie sich autorisieren, das Konto GitHub ist, das mit der GitHub Organisation verknüpft ist, in der Ihr Repository erstellt wurde.

GitHub Quellaktion (per GitHub App): Die Verbindung für ein Repository konnte nicht hergestellt werden

Problem:

Da für eine Verbindung zu einem GitHub Repository der AWS Connector verwendet wird GitHub, benötigen Sie die Berechtigungen des Organisationsinhabers oder Administratorberechtigungen für das Repository, um die Verbindung herzustellen.

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 teams/permission /setting-up-and-managing-organizations-and- -levels-for-an-organization.

Amazon S3-Fehler: Dem ARN der Servicerolle wird der S3-Zugriff für den S3-Bucket verweigert CodePipeline < > < BucketName >

Problem:

Während der Ausführung CodePipeline überprüft die CodeCommit Aktion in, ob der Pipeline-Artefakt-Bucket existiert. Wenn die Aktion nicht zur Überprüfung berechtigt ist, 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" wird der S3-Zugriff für den S3-Bucket verweigert "“ BucketName

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

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 einem Amazon S3, Amazon ECR oder einer 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-Identifikatoren ähnlich sind und identische Anfangszeichen haben. Da die neue Ereignisregel nicht von der Konsole erstellt wird, startet die Pipeline nicht mehr automatisch.

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 Branch-Namens befindet, wird die Ereignisregel für die Quellaktion möglicherweise nicht aktualisiert oder eine Regel für die neuen Quelleinstellungen erstellt.

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

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 Korrekturen: 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 PARALLELMODUS 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 fehl, ohne dass eine Statusmeldung angezeigt wird.

Mögliche Korrekturen: Wenn Sie die Pipeline-Definition für den Ausführungsmodus bearbeiten, nehmen Sie die Bearbeitung getrennt von anderen Bearbeitungsaktionen vor.

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

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

Problem: Bei Pipelines im Parallelmodus wird die Pipeline-Definition für den PARALLEL-Modus nicht aktualisiert, wenn der Pipeline-Ausführungsmodus in QUEUED oder SUPERSEDED geändert wird. Die aktualisierte Pipelinedefinition beim Aktualisieren des PARALLELMODUS wird im SUPERSEDED- oder QUEUED-Modus nicht verwendet.

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

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

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

Problem: Wenn Sie bei Pipelines im PARALLELMODUS den Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED ändern, zeigt der Pipeline-Status den aktualisierten Status nicht als PARALLEL an. Wenn die Pipeline von PARALLEL in QUEUED oder SUPERSEDED geändert wurde, ist der Status der Pipeline im SUPERSEDED- oder QUEUED-Modus 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: Wenn Sie bei Pipelines im Parallelmodus den Pipeline-Ausführungsmodus auf QUEUED oder SUPERSEDED ändern, beachten Sie, dass in der Anzeige des Ausführungsmodus der Status PARALLEL nicht angezeigt wird.

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

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

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, der es Ihnen ermöglicht, nach Dateipfaden zu filtern, um Ihre Pipeline zu starten. In bestimmten Fällen startet die Pipeline bei Pipelines mit Triggern, die nach Dateipfaden gefiltert werden, möglicherweise nicht, wenn ein Zweig mit einem Dateipfadfilter zum ersten Mal erstellt wird, da die CodeConnections Verbindung die geänderten Dateien dadurch nicht auflösen kann. 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 erst im Quell-Repository erstellt wurde. Weitere Hinweise zum Filtern nach Dateipfaden finden Sie unterTrigger mit Code-Push- oder Pull-Request-Ereignistypen hinzufügen.

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

Pipelines mit Verbindungen, die eine 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, der es Ihnen ermöglicht, nach Dateipfaden zu filtern, 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 sie nach Dateipfaden filtert, startet die Pipeline daher möglicherweise nicht, wenn mehr als 100 Dateien vorhanden sind. Weitere Hinweise zum Filtern nach Dateipfaden finden Sie unterTrigger mit Code-Push- oder Pull-Request-Ereignistypen hinzufügen.

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

CodeCommit oder Revisionen der S3-Quelle im PARALLELMODUS 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. mit 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, die die Pipeline starten, liegen kann, wenn das Ereignis CodePipeline empfangen und die Ausführung gestartet wurde und ein anderer Commit oder Image-Tag übertragen wurde CodePipeline (z. B. die CodeCommit Aktion), wird der HEAD-Commit in diesem Moment geklont.

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

Die EC2 Deploy-Aktion schlägt mit der Fehlermeldung Keine solche Datei fehl

Beschreibung: Nachdem die EC2-Bereitstellungsaktion die Artefakte im Zielverzeichnis auf den Instances entpackt hat, führt die Aktion das Skript aus. Wenn sich das Skript im Zielverzeichnis befindet, die Aktion das Skript jedoch nicht ausführen kann, schlägt die Aktion auf dieser Instance fehl und die Bereitstellung der verbleibenden Instanzen schlägt fehl.

Ein Fehler, der den folgenden Fehlermeldungen ähnelt, wird in den Protokollen für eine Bereitstellung angezeigt, bei der sich das Zielverzeichnis /home/ec2-user/deploy/ und der Quell-Repository-Pfad befindenmyRepo/postScript.sh.

Ergebnis: Die Bereitstellungsaktion schlägt in der Pipeline fehl.

Mögliche Lösungen: Gehen Sie zur Problembehandlung wie folgt vor.

Die EKS Deploy-Aktion schlägt fehl und es wird eine Fehlermeldung angezeigt, dass der Cluster nicht erreichbar ist

Beschreibung: Nach der Ausführung der EKS-Bereitstellungsaktion schlägt die Aktion mit einer cluster unreachable Fehlermeldung fehl. Die Meldung zeigt ein Zugriffsproblem auf dem Cluster aufgrund fehlender Berechtigungen. Je nach Dateityp (Helm-Diagramm- oder Kubernetes-Manifestdateien) wird die Fehlermeldung wie folgt angezeigt.

Ergebnis: Die Bereitstellungsaktion schlägt in der Pipeline fehl.

Mögliche Korrekturen: Wenn Sie eine vorhandene Rolle verwenden, muss die CodePipeline Servicerolle mit den erforderlichen Berechtigungen aktualisiert werden, um die EKS-Bereitstellungsaktion verwenden zu können. Um der CodePipeline Servicerolle den Zugriff auf Ihren Cluster zu ermöglichen, müssen Sie Ihrem Cluster außerdem einen Zugriffseintrag hinzufügen und die Servicerolle für den Zugriffseintrag angeben.

Die Pipeline wird nicht für alle Branches ausgelöst, wenn mehrere Quellaktionen auf dasselbe Repository verweisen

Problem: Eine Pipeline hat mehrere Quellaktionen, die Verbindungen verwenden (z. B. ein Bitbucket oder eine GitLab Verbindung), wobei jede Quellaktion auf einen anderen Zweig desselben Repositorys verweist. GitHub Nur einer der Branches löst die Pipeline aus, wenn du Änderungen überträgst. Das Webhook-Abonnement der Verbindung wird für die Kombination aus Pipeline und Repository registriert, nicht pro Branch. Daher werden mehrere Quellaktionen, die auf verschiedene Zweige desselben Repositorys innerhalb einer einzigen Pipeline abzielen, nicht unterstützt.

Mögliche Korrekturen: Verwenden Sie für jeden Branch, den Sie unabhängig auslösen möchten, eine separate Pipeline.

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

Sie haben folgende weitere Möglichkeiten: