Problembehebung AWS CodeBuild

Verwenden Sie die Informationen in diesem Thema, um Fehler zu identifizieren, zu diagnostizieren und zu beheben. Informationen zum Protokollieren und Überwachen von CodeBuild Builds zur Problembehandlung finden Sie unterProtokollierung und Überwachung.

Apache Maven erstellt Referenzartefakte aus dem falschen Repository

Problem: Wenn Sie Maven mit einer von ihm AWS CodeBuild bereitgestellten Java-Build-Umgebung verwenden, ruft Maven Build- und Plugin-Abhängigkeiten aus dem sicheren zentralen Maven-Repository unter https://repo1.maven.org/maven2 ab. Das passiert auch dann, wenn die Datei pom.xml des Build-Projekts explizit die Verwendung anderer Verzeichnisse angibt.

Mögliche Ursache: Von CodeBuild -bereitgestellte Java-Build-Umgebungen enthalten eine Datei mit dem Namensettings.xml, die im Verzeichnis der Build-Umgebung vorinstalliert ist. /root/.m2 Diese Datei settings.xml enthält die folgenden Deklarationen, die Maven anweisen, Build- und Plugin-Abhängigkeiten aus dem sicheren zentralen Maven-Repository unter https://repo1.maven.org/maven2 abzurufen.

<settings>
  <activeProfiles>
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

Empfohlene Lösung: Gehen Sie wie folgt vor:

Build-Befehle werden standardmäßig als Root-Benutzer ausgeführt

Problem: AWS CodeBuild Führt Ihre Build-Befehle als Root-Benutzer aus. Dies passiert, auch wenn das Dockerfile des entsprechenden Build-Image die USER-Anweisungen auf einen anderen Benutzer umstellt.

Ursache: CodeBuild Führt standardmäßig alle Build-Befehle als Root-Benutzer aus.

Empfohlene Lösung: Keine.

Builds schlagen möglicherweise fehl, wenn Dateinamen nicht in den USA angegeben sind. Englische Schriftzeichen

Problem: Wenn Sie einen Build ausführen, der Dateien verwendet, deren Dateinamen nicht aus den USA stammen Englische Zeichen (z. B. chinesische Schriftzeichen) schlägt der Build fehl.

Mögliche Ursache: In Build-Umgebungen, die von AWS CodeBuild bereitgestellt werden, ist das Standardgebietsschema auf POSIX gesetzt. POSIXDie Lokalisierungseinstellungen sind weniger kompatibel mit CodeBuild Dateinamen, die nicht aus den USA stammen. Englische Zeichen und können dazu führen, dass verwandte Builds fehlschlagen.

Empfohlene Lösung: Fügen Sie die folgenden Befehle zum Abschnitt pre_build Ihrer Build-Spezifikationsdatei hinzu. Diese Befehle sorgen dafür, dass die Buildumgebung US-Englisch UTF -8 für ihre Lokalisierungseinstellungen verwendet, was besser mit CodeBuild Dateinamen kompatibel ist, die nicht in den USA vorkommen. Englische Schriftzeichen.

Für Build-Umgebungen basierend auf Ubuntu:

pre_build:
  commands:
    - export LC_ALL="en_US.UTF-8"
    - locale-gen en_US en_US.UTF-8
    - dpkg-reconfigure locales

Für Build-Umgebungen, die auf Amazon Linux basieren:

pre_build:
  commands:
    - export LC_ALL="en_US.utf8"

Builds schlagen möglicherweise fehl, wenn Parameter aus dem Amazon EC2 Parameter Store abgerufen werden

Problem: Wenn ein Build versucht, den Wert eines oder mehrerer im Amazon Parameter Store gespeicherter EC2 Parameter abzurufen, schlägt der Build in der DOWNLOAD_SOURCE Phase mit dem Fehler fehlParameter does not exist.

