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 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 unter[Protokollierung und Überwachung](logging-monitoring.md). **Topics** + [Apache Maven erstellt Referenzartefakte aus dem falschen Repository](#troubleshooting-maven-repos) + [Build-Befehle werden standardmäßig als Root-Benutzer ausgeführt](#troubleshooting-root-build-commands) + [Builds schlagen möglicherweise fehl, wenn Dateinamen nicht in den USA angegeben sind. Englische Schriftzeichen](#troubleshooting-utf-8) + [Builds schlagen möglicherweise fehl, wenn Parameter aus dem Amazon EC2 Parameter Store abgerufen werden](#troubleshooting-parameter-store) + [Auf den Zweigfilter in der Konsole kann nicht zugegriffen werden CodeBuild](#troubleshooting-webhook-filter) + [Erfolg oder Misserfolg der Build-Erstellung wird nicht angezeigt](#no-status-when-build-triggered) + [Der Build-Status wurde nicht an den Quellanbieter gemeldet](#build-status-not-reported) + [Das Basisimage der Windows Server Core 2019-Plattform kann nicht gefunden und ausgewählt werden](#windows-image-not-available) + [Vorherige Befehle in den Build-Spezifikationsdateien werden von nachfolgenden Befehlen nicht erkannt](#troubleshooting-build-spec-commands) + [Fehler: „Access denied“ (Zugriff verweigert) beim Versuch, den Cache herunterzuladen](#troubleshooting-dependency-caching) + [Fehler: „BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE” bei der Verwendung eines benutzerdefinierten Build-Image](#troubleshooting-unable-to-pull-image) + [Fehler: „Der Build-Container wurde vor Abschluss des Builds als tot befunden. Der Build-Container ist abgestürzt, weil nicht genügend Arbeitsspeicher zur Verfügung stand oder das Docker-Image nicht unterstützt wird. ErrorCode: 500"](#windows-server-core-version) + [Fehler: „Es kann keine Verbindung mit dem Docker-Daemon hergestellt werden“ beim Ausführen eines Builds](#troubleshooting-cannot-connect-to-docker-daemon) + [Fehler: "CodeBuild ist nicht autorisiert, Folgendes auszuführen: sts:AssumeRole" beim Erstellen oder Aktualisieren eines Build-Projekts](#troubleshooting-assume-role) + [Fehler: „Fehler beim Aufrufen GetBucketAcl: Entweder hat sich der Bucket-Besitzer geändert oder die Servicerolle ist nicht mehr berechtigt, s3 aufzurufen:GetBucketAcl“](#troubleshooting-calling-bucket-error) + [Fehler: „Failed to upload artifacts: Invalid arn” beim Ausführen eines Builds](#troubleshooting-output-bucket-different-region) + [Fehler: „Git clone failed: Unable to access `'your-repository-URL'`: SSL certificate problem: Self signed certificate“](#troubleshooting-self-signed-certificate) + [Fehler: „The bucket you are attempting to access must be addressed using the specified endpoint” beim Ausführen eines Builds](#troubleshooting-input-bucket-different-region) + [Fehler: "This build image requires selecting at least one runtime version."](#troubleshooting-build-must-specify-runtime) + [Fehler: "QUEUED: INSUFFICIENT\$1SUBNET", wenn ein Build in einer Build-Warteschlange fehlschlägt](#queued-insufficient-subnet-error) + [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“](#troubleshooting-cache-image) + [Fehler: „Das Zertifikat konnte nicht von S3 heruntergeladen werden. AccessDenied“](#troubleshooting-certificate-in-S3) + [Fehler: „Unable to locate credentials“](#troubleshooting-versions) + [RequestError Timeout-Fehler bei der Ausführung auf CodeBuild einem Proxyserver](#code-request-timeout-error) + [Die Bourne-Shell (sh) muss in Build-Images vorhanden sein](#troubleshooting-sh-build-images) + [Warnung: „Skipping install of runtimes. runtime version selection is not supported by this build image“ beim Ausführen eines Builds](#troubleshooting-skipping-all-runtimes-warning) + [Fehler: „ JobWorker Identität konnte nicht verifiziert werden“ beim Öffnen der CodeBuild Konsole](#troubleshooting-unable-to-verify-jobworker) + [Build konnte nicht gestartet werden](#troubleshooting-build-failed-to-start) + [Zugreifen auf GitHub Metadaten in lokal zwischengespeicherten Builds](#troubleshooting-github-metadata) + [AccessDenied: Der Bucket-Besitzer für die Berichtsgruppe stimmt nicht mit dem Besitzer des S3-Buckets überein...](#troubleshooting-bucket-owner) + [Fehler: „Ihren Anmeldeinformationen fehlen ein oder mehrere erforderliche Rechtebereiche“ beim Erstellen eines CodeBuild Projekts mit CodeConnections](#troubleshooting-permission-bitbucket) + [Fehler: „Sorry, es wurde überhaupt kein Terminal angefordert — Eingabe kann nicht abgerufen werden“ beim Erstellen mit dem Ubuntu-Installationsbefehl](#troubleshooting-nvidia-container-toolkit) ## 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.](https://repo1.maven.org/maven2) 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 Namen`settings.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](https://repo1.maven.org/maven2) abzurufen. ``` securecentral securecentral central https://repo1.maven.org/maven2 true central https://repo1.maven.org/maven2 true ``` **Empfohlene Lösung:** Gehen Sie wie folgt vor: 1. Fügen Sie eine Datei `settings.xml` zu Ihrem Quellcode hinzu. 1. Verwenden Sie in dieser Datei `settings.xml` das oben angegebene Format für `settings.xml` als Richtlinie zur Deklaration der Repositorys, aus denen Maven stattdessen die Build- und Plugin-Abhängigkeiten abrufen soll. 1. Weisen Sie in der `install` Phase Ihres Build-Projekts CodeBuild an, Ihre `settings.xml` Datei in das Verzeichnis der Build-Umgebung zu kopieren. `/root/.m2` Ein Beispiel ist der folgende Codeausschnitt aus der Datei `buildspec.yml`, der dieses Verhalten veranschaulicht. ``` version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml ``` ## 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. `POSIX`Die 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 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 -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 Parameter abzurufen, die im Amazon EC2 Parameter Store gespeichert sind, schlägt der Build in der `DOWNLOAD_SOURCE` Phase mit dem Fehler `Parameter does not exist` fehl. **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 `/CodeBuild/` beginnen. **Empfohlene Lösungen:** + Wenn die Servicerolle nicht von generiert wurde CodeBuild, aktualisieren Sie ihre Definition, CodeBuild damit die `ssm:GetParameters` Aktion aufgerufen werden kann. Die folgende Richtlinienanweisung erlaubt es beispielsweise, die Aktion `ssm:GetParameters` auszuführen und Parameter, deren Namen mit `/CodeBuild/` beginnen, abzurufen: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/CodeBuild/*" } ] } ``` ------ + Wenn die Servicerolle von generiert wurde CodeBuild, aktualisieren Sie ihre Definition, um den Zugriff auf Parameter im Amazon EC2 Parameter Store mit anderen Namen als denen, die mit `/CodeBuild/` beginnen, zu ermöglichen CodeBuild . Die folgende Richtlinienanweisung erlaubt es beispielsweise, die Aktion `ssm:GetParameters` auszuführen und Parameter mit dem angegebenen Namen abzurufen: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/PARAMETER_NAME" } ] } ``` ------ ## Auf den Zweigfilter in der Konsole kann nicht zugegriffen werden CodeBuild **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 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](bitbucket-webhook.md) und [GitHub Webhook-Ereignisse filtern (Konsole)](github-webhook-events-console.md). ## 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](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-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](access-tokens.md). ## 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: + USA Ost (Nord-Virginia) + USA Ost (Ohio) + USA West (Oregon) + Europa (Irland) ## 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](build-env-ref-cmd.md) und [Umgebungsvariablen in Build-Umgebungen](build-env-ref-env-vars.md). ## 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:** + Sie haben gerade Caching als Teil Ihres Build-Projekts konfiguriert. + Der Cache wurde vor Kurzem durch die `InvalidateProjectCache`-API ungültig gemacht. + Die von verwendete Dienstrolle CodeBuild hat keine `s3:GetObject` `s3:PutObject` Berechtigungen für den S3-Bucket, der den Cache enthält. **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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html) im *Amazon S3 Developer Guide*. ## Fehler: „BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE” 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`. ***Mögliche Ursache:** Die unkomprimierte Gesamtgröße des Build-Images ist größer als der verfügbare Festplattenspeicher des Compute-Typs der Build-Umgebung. Zum Prüfen der Größe des Build-Image nutzen Sie Docker und führen den Befehl `docker images REPOSITORY:TAG` aus. Eine Liste der für die jeweiligen Datenverarbeitungstypen verfügbaren Speicherplätze finden Sie unter [Berechnungsmodi und Typen der Build-Umgebung](build-env-ref-compute-types.md).* **Empfohlene Lösung:** Verwenden Sie einen größeren Compute-Typ mit mehr verfügbarem Festplattenspeicher oder reduzieren Sie die Größe Ihres benutzerdefinierten Build-Images. ***Mögliche Ursache:** ist AWS CodeBuild nicht berechtigt, das Build-Image aus Ihrer Amazon Elastic Container Registry (Amazon ECR) abzurufen.* **Empfohlene Lösung:** Aktualisieren Sie die Berechtigungen in Ihrem Repository in Amazon ECR, sodass Ihr benutzerdefiniertes Build-Image in die Build-Umgebung abgerufen werden CodeBuild kann. Weitere Informationen hierzu finden Sie unter [Amazon ECR-Beispiel](sample-ecr.md). ***Mögliche Ursache:** Das von Ihnen angeforderte Amazon ECR-Bild ist in der AWS Region, die Ihr AWS Konto verwendet, nicht verfügbar. * **Empfohlene Lösung:** Verwenden Sie ein Amazon ECR-Image, das sich in derselben AWS Region befindet wie das, das Ihr AWS Konto verwendet. ***Mögliche Ursache:** Sie verwenden eine private Registrierung in einer VPC, die keinen öffentlichen Internetzugang hat. CodeBuild kann kein Image von einer privaten IP-Adresse in einer VPC abrufen. Weitere Informationen finden Sie unter [Privates Register mit AWS Secrets Manager Muster für CodeBuild](sample-private-registry.md). * **Empfohlene Lösung:** Wenn Sie eine private Registrierung in einer VPC verwenden, stellen Sie sicher, dass die VPC über einen öffentlichen Internetzugang verfügt. ***Mögliche Ursache:** Wenn die Fehlermeldung "**toomanyrequests**„enthält und das Image von Docker Hub abgerufen wurde, bedeutet dieser Fehler, dass das Docker Hub-Pulllimit erreicht wurde. * **Empfohlene Lösung:** Verwenden Sie eine private Docker Hub-Registrierung oder beziehen Sie Ihr Image von Amazon ECR. Weitere Informationen zur Verwendung einer privaten Registrierung finden Sie unter. [Privates Register mit AWS Secrets Manager Muster für CodeBuild](sample-private-registry.md) Weitere Informationen zur Verwendung von Amazon ECR finden Sie unter[Amazon ECR-Beispiel für CodeBuild](sample-ecr.md). ## Fehler: „Der Build-Container wurde vor Abschluss des Builds als tot befunden. Der Build-Container ist abgestürzt, 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:** + Die Container-Betriebssystemversion wird von CodeBuild nicht unterstützt. + `HTTP_PROXY`, `HTTPS_PROXY` oder beides werden im Container angegeben. **Empfohlene Lösungen:** + Verwenden Sie für Microsoft Windows einen Windows-Container mit einem Container-Betriebssystem (Version: microsoft/windowsservercore:10.0.x (for example, microsoft/windowsservercore 10.0.14393.2125). + Löschen Sie für Linux die `HTTP_PROXY`- und `HTTPS_PROXY`-Einstellungen in Ihrem Docker Image oder geben Sie die VPC-Konfiguration in Ihrem Build-Projekt an. ## 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: 1. Öffnen Sie die CodeBuild Konsole unter [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/). 1. Wählen Sie im Navigationsbereich **Build projects** und dann Ihr Build-Projekt aus. 1. Wählen Sie in **Edit (Bearbeiten)** **Environment (Umgebung)** aus. 1. Wählen Sie **Additional configuration (Zusätzliche Konfiguration)**. 1. Wählen Sie unter **Privilegiert** die Option **Dieses Flag aktivieren aus, wenn Sie Docker-Images erstellen oder Ihren Builds erweiterte Rechte gewähren möchten**. . 1. Wählen Sie **Update environment (Umgebung aktualisieren)**. 1. Wählen Sie **Start build (Build starten)** aus, um erneut zu versuchen, den Build zu erstellen. 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](https://docs.docker.com/storage/storagedriver/overlayfs-driver/). **Anmerkung** Wenn das Basis-Betriebssystem Alpine Linux ist,fügen Sie in `buildspec.yml` das Argument `-t` zu `timeout` hinzu: ``` - 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 CodeBuild[Docker im benutzerdefinierten Bildbeispiel für CodeBuild](sample-docker-custom-image.md) ## 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:** + Das AWS -Security-Token-Service (AWS STS) wurde für die AWS Region deaktiviert, in der Sie versuchen, das Build-Projekt zu erstellen oder zu aktualisieren. + Die dem Build-Projekt zugeordnete AWS CodeBuild Servicerolle ist nicht vorhanden oder verfügt nicht über ausreichende CodeBuild vertrauenswürdige Berechtigungen. + Die dem Build-Projekt zugeordnete Groß- und Kleinschreibung der AWS CodeBuild Servicerolle stimmt nicht mit der tatsächlichen IAM-Rolle überein. **Empfohlene Lösungen:** + Stellen Sie sicher, dass AWS STS es für die AWS Region aktiviert ist, in der Sie versuchen, das Build-Projekt zu erstellen oder zu aktualisieren. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Aktivierung und Deaktivierung AWS STS in einer AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html). + Stellen Sie sicher, dass die CodeBuild Ziel-Servicerolle in Ihrem AWS Konto vorhanden ist. Wenn Sie nicht die Konsole verwenden, achten Sie darauf, dass Sie den Amazon-Ressourcenname (ARN) der Servicerolle beim Erstellen oder Aktualisieren des Build-Projekts richtig geschrieben haben. Beachten Sie, dass bei IAM-Rollen zwischen Groß- und Kleinschreibung unterschieden wird. Vergewissern Sie sich daher, dass die Groß- und Kleinschreibung der IAM-Rolle korrekt ist. + Stellen Sie sicher, dass die CodeBuild Zieldienstrolle über ausreichende vertrauenswürdige Berechtigungen verfügt. CodeBuild Weitere Informationen finden Sie in der Vertrauensbeziehung-Richtlinienanweisung unter [Erlauben CodeBuild Sie die Interaktion mit anderen Diensten AWS](setting-up-service-role.md). ## 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](auth-and-access-control-iam-access-control-identity-based.md#secure-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:** + Bearbeiten Sie Ihr Projekt. Für **Certificate** wählen Sie **Install certificate from S3**. Für **Bucket of certificate** wählen Sie den S3-Bucket, in dem Ihr SSL-Zertifikat gespeichert ist. Für **Object key of certificate (Objektschlüssel des Zertifikats)** geben Sie den Namen Ihres S3-Objektschlüssels ein. + Bearbeiten Sie Ihr Projekt. Wählen Sie **Unsicheres SSL, um SSL-Warnungen** zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise Server-Projekt-Repository herstellen. **Anmerkung** Wir empfehlen, dass Sie **Insecure SSL** nur für Tests verwenden. Es sollte nicht in einer Produktionsumgebung verwendet werden. ## 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 ``` **Anmerkung** Wenn Sie einen `runtime-versions` Abschnitt angeben und ein anderes Image als Ubuntu Standard Image 2.0 oder höher oder das Amazon Linux 2 (AL2) Standard Image 1.0 oder höher verwenden, gibt der Build die Warnung "“ aus`Skipping install of runtimes. Runtime version selection is not supported by this build image`. Weitere Informationen finden Sie unter [Specify runtime versions in the buildspec file](build-spec-ref.md#runtime-versions-buildspec-file). ## Fehler: "QUEUED: INSUFFICIENT\$1SUBNET", 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: + `10.0.0.0:`: Netzwerkadresse. + `10.0.0.1`: Reserviert von AWS für den VPC-Router. + `10.0.0.2`: Reserviert von AWS. Die IP-Adresse des DNS-Servers ist immer die Basis des VPC-Netzwerk-Bereichs plus zwei. Wir reservieren jedoch auch die Basis jedes Subnetzbereichs plus zwei. VPCs Bei mehreren CIDR-Blöcken befindet sich die IP-Adresse des DNS-Servers im primären CIDR. Weitere Informationen finden Sie unter [Amazon-DNS-Server](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS) im *Amazon-VPC-Benutzerhandbuch*. + `10.0.0.3`: Reserviert von AWS für die future Verwendung. + `10.0.0.255`: Broadcast Adresse des Netzwerks. Wir unterstützen keinen Broadcast in eine VPC. Diese Adresse ist 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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing) 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](build-env-ref-available.md). ## 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:** + Sie haben den falschen S3-Bucket für Ihr Zertifikat gewählt. + Sie haben den falschen Objektschlüssel für Ihr Zertifikat eingegeben. **Empfohlene Lösungen:** + Bearbeiten Sie Ihr Projekt. Für **Bucket of certificate** wählen Sie den S3-Bucket, in dem Ihr SSL-Zertifikat gespeichert ist. + Bearbeiten Sie Ihr Projekt. Für **Object key of certificate (Objektschlüssel des Zertifikats)** geben Sie den Namen Ihres S3-Objektschlüssels ein. ## 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:** + Die Version des AWS CLI AWS SDK oder der Komponente in der Build-Umgebung ist nicht kompatibel mit AWS CodeBuild. + Sie führen einen Docker-Container in einer Build-Umgebung aus, die Docker verwendet, und der Container hat standardmäßig keinen Zugriff auf die AWS Anmeldeinformationen. **Empfohlene Lösungen:** + Stellen Sie sicher, dass Ihre Build-Umgebung über die folgende Version oder höher des AWS CLI AWS SDK oder der Komponente verfügt. + AWS CLI: 1.10.47 + AWS SDK for C\$1\$1: 0.2.19 + AWS SDK for Go: 1.2.5 + AWS SDK for Java: 1.11.16 + AWS SDK für JavaScript: 2.4.7 + AWS SDK for PHP: 3.18.28 + AWS SDK for Python (Boto3): 1.4.0 + AWS SDK for Ruby: 2.3.22 + Botocore: 1.4.37 + CoreCLR: 3.2.6-beta + Node.js: 2.4.7 + Wenn Sie einen Docker-Container in einer Build-Umgebung ausführen müssen und für den Container AWS Anmeldeinformationen erforderlich sind, müssen Sie die Anmeldeinformationen von der Build-Umgebung an den Container weitergeben. Fügen Sie in Ihrer Build-Spezifikationsdatei wie in dem nachfolgenden Beispiel einen Docker-`run`-Befehl ein. In diesem Beispiel werden die verfügbaren S3-Buckets mit dem `aws s3 ls` Befehl aufgeführt. Die `-e` Option durchläuft die Umgebungsvariablen, die Ihr Container für den Zugriff auf die AWS Anmeldeinformationen benötigt. ``` docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls ``` + Wenn Sie ein Docker-Image erstellen und für den Build AWS Anmeldeinformationen erforderlich sind (z. B. um eine Datei von Amazon S3 herunterzuladen), müssen Sie die Anmeldeinformationen aus der Build-Umgebung wie folgt an den Docker-Build-Prozess übergeben. 1. Geben Sie in Ihrem Quellcode für das Dockerfile des Docker-Image die folgenden `ARG`-Anweisungen ein. ``` ARG AWS_DEFAULT_REGION ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ``` 1. Fügen Sie in Ihrer Build-Spezifikationsdatei wie in dem nachfolgenden Beispiel einen Docker-`build`-Befehl ein. Die `--build-arg` Optionen legen die Umgebungsvariablen fest, die Ihr Docker-Build-Prozess für den Zugriff auf die Anmeldeinformationen benötigt. AWS ``` docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag . ``` ## RequestError Timeout-Fehler bei der Ausführung auf CodeBuild einem Proxyserver **Problem:** Sie erhalten eine `RequestError`-Fehlermeldung ähnlich einer der folgenden: + `RequestError: send request failed caused by: Post https://logs..amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout`aus CloudWatch Protokollen. + `Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refused`von Amazon S3. **Mögliche Ursachen:** + `ssl-bump` ist nicht ordnungsgemäß konfiguriert. + Die Sicherheitsrichtlinie Ihrer Organisation lässt nicht zu, dass Sie `ssl_bump` verwenden. + Für Ihre Buildspec-Datei sind keine Proxy-Einstellungen mit einem `proxy` -Element angegeben. **Empfohlene Lösungen:** + Stellen Sie sicher, dass `ssl-bump` korrekt konfiguriert ist. Wenn Sie Squid als Proxy-Server verwenden, beachten Sie die Informationen im Abschnitt [Konfigurieren von Squid als expliziter Proxy-Server](run-codebuild-in-explicit-proxy-server.md#use-proxy-server-explicit-squid-configure). + Gehen Sie wie folgt vor, um private Endpunkte für Amazon S3 und CloudWatch Logs zu verwenden: 1. Entfernen Sie in der Routing-Tabelle Ihres privaten Subnetzes die von Ihnen hinzugefügte Regel, die für das Internet bestimmten Datenverkehr an Ihren Proxy-Server weiterleitet. Weitere Informationen finden Sie unter [Erstellen eines Subnetzes in Ihrer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet) im *Amazon VPC-Benutzerhandbuch*. 1. Erstellen Sie einen privaten Amazon S3 S3-Endpunkt und einen CloudWatch Logs-Endpunkt und verknüpfen Sie sie mit dem privaten Subnetz Ihrer Amazon VPC. Weitere Informationen finden Sie unter [VPC-Endpunktdienste](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) im *Amazon VPC-Benutzerhandbuch*. 1. Vergewissern Sie sich, dass „**Privaten DNS-Namen in Ihrer Amazon VPC aktivieren**“ ausgewählt ist. Weitere Informationen finden Sie unter [Erstellung eines Schnittstellenendpunkts](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) im *Benutzerhandbuch für Amazon VPC*. + Wenn Sie für einen expliziten Proxy-Server kein `ssl-bump` verwenden, fügen Sie Ihrer Buildspec-Datei mithilfe eines `proxy` -Elements eine Proxy-Konfiguration hinzu. Weitere Informationen erhalten Sie unter [CodeBuild Auf einem expliziten Proxyserver ausführen](run-codebuild-in-explicit-proxy-server.md) und [Syntax der Build-Spezifikation](build-spec-ref.md#build-spec-ref-syntax). ``` version: 0.2 proxy: upload-artifacts: yes logs: yes phases: build: commands: ``` ## 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 `sh`muss 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](create-project.md#create-project-console-project-config). ## 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:** + Das für den Bucket-Besitzer der Berichtsgruppe angegebene Konto stimmt nicht mit dem Besitzer des Amazon S3 S3-Buckets überein. + Die Servicerolle hat keinen Schreibzugriff auf den Bucket. **Empfohlene Lösungen:** + Ändern Sie den Besitzer des Berichtsgruppen-Buckets so, dass er dem Besitzer des Amazon S3 S3-Buckets entspricht. + Ändern Sie die Servicerolle, um Schreibzugriff auf den Amazon S3 S3-Bucket zu ermöglichen. ## 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:** + Der neue Berechtigungsbereich wurde möglicherweise in deinem Bitbucket-Konto nicht akzeptiert. **Empfohlene Lösungen:** + Um die neue Erlaubnis zu akzeptieren, solltest du von Bitbucket eine E-Mail mit dem Betreff „**Aktion erforderlich — Geltungsbereiche für AWS CodeStar haben sich geändert**“ erhalten haben. `notifications-noreply@bitbucket.org` Die E-Mail enthält einen Link, über den du die Webhook-Berechtigungen für deine bestehende CodeConnections Bitbucket-App-Installation gewähren kannst. + Wenn du die E-Mail nicht finden kannst, kannst du die Erlaubnis erteilen, indem du zu oder navigierst `https://bitbucket.org/site/addons/reauthorize?addon_key=aws-codestar` und den Workspace auswählst`https://bitbucket.org/site/addons/reauthorize?account=&addon_key=aws-codestar`, dem du die Webhook-Berechtigung erteilen möchtest. ![\[Erteile deinem Workspace die Webhook-Berechtigung.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/bitbucket-csc.png) ## 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](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html#installing-with-apt). 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.