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 Build-Umgebung für ihre Lokalisierungseinstellungen US-Englisch UTF-8 verwendet, was besser mit CodeBuild Dateinamen kompatibel ist, die nicht in den USA vorkommen. Englische Zeichen.

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 -f noninteractive 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:

Zugriff auf Verzweigungsfilter in der CodeBuild -Konsole nicht möglich

Problem: Die Zweigfilteroption 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 eine bessere Kontrolle über die Webhook-Ereignisse bieten, die einen neuen CodeBuild-Build auslösen.

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 Buildstatus melden, wenn Sie ein CodeBuild Projekt erstellen oder aktualisieren. Diese Option weist CodeBuild an, den Status zurückzugeben, wenn Sie eine Build-Erstellung auslösen. Weitere Informationen finden Sie unter reportBuildStatus in der AWS CodeBuild -API-Referenz.

Der Build-Status wurde nicht an den Quellanbieter 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-Image

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 zum Erstellen und Ausführen eines Docker-Images mithilfe von AWS CodeBuildDocker im benutzerdefinierten Bildbeispiel für CodeBuild

Fehler: "CodeBuild ist nicht berechtigt, 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 Ihrer IAM-Rolle die s3:GetBucketLocation Berechtigungen s3:GetBucketAcl und 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 dann Ihrer IAM-Rolle 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 clone failed: Unable to access 'your-repository-URL': SSL certificate problem: Self signed certificate“

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önnen beispielsweise die folgende Build-Spezifikationsdatei für ein Projekt mit PHP verwenden:

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 Ihre VPC angegebene IPv4 CIDR-Block verwendet eine reservierte IP-Adresse. Die ersten vier sowie auch die letzte IP-Adresse in jedem Subnetz CIDR-Block stehen nicht zu Ihrer Verfügung und können daher keiner Instance zugewiesen werden. So sind beispielsweise in einem Subnetz mit dem CIDR-Block 10.0.0.0/24 die folgenden fünf IP-Adressen reserviert:

Empfohlene Lösungen: Überprüfen Sie, ob Ihre VPC eine reservierte IP-Adresse verwendet. Ersetzen Sie eine reservierte IP-Adresse durch eine IP-Adresse, die nicht reserviert ist. Weitere Informationen finden Sie unter Dimensionierung der VPC und der Subnetze im Amazon VPC 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, das SDK auszuführen, ein AWS SDK zu verwenden oder eine andere ähnliche Komponente als Teil eines Builds aufzurufen, werden Build-Fehler angezeigt, die in direktem Zusammenhang mit dem AWS CLI AWS SDK oder der 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 Build container found dead before completing the build fehl.

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 jobId enthalten, so, dass sie einen anderen Schlüssel haben, z. B. jobIdentifier

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:

Fehler: „Ihren Anmeldeinformationen fehlen ein oder mehrere erforderliche Rechtebereiche“ beim Erstellen eines CodeBuild Projekts mit CodeConnections

Problem: Wenn du ein CodeBuild Projekt mit erstellst CodeConnections, bist du nicht berechtigt, einen Bitbucket-Webhook zu installieren.

Mögliche Ursachen:

Empfohlene Lösungen:

Fehler: „Sorry, es wurde überhaupt kein Terminal angefordert — Eingabe kann nicht abgerufen werden“ beim Erstellen mit dem Ubuntu-Installationsbefehl

Problem: Wenn Sie Builds mit GPU-Container-Rechten ausführen, installieren Sie möglicherweise das NVIDIA Container Toolkit gemäß diesem Verfahren. In der neuesten CodeBuild Image-Version wird Docker mit dem nvidia-container-toolkit neuesten und kuratierten Image CodeBuild vorinstalliert amazonlinux und ubuntu konfiguriert. Wenn Sie dieses Verfahren befolgen, schlagen Builds mit dem Ubuntu-Installationsbefehl fehl und es wird der folgende Fehler angezeigt:

Running command curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor --no-tty -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
gpg: Sorry, no terminal at all requested - can't get input
curl: (23) Failed writing body

Mögliche Ursachen: Der GPG-Schlüssel ist bereits an derselben Stelle vorhanden.

Empfohlene Lösungen: Der nvidia-container-toolkit ist bereits im Image installiert. Wenn Sie diesen Fehler sehen, können Sie die Installation überspringen und den Docker-Prozess in Ihrer Buildspec neu starten.