Mögliche Ursache: Die Servicerolle, auf die sich das Build-Projekt stützt, ist nicht berechtigt, die ssm:GetParameters Aktion aufzurufen, oder das Build-Projekt verwendet eine Servicerolle, die von der Aktion generiert wird AWS CodeBuild und den Aufruf der ssm:GetParameters Aktion ermöglicht, aber die Parameter haben Namen, die nicht mit beginnen/CodeBuild/.

Empfohlene Lösungen:

Auf den Zweigfilter in der CodeBuild Konsole kann nicht zugegriffen werden

Problem: Die Branch-Filter-Option ist in der Konsole nicht verfügbar, wenn Sie ein AWS CodeBuild Projekt erstellen oder aktualisieren.

Mögliche Ursache: Die Verzweigungsfilter-Option ist veraltet. Sie wurde durch Webhook-Filtergruppen ersetzt, die mehr Kontrolle über die Webhook-Ereignisse bieten, die einen neuen Build auslösen. CodeBuild

Empfohlene Lösung: Um einen Verzweigungsfilter zu migrieren, den Sie vor der Einführung von Webhook-Filtern erstellt haben, erstellen Sie eine Webhook-Filtergruppe mit einem HEAD_REF-Filter mit dem regulären Ausdruck ^refs/heads/branchName$. Wenn der reguläre Ausdruck Ihres Verzweigungsfilters beispielsweise ^branchName$ lautete, ist der aktualisierte reguläre Ausdruck, den Sie in den HEAD_REF-Filter eingeben, ^refs/heads/branchName$. Weitere Informationen erhalten Sie unter Bitbucket-Webhook-Ereignisse und GitHub Webhook-Ereignisse filtern (Konsole).

Erfolg oder Misserfolg der Build-Erstellung wird nicht angezeigt

Problem: Erfolg oder Misserfolg einer wiederholten Build-Erstellung wird nicht angezeigt.

Mögliche Ursache: Die Option zum Melden des Build-Status ist nicht aktiviert.

Empfohlene Lösungen: Aktivieren Sie die Option Build-Status melden, wenn Sie ein CodeBuild Projekt erstellen oder aktualisieren. Diese Option weist CodeBuild an, dass der Status gemeldet werden soll, wenn Sie einen Build auslösen. Weitere Informationen finden Sie reportBuildStatusin der AWS CodeBuild APIReferenz.

Der Build-Status wurde dem Quellanbieter nicht gemeldet

Problem: Nachdem die Berichterstattung über den Build-Status an einen Quellanbieter wie GitHub Bitbucket zugelassen wurde, wird der Build-Status nicht aktualisiert.

Mögliche Ursache: Der mit dem Quellanbieter verknüpfte Benutzer hat keinen Schreibzugriff auf das Repo.

Empfohlene Lösungen: Um dem Quellanbieter den Build-Status melden zu können, muss der mit dem Quellanbieter verknüpfte Benutzer Schreibzugriff auf das Repository haben. Wenn der Benutzer keinen Schreibzugriff hat, kann der Build-Status nicht aktualisiert werden. Weitere Informationen finden Sie unter Zugriff auf den Quellanbieter.

Das Basisimage der Windows Server Core 2019-Plattform kann nicht gefunden und ausgewählt werden

Problem: Sie können das Basisimage der Windows Server Core 2019-Plattform nicht finden oder auswählen.

Mögliche Ursache: Sie verwenden eine AWS Region, die dieses Image nicht unterstützt.

Empfohlene Lösungen: Verwenden Sie eine der folgenden AWS Regionen, in denen das Basisimage der Windows Server Core 2019-Plattform unterstützt wird:

Vorherige Befehle in den Build-Spezifikationsdateien werden von nachfolgenden Befehlen nicht erkannt

Problem: Die Ergebnisse von einem oder mehreren Befehlen in der Build-Spezifikationsdatei werden von nachfolgenden Befehlen in derselben Build-Spezifikationsdatei nicht erkannt. Beispielsweise legt ein Befehl eine lokale Umgebungsvariable fest, aber ein späterer Befehl ruft den Wert dieser lokalen Umgebungsvariable nicht ab.

Mögliche Ursache: In der Build-Spezifikationsdateiversion 0.1 führt AWS CodeBuild jeden Befehl in einer separaten Instance der Standard-Shell in der Build-Umgebung aus. d. h., dass jeder Befehl unabhängig von allen anderen Befehlen ausgeführt wird. Daher können Sie keinen Einzelbefehl ausführen, der auf dem Status eines vorherigen Befehls basiert.

Empfohlene Lösungen: Wir empfehlen die Verwendung der Build-Spezifikationsversion 0.2, die dieses Problem behebt. Falls Sie doch die Build-Spezifikationsversion 0.1 verwenden müssen, empfehlen wir die Verwendung des Shell-Befehlsverkettungsoperators (z. B. && in Linux), um mehrere Befehle zu einem einzigen Befehl zu kombinieren. Oder schließen Sie ein Shell-Skript in den Quellcode ein, das mehrere Befehle enthält, und rufen Sie dann dieses Shell-Skript über einen Einzelbefehl in der Build-Spezifikationsdatei auf. Weitere Informationen erhalten Sie unter Shells und Befehle in Build-Umgebungen und Umgebungsvariablen in Build-Umgebungen.

Fehler: „Access denied“ (Zugriff verweigert) beim Versuch, den Cache herunterzuladen

Problem: Beim Versuch, den Cache für ein Build-Projekt herunterzuladen, das den Cache aktiviert hat, wird eine Access denied-Fehlermeldung angezeigt.

Mögliche Ursachen:

Empfohlene Lösung: Bei der ersten Verwendung ist es normal, diese Fehlermeldung direkt nach der Aktualisierung der Cache-Konfiguration zu erhalten. Wenn das Problem weiterhin besteht, sollten Sie prüfen, ob Ihre Service-Rolle über die Berechtigungen s3:GetObject und s3:PutObject für den S3-Bucket verfügt, in dem sich der Cache befindet. Weitere Informationen finden Sie unter Spezifying S3 Permissions im Amazon S3 Developer Guide.

Fehler: "BUILD_ CONTAINER _ UNABLE _TO_ PULL _IMAGE" bei der Verwendung eines benutzerdefinierten Build-Images

Problem: Wenn Sie versuchen, Builds auszuführen, die benutzerdefinierte Build-Images verwenden, erhalten Sie die Fehlermeldung BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE.

Fehler: „Der Build-Container wurde vor Abschluss des Builds als tot befunden. Der Build-Container ist gestorben, weil nicht genügend Arbeitsspeicher zur Verfügung stand oder das Docker-Image nicht unterstützt wird. ErrorCode: 500"

Problem: Wenn Sie versuchen, einen Microsoft Windows- oder Linux-Container in zu verwenden AWS CodeBuild, tritt dieser Fehler während der PROVISIONING Phase auf.

Mögliche Ursachen:

Empfohlene Lösungen:

Fehler: „Es kann keine Verbindung mit dem Docker-Daemon hergestellt werden“ beim Ausführen eines Builds

Problem: Ihr Build ist nicht erfolgreich und Sie erhalten eine Fehlermeldung ähnlich Cannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running? im Build-Protokoll.

Mögliche Ursache: Sie führen den Build nicht im privilegierten Modus aus.

Empfohlene Lösung: Um diesen Fehler zu beheben, müssen Sie den privilegierten Modus aktivieren und Ihre Buildspec anhand der folgenden Anweisungen aktualisieren.

Gehen Sie folgendermaßen vor, um Ihren Build im privilegierten Modus auszuführen:

Sie müssen auch den Docker-Daemon in Ihrem Container starten. Die install Phase Ihrer Buildspec könnte in etwa so aussehen.

phases:
  install:
    commands:
      - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
      - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

Weitere Informationen über die OverlayFS-Speichertreiber, auf die in der Build-Spezifikationsdatei verwiesen wird, finden Sie auf der Docker-Website unter Verwenden des OverlayFS-Speichertreibers.

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

Weitere Informationen darüber, wie Sie mithilfe von ein Docker-Image erstellen und ausführen, finden Sie unter. AWS CodeBuildDocker im benutzerdefinierten Bildbeispiel für CodeBuild

Fehler: "CodeBuild ist nicht autorisiert, Folgendes auszuführen: sts:AssumeRole" beim Erstellen oder Aktualisieren eines Build-Projekts

Problem: Wenn Sie versuchen, ein Build-Projekt zu erstellen oder zu aktualisieren, wird der Fehler Code:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-name angezeigt.

Mögliche Ursachen:

Empfohlene Lösungen:

Fehler: „Fehler beim Aufrufen GetBucketAcl: Entweder hat sich der Bucket-Besitzer geändert oder die Servicerolle ist nicht mehr berechtigt, s3 aufzurufen:GetBucketAcl“

Problem: Ihnen wird beim Ausführen eines Builds eine Fehlermeldung in Bezug auf die Änderung eines S3-Bucket-Eigentümers und von GetBucketAcl-Berechtigungen angezeigt.

Mögliche Ursache: Sie haben die s3:GetBucketLocation Berechtigungen s3:GetBucketAcl und zu Ihrer IAM Rolle hinzugefügt. Diese Berechtigungen sichern den S3-Bucket Ihres Projekts und stellen Sie sicher, dass nur Sie Zugriff auf diesen haben. Nachdem Sie diese Berechtigungen hinzugefügt haben, hat sich der Besitzer des S3-Buckets geändert.

Empfohlene Lösung: Stellen Sie sicher, dass Sie der Besitzer des S3-Buckets sind, und fügen Sie Ihrer IAM Rolle dann erneut Berechtigungen hinzu. Weitere Informationen finden Sie unter Sicherer Zugriff auf S3-Buckets.

Fehler: „Failed to upload artifacts: Invalid arn” beim Ausführen eines Builds

Problem: Beim Ausführen eines Builds schlägt die Build-Phase UPLOAD_ARTIFACTS mit der Fehlermeldung Failed to upload artifacts: Invalid arn fehl.

Mögliche Ursache: Ihr S3-Ausgabe-Bucket (der Bucket, in dem die Ausgabe aus dem Build AWS CodeBuild gespeichert wird) befindet sich in einer anderen AWS Region als das CodeBuild Build-Projekt.

Empfohlene Lösung: Aktualisieren Sie die Einstellungen des Build-Projekts so, dass sie auf einen Ausgabe-Bucket verweisen, der sich in derselben AWS Region wie das Build-Projekt befindet.

Fehler: „Git-Klon fehlgeschlagen: Zugriff nicht möglich'your-repository-URL': SSL Zertifikatsproblem: Selbstsigniertes Zertifikat“

Problem: Beim Versuch, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursache: Ihr Quell-Repository verfügt über ein selbstsigniertes Zertifikat, Sie haben jedoch nicht angegeben, dass das Zertifikat aus Ihrem S3-Bucket als Teil Ihres Build-Projekts installiert werden soll.

Empfohlene Lösungen:

Fehler: „The bucket you are attempting to access must be addressed using the specified endpoint” beim Ausführen eines Builds

Problem: Beim Ausführen eines Builds schlägt die Build-Phase DOWNLOAD_SOURCE mit der Fehlermeldung The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint fehl.

Mögliche Ursache: Ihr vorgefertigter Quellcode ist in einem S3-Bucket gespeichert, und dieser Bucket befindet sich in einer anderen AWS Region als das AWS CodeBuild Build-Projekt.

Empfohlene Lösung: Aktualisieren Sie die Einstellungen des Build-Projekts, sodass diese auf einen Bucket verweisen, der Ihren vorgefertigten Quellcode enthält. Stellen Sie sicher, dass sich der Bucket in derselben AWS Region wie das Build-Projekt befindet.

Fehler: "This build image requires selecting at least one runtime version."

Problem: Beim Ausführen eines Builds schlägt die Build-Phase DOWNLOAD_SOURCE mit der Fehlermeldung YAML_FILE_ERROR: This build image requires selecting at least one runtime version fehl.

Mögliche Ursache: Ihr Build verwendet Version 1.0 oder höher des Amazon Linux 2 (AL2) -Standard-Images oder Version 2.0 oder höher des Ubuntu-Standard-Images, und in der Buildspec-Datei ist keine Laufzeit angegeben.

Empfohlene Lösung: Wenn Sie das aws/codebuild/standard:2.0 CodeBuild verwaltete Image verwenden, müssen Sie im runtime-versions Abschnitt der Buildspec-Datei eine Laufzeitversion angeben. Sie könnten beispielsweise die folgende Buildspec-Datei für ein Projekt verwenden, das Folgendes verwendet: PHP

version: 0.2

phases:
  install:
    runtime-versions:
        php: 7.3
  build:
    commands:
      - php --version
artifacts:
  files:
    -  README.md

Weitere Informationen finden Sie unter Specify runtime versions in the buildspec file.

Fehler: "QUEUED: INSUFFICIENT _SUBNET", wenn ein Build in einer Build-Warteschlange fehlschlägt

Problem: Ein Build in einer Build-Warteschlange schlägt fehl und es wird eine Fehlermeldung ähnlich wie QUEUED: INSUFFICIENT_SUBNET angezeigt.

Mögliche Ursachen: Der für Sie angegebene IPv4 CIDR Block VPC verwendet eine reservierte IP-Adresse. Die ersten vier IP-Adressen und die letzte IP-Adresse in jedem CIDR Subnetzblock stehen Ihnen nicht zur Verfügung und können keiner Instanz zugewiesen werden. In einem Subnetz mit CIDR Block sind 10.0.0.0/24 beispielsweise die folgenden fünf IP-Adressen reserviert:

Empfohlene Lösungen: Überprüfen Sie, ob Sie VPC eine reservierte IP-Adresse verwenden. Ersetzen Sie eine reservierte IP-Adresse durch eine IP-Adresse, die nicht reserviert ist. Weitere Informationen finden Sie unter VPCund zur Größe von Subnetzen im VPCAmazon-Benutzerhandbuch.

Fehler: „Cache konnte nicht heruntergeladen werden: RequestError: Die Anfrage konnte nicht gesendet werden, verursacht durch: x509: System-Roots konnten nicht geladen werden und es wurden keine Roots bereitgestellt“

Problem: Beim Versuch, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursache: Sie haben Caching als Teil Ihres Build-Projekts konfiguriert und verwenden ein älteres Docker-Image mit einem abgelaufenen Stammzertifikat.

Empfohlene Lösung: Aktualisieren Sie das Docker-Image, das in Ihrem AWS CodeBuild Projekt verwendet wird. Weitere Informationen finden Sie unter Docker-Images bereitgestellt von CodeBuild.

Fehler: „Das Zertifikat konnte nicht von S3 heruntergeladen werden. AccessDenied“

Problem: Beim Versuch, ein Build-Projekt auszuführen, schlägt der Build mit dieser Fehlermeldung fehl.

Mögliche Ursachen:

Empfohlene Lösungen:

Fehler: „Unable to locate credentials“

Problem: Wenn Sie versuchen AWS CLI, die Komponente auszuführen AWS SDK, eine zu verwenden oder eine andere ähnliche Komponente als Teil eines Builds aufzurufen, werden Build-Fehler angezeigt, die in direktem Zusammenhang mit der AWS CLI AWS SDK, oder -Komponente stehen. Sie könnten zum Beispiel eine Build-Fehlermeldung wie Unable to locate credentials erhalten.

Mögliche Ursachen:

Empfohlene Lösungen:

RequestError Timeout-Fehler bei der Ausführung auf CodeBuild einem Proxyserver

Problem: Sie erhalten eine RequestError-Fehlermeldung ähnlich einer der folgenden:

Mögliche Ursachen:

Empfohlene Lösungen:

Die Bourne-Shell (sh) muss in Build-Images vorhanden sein

Problem: Sie verwenden ein Build-Image, das nicht von bereitgestellt wird AWS CodeBuild, und Ihre Builds schlagen mit der Meldung fehlBuild container found dead before completing the build.

Mögliche Ursache: Die Bourne-Shell (sh) ist nicht in Ihrem Build-Image enthalten. CodeBuild shmuss Build-Befehle und -Skripte ausführen.

Empfohlene Lösung: Falls es nicht sh in Ihrem Build-Image vorhanden ist, fügen Sie es unbedingt hinzu, bevor Sie weitere Builds starten, die Ihr Image verwenden. (CodeBuild ist bereits sh in den Build-Images enthalten.)

Warnung: „Skipping install of runtimes. runtime version selection is not supported by this build image“ beim Ausführen eines Builds

Problem: Wenn Sie einen Build ausführen, enthält das Build-Protokoll diesen Warnhinweis.

Mögliche Ursache: Ihr Build verwendet keine Version 1.0 oder höher des Amazon Linux 2 (AL2) -Standard-Images oder Version 2.0 oder höher des Ubuntu-Standard-Images, und eine Laufzeit ist in einem runtime-versions Abschnitt in Ihrer Buildspec-Datei angegeben.

Empfohlene Lösung: Stellen Sie sicher, dass Ihre buildspec-Datei keinen runtime-versions-Abschnitt enthält. Der runtime-versions Abschnitt ist nur erforderlich, wenn Sie das Amazon Linux 2 (AL2) -Standard-Image oder höher oder das Ubuntu-Standard-Image Version 2.0 oder höher verwenden.

Fehler: „ JobWorker Identität konnte nicht verifiziert werden“ beim Öffnen der CodeBuild Konsole

Problem: Wenn Sie die CodeBuild Konsole öffnen, wird die Fehlermeldung „ JobWorker Identität konnte nicht verifiziert werden“ angezeigt.

Mögliche Ursache: Die IAM Rolle, die für den Konsolenzugriff verwendet wird, hat ein Tag mit jobId als Schlüssel. Dieser Tag-Schlüssel ist reserviert für CodeBuild und verursacht diesen Fehler, falls er vorhanden ist.

Empfohlene Lösung: Ändern Sie alle benutzerdefinierten IAM Rollen-Tags, die den Schlüssel enthaltenjobId, so, dass sie einen anderen Schlüssel haben, z. jobIdentifier B.

Build konnte nicht gestartet werden

Problem: Beim Starten eines Builds erhalten Sie die Fehlermeldung Build konnte nicht gestartet werden.

Mögliche Ursache: Die Anzahl gleichzeitiger Builds wurde erreicht.

Empfohlene Lösungen: Warten Sie, bis andere Builds abgeschlossen sind, oder erhöhen Sie das Limit für gleichzeitige Builds für das Projekt und starten Sie den Build erneut. Weitere Informationen finden Sie unter Konfiguration des Projekts.

Zugreifen auf GitHub Metadaten in lokal zwischengespeicherten Builds

Problem: In einigen Fällen ist das .git-Verzeichnis in einem zwischengespeicherten Build eine Textdatei und kein Verzeichnis.

Mögliche Ursachen: Wenn das lokale Quell-Caching für einen Build aktiviert ist, wird ein Gitlink für das Verzeichnis CodeBuild erstellt. .git Das bedeutet, dass das .git Verzeichnis tatsächlich eine Textdatei ist, die den Pfad zum Verzeichnis enthält.

Empfohlene Lösungen: Verwenden Sie in allen Fällen den folgenden Befehl, um das Git-Metadatenverzeichnis abzurufen. Dieser Befehl funktioniert unabhängig vom Format von.git:

git rev-parse --git-dir

AccessDenied: Der Bucket-Besitzer für die Berichtsgruppe stimmt nicht mit dem Besitzer des S3-Buckets überein...

Problem: Beim Hochladen von Testdaten in einen Amazon S3 S3-Bucket können die Testdaten nicht in den Bucket geschrieben werden. CodeBuild

Mögliche Ursachen:

Empfohlene Lösungen: