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. # Erstellen Sie ein Build-Projekt in AWS CodeBuild Sie können die AWS CodeBuild Konsole oder verwenden AWS CLI, AWS SDKs um ein Build-Projekt zu erstellen. **Topics** + [Voraussetzungen](#create-project-prerequisites) + [Erstellen Sie ein Build-Projekt (Konsole)](#create-project-console) + [Erstellen eines Build-Projekts (AWS CLI)](#create-project-cli) + [Erstellen eines Build-Projekts (AWS SDKs)](#create-project-sdks) + [Erstellen eines Build-Projekts (CloudFormation)](#create-project-cloud-formation) ## Voraussetzungen Bevor Sie ein Build-Projekt erstellen, beantworten Sie die Fragen unter[Planen eines Builds](planning.md). ## Erstellen Sie ein Build-Projekt (Konsole) Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home). Wenn eine CodeBuild Informationsseite angezeigt wird, wählen Sie Build-Projekt **erstellen**. Erweitern Sie andernfalls im Navigationsbereich **Build**, wählen Sie **Build projects** und dann **Create build project** aus. Wählen Sie **Create build project (Build-Projekt erstellen)** aus. Füllen Sie die folgenden Abschnitte aus. Wenn Sie fertig sind, wählen Sie unten auf der Seite die Option **Build-Projekt erstellen** aus. **Topics** + [Konfiguration des Projekts](#create-project-console-project-config) + [Quelle](#create-project-console-source) + [Umgebung](#create-project-console-environment) + [Buildspec](#create-project-console-buildspec) + [Batch-Konfiguration](#create-project-console-batch-config) + [-Artefakte](#create-project-console-artifacts) + [Logs (Protokolle)](#create-project-console-logs) ### Konfiguration des Projekts **Project name** Geben Sie einen Namen für dieses Build-Projekt ein. Die Namen der Build-Projekte müssen für jedes AWS Konto eindeutig sein. **Beschreibung** Geben Sie optional eine Beschreibung des Build-Projekts ein, damit andere Benutzer verstehen, wofür dieses Projekt verwendet wird. **Badge erstellen** (Optional) Wählen Sie **Build-Badge aktivieren** aus, um den Build-Status Ihres Projekts sichtbar und einbettbar zu machen. Weitere Informationen finden Sie unter [Build Badges-Beispiel](sample-build-badges.md). Das Build-Badge gilt nicht, wenn Ihr Quellanbieter Amazon S3 ist. **Aktivieren Sie das Limit für gleichzeitige Builds** (Optional) Wenn Sie die Anzahl der gleichzeitigen Builds für dieses Projekt einschränken möchten, führen Sie die folgenden Schritte aus: 1. Wählen Sie „**Anzahl gleichzeitiger Builds einschränken“, die mit diesem Projekt gestartet werden können**. 1. Geben Sie im Feld **Limit für gleichzeitige Builds** die maximale Anzahl gleichzeitiger Builds ein, die für dieses Projekt zulässig sind. Dieses Limit darf nicht höher sein als das Limit für gleichzeitige Builds, das für das Konto festgelegt wurde. Wenn Sie versuchen, eine Zahl einzugeben, die über dem Kontolimit liegt, wird eine Fehlermeldung angezeigt. Neue Builds werden nur gestartet, wenn die aktuelle Anzahl der Builds dieses Limit unterschreitet oder ihm entspricht. Wenn die aktuelle Build-Anzahl dieses Limit erreicht, werden neue Builds gedrosselt und nicht ausgeführt. **Zusätzliche Informationen** (Optional) Geben Sie für **Tags** den Namen und den Wert aller Tags ein, die von den unterstützenden AWS Diensten verwendet werden sollen. Verwenden Sie **Add row**, um ein Tag hinzuzufügen. Sie können bis zu 50 Tags hinzufügen. ### Quelle **Quellanbieter** Wählen Sie den Typ des Quellcode-Anbieters. Verwenden Sie die folgenden Listen, um die für Ihren Quellanbieter geeignete Auswahl zu treffen: CodeBuild unterstützt Bitbucket Server nicht. ------ #### [ Amazon S3 ] **Bucket** Wählen Sie den Namen des Eingabe-Buckets, der den Quellcode enthält. **S3-Objektschlüssel oder S3-Ordner** Geben Sie den Namen der ZIP-Datei oder den Pfad zu dem Ordner ein, der den Quellcode enthält. Geben Sie einen Vorwärtsschrägstrich (/) ein, um den gesamten Inhalt im S3-Bucket herunterzuladen. **Quellversion** Geben Sie die Versions-ID des Objekts ein, das den Build Ihrer Eingabedatei darstellt. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). ------ #### [ CodeCommit ] **Repository** Wählen Sie das Repository aus, das Sie verwenden möchten. **Art der Referenz** Wählen Sie **Branch**, **Git-Tag** oder **Commit ID**, um die Version Ihres Quellcodes anzugeben. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie aus, ob Sie einen flachen Klon erstellen möchten, dessen Verlauf auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Git-Submodule** Wählen Sie **Use Git submodules (Git-Untermodule verwenden)** aus, wenn Ihr Repository Git-Untermodule enthalten soll. ------ #### [ Bitbucket ] **Berechtigungsnachweis** Wählen Sie **Standard-Quellanmeldedaten** oder **Benutzerdefinierte Quellanmeldedaten und** folgen Sie den Anweisungen, um die Standard-Quellanmeldedaten zu verwalten oder die Quellanmeldedaten anzupassen. **Art der Verbindung** Wählen Sie **CodeConnections**, **OAuth**, **App-Passwort** oder **persönliches Zugriffstoken**, mit dem Sie eine Verbindung herstellen möchten CodeBuild. **Connection (Verbindung)** Wählen Sie eine Bitbucket-Verbindung oder ein Secrets Manager Manager-Secret aus, um eine Verbindung über den angegebenen Verbindungstyp herzustellen. **Repository** Wähle **Repository in meinem Bitbucket-Konto** oder **Öffentliches Repository** und gib die Repository-URL ein. **Quellversion** Geben Sie einen Zweig, eine Commit-ID, ein Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md) Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie **Git clone depth (Git-Klontiefe)** aus, um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Git-Submodule** Wählen Sie **Use Git submodules (Git-Untermodule verwenden)** aus, wenn Ihr Repository Git-Untermodule enthalten soll. **Build-Status** Wählen Sie **Build-Status beim Start und Ende Ihrer Builds an den Quellanbieter melden**, wenn Sie möchten, dass der Status des Beginns und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird. Um dem Quellanbieter den Buildstatus 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). Geben Sie für **den Statuskontext** den Wert ein, der für den `name` Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter [Build](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build) in der Bitbucket-API-Dokumentation. Geben Sie **unter Ziel-URL** den Wert ein, der für den `url` Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter [Build](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build) in der Bitbucket-API-Dokumentation. Der Status eines durch einen Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder eines API-Aufrufs an den Quellanbieter gemeldet wird, müssen Sie diese Einstellung auswählen. Wenn die Builds Ihres Projekts durch einen Webhook ausgelöst werden, müssen Sie einen neuen Commit an das Repo übertragen, damit eine Änderung an dieser Einstellung wirksam wird. Wählen Sie **unter Primäre Quell-Webhook-Ereignisse** die Option **Jedes Mal neu erstellen, wenn eine Codeänderung in dieses Repository übertragen wird**, wenn Sie den Quellcode jedes Mal erstellen CodeBuild möchten, wenn eine Codeänderung in dieses Repository übertragen wird. Weitere Hinweise zu Webhooks und Filtergruppen finden Sie unter. [Bitbucket-Webhook-Ereignisse](bitbucket-webhook.md) ------ #### [ GitHub ] **Berechtigungsnachweis** Wählen Sie **Standard-Quellanmeldedaten** oder **Benutzerdefinierte Quellanmeldedaten und** folgen Sie den Anweisungen, um die Standard-Quellanmeldedaten zu verwalten oder die Quellanmeldedaten anzupassen. **Art der Verbindung** Wählen Sie **GitHub App **OAuth****, oder **Persönliches Zugriffstoken**, mit dem Sie eine Verbindung herstellen möchten CodeBuild. **Connection (Verbindung)** Wählen Sie eine GitHub Verbindung oder ein Secrets Manager Manager-Geheimnis aus, um eine Verbindung über den angegebenen Verbindungstyp herzustellen. **Repository** Wählen Sie „**Repository in meinem GitHub Konto**“, „**Öffentliches Repository**“ oder „**Webhook mit GitHub Gültigkeitsbereich**“ und geben Sie die Repository-URL ein. **Quellversion** Geben Sie einen Zweig, eine Commit-ID, ein Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md) Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie **Git clone depth (Git-Klontiefe)** aus, um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Git-Submodule** Wählen Sie **Use Git submodules (Git-Untermodule verwenden)** aus, wenn Ihr Repository Git-Untermodule enthalten soll. **Build-Status** Wählen Sie **Build-Status beim Start und Ende Ihrer Builds an den Quellanbieter melden**, wenn Sie möchten, dass der Status des Beginns und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird. Um dem Quellanbieter den Buildstatus 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). Geben Sie für **den Statuskontext** den Wert ein, der für den `context` Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie im GitHub Entwicklerhandbuch unter [Einen Commit-Status erstellen](https://developer.github.com/v3/repos/statuses/#create-a-commit-status). Geben Sie für **Ziel-URL** den Wert ein, der für den `target_url` Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie im GitHub Entwicklerhandbuch unter [Einen Commit-Status erstellen](https://developer.github.com/v3/repos/statuses/#create-a-commit-status). Der Status eines durch einen Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder eines API-Aufrufs an den Quellanbieter gemeldet wird, müssen Sie diese Einstellung auswählen. Wenn die Builds Ihres Projekts durch einen Webhook ausgelöst werden, müssen Sie einen neuen Commit an das Repo übertragen, damit eine Änderung an dieser Einstellung wirksam wird. Wählen Sie **unter Primäre Quell-Webhook-Ereignisse** die Option **Jedes Mal neu erstellen, wenn eine Codeänderung in dieses Repository übertragen wird**, wenn Sie den Quellcode jedes Mal erstellen CodeBuild möchten, wenn eine Codeänderung in dieses Repository übertragen wird. Weitere Hinweise zu Webhooks und Filtergruppen finden Sie unter. [GitHub Webhook-Ereignisse](github-webhook.md) ------ #### [ GitHub Enterprise Server ] **Berechtigungsnachweis** Wählen Sie **Standard-Quellanmeldedaten** oder **Benutzerdefinierte Quellanmeldedaten und** folgen Sie den Anweisungen, um die Standard-Quellanmeldedaten zu verwalten oder die Quellanmeldedaten anzupassen. **Art der Verbindung** Wählen Sie **CodeConnections**oder **Persönliches Zugriffstoken**, mit dem Sie eine Verbindung herstellen möchten CodeBuild. **Connection (Verbindung)** Wählen Sie eine GitHub Enterprise-Verbindung oder ein Secrets Manager Manager-Geheimnis aus, um eine Verbindung über den angegebenen Verbindungstyp herzustellen. **Repository** Wählen Sie **Repository in meinem GitHub Unternehmenskonto** oder **Webhook mit GitHub Unternehmensbereich** und geben Sie die Repository-URL ein. **Quellversion** Geben Sie eine Pull-Anfrage, einen Branch, eine Commit-ID, ein Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie **Git clone depth (Git-Klontiefe)** aus, um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Git-Submodule** Wählen Sie **Use Git submodules (Git-Untermodule verwenden)** aus, wenn Ihr Repository Git-Untermodule enthalten soll. **Build-Status** Wählen Sie **Build-Status beim Start und Ende Ihrer Builds an den Quellanbieter melden**, wenn Sie möchten, dass der Status des Beginns und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird. Um dem Quellanbieter den Buildstatus 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). Geben Sie für **den Statuskontext** den Wert ein, der für den `context` Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie im GitHub Entwicklerhandbuch unter [Einen Commit-Status erstellen](https://developer.github.com/v3/repos/statuses/#create-a-commit-status). Geben Sie für **Ziel-URL** den Wert ein, der für den `target_url` Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie im GitHub Entwicklerhandbuch unter [Einen Commit-Status erstellen](https://developer.github.com/v3/repos/statuses/#create-a-commit-status). Der Status eines durch einen Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder eines API-Aufrufs an den Quellanbieter gemeldet wird, müssen Sie diese Einstellung auswählen. Wenn die Builds Ihres Projekts durch einen Webhook ausgelöst werden, müssen Sie einen neuen Commit an das Repo übertragen, damit eine Änderung an dieser Einstellung wirksam wird. **Unsicheres SSL** Wählen Sie **Unsicheres SSL aktivieren, um SSL-Warnungen** zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise-Projekt-Repository herstellen. Wählen Sie **unter Primäre Quell-Webhook-Ereignisse** die Option **Jedes Mal neu erstellen, wenn eine Codeänderung in dieses Repository übertragen wird**, wenn Sie den Quellcode jedes Mal neu erstellen CodeBuild möchten, wenn eine Codeänderung in dieses Repository übertragen wird. Weitere Hinweise zu Webhooks und Filtergruppen finden Sie unter. [GitHub Webhook-Ereignisse](github-webhook.md) ------ #### [ GitLab ] **Berechtigungsnachweis** Wählen Sie **Standard-Quellanmeldedaten** oder **Benutzerdefinierte Quellanmeldedaten und** folgen Sie den Anweisungen, um die Standard-Quellanmeldedaten zu verwalten oder die Quellanmeldedaten anzupassen. **Art der Verbindung** **CodeConnections**wird verwendet, um eine Verbindung GitLab herzustellen CodeBuild. **Connection (Verbindung)** Wählen Sie eine GitLab Verbindung aus, über die eine Verbindung hergestellt werden soll CodeConnections. **Repository** Wählen Sie das Repository aus, das Sie verwenden möchten. **Quellversion** Geben Sie eine Pull-Request-ID, einen Branch, eine Commit-ID, ein Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie **Git clone depth (Git-Klontiefe)** aus, um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Build-Status** Wählen Sie **Build-Status beim Start und Ende Ihrer Builds an den Quellanbieter melden**, wenn Sie möchten, dass der Status des Beginns und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird. Um dem Quellanbieter den Buildstatus 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). ------ #### [ GitLab Self Managed ] **Berechtigungsnachweis** Wählen Sie **Standard-Quellanmeldedaten** oder **Benutzerdefinierte Quellanmeldedaten und** folgen Sie den Anweisungen, um die Standard-Quellanmeldedaten zu verwalten oder die Quellanmeldedaten anzupassen. **Art der Verbindung** **CodeConnections**wird verwendet, um GitLab Self Managed mit zu verbinden CodeBuild. **Connection (Verbindung)** Wählen Sie eine GitLab selbstverwaltete Verbindung aus, über die Sie eine Verbindung herstellen möchten CodeConnections. **Repository** Wählen Sie das Repository aus, das Sie verwenden möchten. **Quellversion** Geben Sie eine Pull-Request-ID, einen Branch, eine Commit-ID, ein Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehen IDs, wie zum Beispiel `811dd1ba1aba14473856cee38308caed7190c0d` oder`5392f7`. Dies hilft dir dabei, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden. **Tiefe des Git-Klonens** Wählen Sie **Git clone depth (Git-Klontiefe)** aus, um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Wenn Sie einen vollständigen Klon erstellen möchten, wählen Sie **Full (Vollständig)** aus. **Build-Status** Wählen Sie **Build-Status beim Start und Ende Ihrer Builds an den Quellanbieter melden**, wenn Sie möchten, dass der Status des Beginns und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird. Um dem Quellanbieter den Buildstatus 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). ------ ### Umgebung **Bereitstellungsmodell** Führen Sie eine der folgenden Aktionen aus: + **Um On-Demand-Flotten zu verwenden, die von verwaltet werden AWS CodeBuild, wählen Sie On-Demand.** CodeBuild Bietet mit On-Demand-Flotten Rechenleistung für Ihre Builds. Die Maschinen werden zerstört, wenn der Bau abgeschlossen ist. On-Demand-Flotten werden vollständig verwaltet und verfügen über automatische Skalierungsfunktionen zur Bewältigung von Nachfragespitzen. + **Um Flotten mit reservierter Kapazität zu verwenden, die von verwaltet werden AWS CodeBuild, wählen Sie **Reservierte Kapazität** und dann einen Flottennamen aus.** Bei Flotten mit reservierter Kapazität konfigurieren Sie eine Reihe von dedizierten Instances für Ihre Build-Umgebung. Diese Maschinen bleiben inaktiv und sind bereit, Builds oder Tests sofort zu verarbeiten, wodurch die Build-Dauer reduziert wird. Mit Flotten mit reservierter Kapazität sind Ihre Maschinen immer in Betrieb und es fallen weiterhin Kosten an, solange sie bereitgestellt werden. Weitere Informationen finden Sie unter [Führen Sie Builds auf Flotten mit reservierter Kapazität aus](fleets.md). **Bild der Umgebung** Führen Sie eine der folgenden Aktionen aus: + Um ein Docker-Image zu verwenden, das von verwaltet wird AWS CodeBuild, wählen Sie **Verwaltetes Image** aus und treffen Sie dann eine Auswahl **unter Betriebssystem**, **Runtime (s)**, ****Image**** und Image-Version. Treffen Sie eine Auswahl unter **Environment type (Umgebungstyp)**, sofern verfügbar. + Wenn Sie ein anderes Docker-Image verwenden möchten, wählen Sie **Custom image** (Benutzerdefiniertes Image) aus. **Wählen Sie als **Umgebungstyp** **ARM**, **Linux, Linux** **GPU** oder Windows aus.** Wenn Sie **Andere Registrierung** wählen, geben Sie für **Externe Registrierungs-URL** den Namen und das Tag des Docker-Images in Docker Hub ein. Verwenden Sie dabei das Format. `docker repository/docker image name` Wenn Sie sich für **Amazon ECR** entscheiden, verwenden Sie das **Amazon ECR-Repository** und das **Amazon ECR-Image**, um das Docker-Image in Ihrem Konto auszuwählen. AWS + **Um ein privates Docker-Image zu verwenden, wählen Sie Benutzerdefiniertes Image.** Wählen Sie als **Umgebungstyp** **ARM**, **Linux**, **Linux GPU** oder **Windows** aus. Wählen Sie unter **Image registry (Abbildregistrierung)** die Option **Other registry (Andere Registrierung)** aus und geben Sie dann den ARN der Anmeldeinformationen für Ihr privates Docker-Image ein. Die Anmeldeinformationen müssen von Secrets Manager erstellt werden. Weitere Informationen finden Sie unter [Was ist AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) im *AWS Secrets Manager -Benutzerhandbuch*. CodeBuild überschreibt die `ENTRYPOINT` für benutzerdefinierte Docker-Images. **Datenverarbeitung** Führen Sie eine der folgenden Aktionen aus: + Um EC2 Compute zu verwenden, wählen Sie. **EC2** EC2 Compute bietet optimierte Flexibilität bei Aktionsläufen. + Um Lambda Compute zu verwenden, wählen Sie **Lambda**. Lambda Compute bietet optimierte Startgeschwindigkeiten für Ihre Builds. Lambda unterstützt schnellere Builds aufgrund einer geringeren Startlatenz. Lambda skaliert auch automatisch, sodass Builds nicht in der Warteschlange warten, bis sie ausgeführt werden. Weitere Informationen finden Sie unter [Builds auf dem AWS Lambda Computer ausführen](lambda.md). **Rolle „Dienst“** Führen Sie eine der folgenden Aktionen aus: + Wenn Sie keine CodeBuild Servicerolle haben, wählen Sie **Neue Servicerolle**. Geben Sie im Feld **Rollenname** einen Namen für die neue Rolle ein. + Wenn Sie eine CodeBuild Servicerolle haben, wählen Sie **Bestehende Servicerolle** aus. Wählen Sie **unter Role ARN** die Servicerolle aus. Wenn Sie die Konsole verwenden, um ein Build-Projekt zu erstellen, können Sie gleichzeitig eine CodeBuild Servicerolle erstellen. In der Standardeinstellung funktioniert diese Rolle ausschließlich mit diesem Projekt. Wenn Sie die Konsole verwenden, um die Servicerolle mit einem anderen Build-Projekt zu verknüpfen, wird die Rolle so aktualisiert, dass sie mit dem anderen Build-Projekt funktioniert. Eine Servicerolle kann in bis zu zehn Build-Projekten verwendet werden. **Zusätzliche Konfiguration** **Limit für automatische Wiederholungen** Geben Sie die Anzahl zusätzlicher automatischer Wiederholungen nach einem fehlgeschlagenen Build an. Wenn das Limit für automatische Wiederholungen beispielsweise auf 2 festgelegt ist, CodeBuild wird die `RetryBuild` API aufgerufen, um Ihren Build automatisch bis zu 2 weitere Male zu wiederholen. **Timeout (Zeitüberschreitung)** Geben Sie einen Wert zwischen 5 Minuten und 36 Stunden an. Danach wird der Build CodeBuild gestoppt, falls er nicht abgeschlossen ist. Wenn Sie die Felder **hours** und **minutes** leer lassen, wird der Standardwert von 60 Minuten verwendet. **Privilegiert** (Optional) Wählen Sie **Dieses Flag aktivieren aus, wenn Sie Docker-Images erstellen möchten oder wenn Sie möchten, dass Ihre Builds nur dann erweiterte Rechte erhalten**, wenn Sie dieses Build-Projekt zum Erstellen von Docker-Images verwenden möchten. Andernfalls schlagen alle zugehörigen Builds fehl, die versuchen, mit dem Docker-Daemon zu interagieren. Sie müssen zudem den Docker-Daemon müssen, damit Ihre Builds interagieren können. Eine Möglichkeit, dies durchzuführen, besteht darin, den Docker-Daemon in der `install`-Phase Ihrer Build-Spezifikation zu initialisieren, indem Sie die folgenden Build-Befehle ausführen. Führen Sie diese Befehle nicht aus, wenn Sie ein Image für die Build-Umgebung ausgewählt haben, das von CodeBuild mit Docker-Unterstützung bereitgestellt wird. Standardmäßig ist der Docker-Daemon für Nicht-VPC-Builds aktiviert. Wenn Sie Docker-Container für VPC-Builds verwenden möchten, lesen Sie auf der Docker Docs-Website unter [Runtime Privilege and Linux Capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) nach und aktivieren Sie den privilegierten Modus. Außerdem unterstützt Windows den privilegierten Modus nicht. ``` - 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" ``` **VPC** Wenn Sie mit Ihrer VPC arbeiten möchten CodeBuild : + Wählen Sie für **VPC** die VPC-ID aus, die CodeBuild verwendet wird. + Wählen Sie für **VPC-Subnetze die Subnetze** aus, die Ressourcen enthalten, die verwendet werden. CodeBuild + Wählen Sie für **VPC-Sicherheitsgruppen** die Sicherheitsgruppen aus, CodeBuild die den Zugriff auf Ressourcen in der VPCs ermöglichen. Weitere Informationen finden Sie unter [Verwendung AWS CodeBuild mit Amazon Virtual Private Cloud](vpc-support.md). **Datenverarbeitung** Wählen Sie eine der verfügbaren Optionen. **Anmeldeinformationen für die Registrierung** Geben Sie Anmeldeinformationen für die Registrierung an, wenn das Projekt mit einem nicht privaten Registrierungsabbild konfiguriert ist. Diese Anmeldeinformationen werden nur verwendet, wenn die Bilder durch Bilder aus privaten Registern überschrieben werden. **Umgebungsvariablen** Geben Sie den Namen und den Wert ein und wählen Sie dann den Typ der einzelnen Umgebungsvariablen aus, die von Builds verwendet werden sollen. CodeBuild legt die Umgebungsvariable für Ihre AWS Region automatisch fest. Sie müssen die folgenden Umgebungsvariablen festlegen, wenn Sie sie nicht zu Ihrer buildspec.yml hinzugefügt haben: + AWS\$1ACCOUNT\$1ID + IMAGE\$1REPO\$1NAME + IMAGE\$1TAG Konsole und AWS CLI Benutzer können Umgebungsvariablen sehen. Wenn Sie keine Bedenken hinsichtlich der Sichtbarkeit Ihrer Umgebungsvariablen haben, stellen Sie die Felder **Name** und **Value** ein und legen Sie dann den **Type** auf **Plaintext** fest. Wir empfehlen, dass Sie eine Umgebungsvariable mit einem sensiblen Wert wie einer AWS Zugriffsschlüssel-ID, einem AWS geheimen Zugriffsschlüssel oder einem Passwort als Parameter im Amazon EC2 Systems Manager Parameter Store oder speichern AWS Secrets Manager. Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, wählen Sie als **Typ** die Option **Parameter**. Geben Sie unter **Name** einen Bezeichner ein, auf CodeBuild den verwiesen werden soll. Geben Sie für **Value** den Namen des Parameters ein, wie er im Amazon EC2 Systems Manager Parameter Store gespeichert ist. Verwenden Sie beispielsweise einen Parameter mit der Bezeichnung `/CodeBuild/dockerLoginPassword` und wählen Sie für **Type (Typ)** **Parameter Store** aus. Geben Sie unter **Name** `LOGIN_PASSWORD` ein. Geben Sie für **Wert** `/CodeBuild/dockerLoginPassword` ein. Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, empfehlen wir, Parameter mit Parameternamen zu speichern, die mit `/CodeBuild/` (z. B.`/CodeBuild/dockerLoginPassword`) beginnen. Sie können die CodeBuild Konsole verwenden, um einen Parameter in Amazon EC2 Systems Manager zu erstellen. Wählen Sie **Create a parameter (Parameter erstellen)** aus und befolgen Sie dann die Anweisungen im Dialogfeld. (In diesem Dialogfeld können Sie für **KMS-Schlüssel** den ARN eines AWS KMS Schlüssels in Ihrem Konto angeben. Amazon EC2 Systems Manager verwendet diesen Schlüssel, um den Wert des Parameters beim Speichern zu verschlüsseln und beim Abrufen zu entschlüsseln.) Wenn Sie die CodeBuild Konsole verwenden, um einen Parameter zu erstellen, beginnt die Konsole den Parameternamen mit dem, `/CodeBuild/` wie er gespeichert wird. Weitere Informationen finden Sie unter [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) und [Systems Manager Parameter Store Console Walkthrough](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console) im *Amazon EC2 Systems Manager Manager-Benutzerhandbuch*. Wenn Ihr Build-Projekt auf Parameter Store von Amazon EC2 Systems Manager gespeicherte Parameter verweist, muss die Service-Rolle des Build-Projekts die `ssm:GetParameters` Aktion zulassen. Wenn Sie zuvor **Neue Servicerolle** ausgewählt haben, wird CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt aufgenommen. Wenn Sie jedoch **Existing service role (Vorhandene Servicerolle)** ausgewählt haben, müssen Sie diese Aktion separat in Ihre Servicerolle aufnehmen. Wenn sich Ihr Build-Projekt auf Parameter Store von Amazon EC2 Systems Manager mit Parameternamen bezieht, die nicht mit beginnen`/CodeBuild/`, und Sie **Neue Servicerolle** wählen, müssen Sie diese Servicerolle aktualisieren, um Zugriff auf Parameternamen zu gewähren, die nicht mit beginnen`/CodeBuild/`. Dies liegt daran, dass diese Service-Rolle nur auf Parameternamen zugreift, die mit `/CodeBuild/` beginnen. Wenn Sie **Neue Servicerolle** wählen, beinhaltet die Servicerolle die Berechtigung, alle Parameter unter dem `/CodeBuild/` Namespace im Amazon EC2 Systems Manager Parameter Store zu entschlüsseln. Von Ihnen gesetzte Umgebungsvariablen ersetzen vorhandene Umgebungsvariablen. Wenn das Docker-Image beispielsweise bereits eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `my_value` enthält und Sie eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `other_value` festlegen, wird `my_value` durch `other_value` ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `/usr/local/sbin:/usr/local/bin` enthält und Sie eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `$PATH:/usr/share/ant/bin` festlegen, wird `/usr/local/sbin:/usr/local/bin` durch den Literalwert `$PATH:/usr/share/ant/bin` ersetzt. Legen Sie keine Umgebungsvariable mit einem Namen fest, der mit `CODEBUILD_` beginnt. Dieses Präfix ist zur -internen Verwendung reserviert. Wenn eine Umgebungsvariable mit identischem Namen an mehreren Orten definiert ist, wird der Wert folgendermaßen bestimmt: + Der Wert im Aufruf zum Starten des Build-Vorgangs hat den höchsten Vorrang. + Der Wert in der Build-Projektdefinition folgt darauf. + Der Wert in der buildspec-Deklaration hat die niedrigste Priorität. Wenn Sie Secrets Manager verwenden, wählen Sie für **Type** **Secrets Manager**. Geben Sie unter **Name** einen Bezeichner ein, auf CodeBuild den verwiesen werden soll. Geben Sie unter **Wert** einen `reference-key` mit dem Muster `secret-id:json-key:version-stage:version-id` ein. Weitere Informationen finden Sie unter [Secrets Manager reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec). Wenn Sie Secrets Manager verwenden, empfehlen wir, Secrets mit Namen zu speichern, die mit `/CodeBuild/` (z. B.`/CodeBuild/dockerLoginPassword`) beginnen. Weitere Informationen finden Sie unter [Was ist AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) im *AWS Secrets Manager -Benutzerhandbuch*. Wenn sich Ihr Build-Projekt auf Geheimnisse bezieht, die in Secrets Manager gespeichert sind, muss die Service-Rolle des Build-Projekts die `secretsmanager:GetSecretValue` Aktion zulassen. Wenn Sie zuvor **Neue Servicerolle** ausgewählt haben, wird CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt aufgenommen. Wenn Sie jedoch **Existing service role (Vorhandene Servicerolle)** ausgewählt haben, müssen Sie diese Aktion separat in Ihre Servicerolle aufnehmen. Wenn sich Ihr Build-Projekt auf Geheimnisse bezieht, die in Secrets Manager mit geheimen Namen gespeichert sind, die nicht mit beginnen`/CodeBuild/`, und Sie **Neue Dienstrolle** ausgewählt haben, müssen Sie die Servicerolle aktualisieren, um Zugriff auf geheime Namen zu ermöglichen, die nicht mit beginnen`/CodeBuild/`. Dies liegt daran, dass die Servicerolle nur den Zugriff auf geheime Namen ermöglicht, die mit beginnen`/CodeBuild/`. Wenn Sie **Neue Dienstrolle** wählen, beinhaltet die Dienstrolle die Berechtigung, alle Geheimnisse unter dem `/CodeBuild/` Namespace im Secrets Manager zu entschlüsseln. ### Buildspec **Spezifikationen erstellen** Führen Sie eine der folgenden Aktionen aus: + Wenn Ihr Quellcode eine buildspec-Datei enthält, wählen Sie **Use a buildspec file (Eine buildspec-Datei verwenden)** aus. Standardmäßig sucht CodeBuild nach einer Datei namens `buildspec.yml` im Quellcodestammverzeichnis. Wenn Ihre Buildspec-Datei einen anderen Namen oder Speicherort verwendet, geben Sie ihren Pfad vom Quellstammverzeichnis in das Feld **Buildspec-Name** ein (zum Beispiel oder. `buildspec-two.yml` `configuration/buildspec.yml` Wenn sich die Buildspec-Datei in einem S3-Bucket befindet, muss sie sich in derselben Region wie Ihr Build-Projekt befinden. AWS Geben Sie die Buildspec-Datei mit ihrem ARN an (z. B.). `arn:aws:s3:::/buildspec.yml` + Wenn der Quellcode keine Build-Spezifikationsdatei enthält oder Sie andere Build-Befehle ausführen möchten, als für die `build`-Phase in der `buildspec.yml`-Datei im Stammverzeichnis des Quellcodes angegeben wurden, wählen Sie **Insert build commands (Build-Befehle einfügen)** aus. Geben Sie für **Build commands (Build-Befehle)** die Befehle ein, die in der `build`-Phase ausgeführt werden sollen. Bei mehreren Befehlen unterteilen Sie die einzelnen Befehle mit `&&`, (wie z. B. `mvn test && mvn package`). Um Befehle in anderen Phasen auszuführen oder wenn Sie eine lange Liste von Befehlen für die `build` Phase haben, fügen Sie dem Quellcode-Stammverzeichnis eine `buildspec.yml` Datei hinzu, fügen Sie die Befehle zur Datei hinzu und wählen Sie dann **Use the buildspec.yml** im Quellcode-Stammverzeichnis. Weitere Informationen hierzu finden Sie unter [Build-Spezifikationsreferenz](build-spec-ref.md). ### Batch-Konfiguration Sie können eine Gruppe von Builds als einen einzigen Vorgang ausführen. Weitere Informationen finden Sie unter [Builds stapelweise ausführen](batch-build.md). **Definieren Sie die Batch-Konfiguration** Wählen Sie diese Option, um Batch-Builds in diesem Projekt zuzulassen. **Batch-Servicerolle** Stellt die Servicerolle für Batch-Builds bereit. Wählen Sie eine der folgenden Optionen aus: + Wenn Sie keine Batch-Servicerolle haben, wählen Sie **Neue Servicerolle** aus. Geben Sie im Feld **Servicerolle** einen Namen für die neue Rolle ein. + Wenn Sie eine Batch-Servicerolle haben, wählen Sie **Bestehende Servicerolle** aus. Wählen Sie **unter Servicerolle** die Servicerolle aus. Batch-Builds führen eine neue Sicherheitsrolle in der Batch-Konfiguration ein. Diese neue Rolle ist erforderlich, da sie in der Lage sein CodeBuild muss`StartBuild`, die `RetryBuild` Aktionen`StopBuild`, und in Ihrem Namen aufzurufen, um Builds als Teil eines Batches auszuführen. Kunden sollten aus zwei Gründen eine neue Rolle und nicht dieselbe Rolle verwenden, die sie in ihrem Build verwenden: + Die Zuweisung der Build-Rolle `StartBuild` und der `RetryBuild` Berechtigungen würde es einem einzelnen Build ermöglichen, mehrere Builds über die Buildspec zu starten. `StopBuild` + CodeBuild Batch-Builds bieten Einschränkungen, die die Anzahl der Builds und Berechnungstypen einschränken, die für die Builds im Batch verwendet werden können. Wenn die Build-Rolle über diese Berechtigungen verfügt, ist es möglich, dass die Builds selbst diese Einschränkungen umgehen. **Zulässige Berechnungstypen für Batch** Wählen Sie die für den Stapel zulässigen Berechnungstypen aus. Wählen Sie alle zutreffenden Antworten aus. **Zulässige Flotten pro Batch** Wählen Sie die für den Stapel zulässigen Flotten aus. Wählen Sie alle zutreffenden Antworten aus. **Maximal zulässige Anzahl von Builds pro Batch** Geben Sie die maximale Anzahl von Builds ein, die im Stapel zulässig sind. Wenn ein Stapel diesen Grenzwert überschreitet, schlägt der Batch fehl. **Batch-Timeout** Geben Sie die maximale Zeit für den Abschluss des Batch-Builds ein. **Kombinieren Sie Artefakte** Wählen Sie **Alle Artefakte aus dem Stapel an einem einzigen Ort kombinieren** aus, um alle Artefakte aus dem Stapel an einem einzigen Ort zusammenzufassen. **Batch-Berichtsmodus** Wählen Sie den gewünschten Modus für den Build-Statusbericht für Batch-Builds aus. **Dieses Feld ist nur verfügbar, GitHub wenn die Projektquelle Bitbucket oder GitHub Enterprise ist und unter Quelle die Option **Buildstatus an den Quellanbieter melden, wenn deine Builds beginnen und enden**, ausgewählt ist.** **Aggregierte Builds** Wählen Sie diese Option aus, um die Status aller Builds im Batch in einem einzigen Statusbericht zusammenzufassen. **Einzelne Builds** Wählen Sie diese Option aus, damit der Build-Status für alle Builds im Batch separat gemeldet wird. ### -Artefakte **Typ** Führen Sie eine der folgenden Aktionen aus: + Wenn keine Build-Ausgabeartefakte erstellt werden sollen, klicken Sie auf die Option **No artifacts**. Möglicherweise möchten Sie dies tun, wenn Sie nur Build-Tests ausführen oder ein Docker-Image in ein Amazon ECR-Repository übertragen möchten. + Um die Build-Ausgabe in einem S3-Bucket zu speichern, wählen Sie **Amazon S3** und gehen Sie dann wie folgt vor: + Lassen Sie **Name** leer, wenn Sie den Projektnamen für die ZIP-Datei mit der Build-Ausgabe verwenden möchten. Geben Sie andernfalls den Namen ein. (Wenn eine ZIP-Datei mit einer Dateierweiterung ausgegeben werden soll, vergewissern Sie sich, dass Sie die Dateierweiterung an den Namen der ZIP-Datei anfügen.) + Wählen Sie **Enable semantitic versioning (Semantisches Versioning aktivieren)** aus, wenn Sie möchten, dass ein Name in der buildspec-Datei jeden beliebigen in der Konsole angegebenen Namen überschreibt. Der Name in einer buildspec-Datei wird zur Erstellungszeit berechnet und verwendet die Shell-Befehlssprache. Beispielsweise können Sie dem Namen Ihres Artefakts ein Datum und eine Uhrzeit anhängen, damit dieser stets eindeutig ist. Eindeutige Artefakt-Namen verhindern, dass Artefakte überschrieben werden. Weitere Informationen finden Sie unter [Syntax der Build-Spezifikation](build-spec-ref.md#build-spec-ref-syntax). + Wählen Sie für **Bucket name** den Namen des Ausgabe-Buckets aus. + Wenn Sie in diesem Vorgang zuvor die Option **Insert build commands (Build-Befehle eingeben)** verwendet haben, geben Sie für **Output files (Ausgabedateien)** die Speicherorte der Build-Dateien ein, die in der ZIP-Datei oder dem Ordner für die Build-Ausgabe enthalten sein sollen. Bei mehreren Speicherorten trennen Sie die einzelnen Speicherorte durch ein Komma, (wie z. B. `appspec.yml, target/my-app.jar`). Weitere Informationen finden Sie in der Beschreibung von `files` in [Syntax der Build-Spezifikation](build-spec-ref.md#build-spec-ref-syntax). + Wenn Sie nicht wollen, dass Ihre Build-Artefakte verschlüsselt werden, wählen Sie **Remove artifacts encryption (Verschlüsselung von Artefakten entfernen)** aus. Für jede Gruppe sekundärer Artefakte: 1. Geben Sie für **Artifact identifier (Artefakt-ID)** einen Wert mit weniger als 128 Zeichen ein, der nur alphanumerische Zeichen und Unterstriche enthält. 1. Wählen Sie **Add artifact (Artefakt hinzufügen)** aus. 1. Führen Sie die vorherigen Schritte aus, um die sekundären Artefakte zu konfigurieren. 1. Wählen Sie **Save artifact (Artefakt speichern)** aus. **Zusätzliche Konfiguration** **Verschlüsselungsschlüssel** (Optional) Führen Sie eine der folgenden Optionen aus: + Um das Von AWS verwalteter Schlüssel für Amazon S3 in Ihrem Konto zur Verschlüsselung der Build-Ausgabeartefakte zu verwenden, lassen Sie den **Verschlüsselungsschlüssel** leer. Dies ist die Standardeinstellung. + Um einen vom Kunden verwalteten Schlüssel zum Verschlüsseln der Build-Ausgabeartefakte zu verwenden, geben Sie im Feld **Verschlüsselungsschlüssel** den ARN des KMS-Schlüssels ein. Verwenden Sie dabei das Format `arn:aws:kms:region-ID:account-ID:key/key-ID`. **Cache-Typ** Wählen Sie für **Cache type (Cache-Typ)** eine der folgenden Optionen aus: + Wenn Sie keinen Cache verwenden möchten, wählen Sie **No cache**. + Wenn Sie einen Amazon S3-Cache verwenden möchten, wählen Sie **Amazon S3** und gehen Sie dann wie folgt vor: + Wählen Sie für **Bucket** den Namen des S3-Buckets, in dem der Cache gespeichert wird. + (Optional) Geben Sie für das **Cache-Pfadpräfix** ein Amazon S3 S3-Pfadpräfix ein. Der Wert für **Cache path prefix (Cache-Pfadpräfix)** ist mit einem Verzeichnisnamen vergleichbar. Er ermöglicht Ihnen das Speichern des Cache in demselben Verzeichnis eines Buckets. **Wichtig** Fügen Sie am Ende des Pfadpräfix keinen abschließenden Schrägstrich (/) an. + Wenn Sie einen lokalen Cache verwenden möchten, wählen Sie **Local (Lokal)** und dann mindestens einen lokalen Cache-Modus aus. **Anmerkung** Der Modus Docker layer cache (Docker-Ebenen-Cache) ist nur für Linux verfügbar. Wenn Sie diesen Modus auswählen, muss Ihr Projekt im privilegierten Modus ausgeführt werden. Durch die Verwendung eines Caches wird eine erhebliche Ersparnis bei der Erstellungszeit erzielt, da wiederverwendbare Teile der Build-Umgebung im Cache gespeichert und über Builds hinweg verwendet werden. Weitere Informationen über die Angabe eines Cache in der Build-Spezifikationsdatei finden Sie unter [Syntax der Build-Spezifikation](build-spec-ref.md#build-spec-ref-syntax). Weitere Informationen zum Caching finden Sie unter [Cache-Builds zur Verbesserung der Leistung](build-caching.md). ### Logs (Protokolle) Wählen Sie die Protokolle aus, die Sie erstellen möchten. Sie können Amazon CloudWatch Logs, Amazon S3 S3-Protokolle oder beides erstellen. **CloudWatch** Wenn Sie Amazon CloudWatch Logs-Protokolle wünschen: **CloudWatch logs** Wählen Sie **CloudWatch logs (CW-Protokolle)**. **Group name** (Gruppenname) Geben Sie den Namen Ihrer Amazon CloudWatch Logs-Protokollgruppe ein. **Name des Streams** Geben Sie den Namen Ihres Amazon CloudWatch Logs-Log-Streams ein. **S3** Wenn Sie Amazon S3 S3-Protokolle wünschen: **S3-Protokolle** Wählen Sie **S3 logs (S3-Protokolle)**. **Bucket** Wählen Sie den Namen des S3-Buckets für Ihre Logs. **Pfadpräfix** Geben Sie das Präfix für Ihre Logs ein. **Deaktivieren Sie die S3-Protokollverschlüsselung** Wählen Sie diese Option aus, wenn Sie nicht möchten, dass Ihre S3-Protokolle verschlüsselt werden. ## Erstellen eines Build-Projekts (AWS CLI) Weitere Informationen zur Verwendung von AWS CLI with CodeBuild finden Sie unter[Befehlszeilenreferenz](cmd-ref.md). Um ein CodeBuild Build-Projekt mit dem zu erstellen AWS CLI, erstellen Sie eine [Projektstruktur](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html) im JSON-Format, füllen die Struktur aus und rufen den [https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html)Befehl zum Erstellen des Projekts auf. ### Erstellen Sie die JSON-Datei Erstellen Sie eine JSON-Skelettdatei mit dem [https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html)Befehl und verwenden Sie die `--generate-cli-skeleton` folgende Option: ``` aws codebuild create-project --generate-cli-skeleton > ``` Dadurch wird eine JSON-Datei mit dem von angegebenen Pfad und Dateinamen erstellt**. ### Füllen Sie die JSON-Datei aus Ändern Sie die JSON-Daten wie folgt und speichern Sie Ihre Ergebnisse. ``` { "name": "", "description": "", "source": { "type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE", "location": "", "gitCloneDepth": "", "buildspec": "", "InsecureSsl": "", "reportBuildStatus": "", "buildStatusConfig": { "context": "", "targetUrl": "" }, "gitSubmodulesConfig": { "fetchSubmodules": "" }, "auth": { "type": "", "resource": "" }, "sourceIdentifier": "" }, "secondarySources": [ { "type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE", "location": "", "gitCloneDepth": "", "buildspec": "", "InsecureSsl": "", "reportBuildStatus": "", "auth": { "type": "", "resource": "" }, "sourceIdentifier": "" } ], "secondarySourceVersions": [ { "sourceIdentifier": "", "sourceVersion": "" } ], "sourceVersion": "", "artifacts": { "type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS", "location": "", "path": "", "namespaceType": "", "name": "", "overrideArtifactName": "", "packaging": "" }, "secondaryArtifacts": [ { "type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS", "location": "", "path": "", "namespaceType": "", "name": "", "packaging": "", "artifactIdentifier": "" } ], "cache": { "type": "", "location": "", "mode": [ "" ] }, "environment": { "type": "LINUX_CONTAINER" | "LINUX_GPU_CONTAINER" | "ARM_CONTAINER" | "WINDOWS_SERVER_2019_CONTAINER" | "WINDOWS_SERVER_2022_CONTAINER", "image": "", "computeType": "BUILD_GENERAL1_SMALL" | "BUILD_GENERAL1_MEDIUM" | "BUILD_GENERAL1_LARGE" | "BUILD_GENERAL1_2XLARGE", "certificate": "", "environmentVariables": [ { "name": "", "value": "", "type": "" } ], "registryCredential": [ { "credential": "", "credentialProvider": "" } ], "imagePullCredentialsType": "CODEBUILD" | "SERVICE_ROLE", "privilegedMode": "" }, "serviceRole": "", "autoRetryLimit": , "timeoutInMinutes": , "queuedTimeoutInMinutes": , "encryptionKey": "", "tags": [ { "key": "", "value": "" } ], "vpcConfig": { "securityGroupIds": [ "" ], "subnets": [ "" ], "vpcId": "" }, "badgeEnabled": "", "logsConfig": { "cloudWatchLogs": { "status": "", "groupName": "", "streamName": "" }, "s3Logs": { "status": "", "location": "", "encryptionDisabled": "" } }, "fileSystemLocations": [ { "type": "EFS", "location": ":/", "mountPoint": "", "identifier": "", "mountOptions": "" } ], "buildBatchConfig": { "serviceRole": "", "combineArtifacts": , "restrictions": { "maximumBuildsAllowed": , "computeTypesAllowed": [ "" ], "fleetsAllowed": [ "" ] }, "timeoutInMins": , "batchReportMode": "REPORT_AGGREGATED_BATCH" | "REPORT_INDIVIDUAL_BUILDS" }, "concurrentBuildLimit": } ``` Ersetzen Sie Folgendes: #### **Name** Erforderlich Name dieses Build-Projekts. Dieser Name muss für alle Build-Projekte in Ihrem AWS Konto eindeutig sein. #### **description** Optional. Beschreibung dieses Build-Projekts. #### **source** Erforderlich Ein [ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html)Objekt, das Informationen zu den Quellcodeeinstellungen dieses Build-Projekts enthält. Nachdem Sie ein `source`-Objekt hinzugefügt haben, können Sie mit [**secondarySources**](#cli.secondarysources) bis zu zwölf weitere Quellen hinzufügen. Diese Einstellungen umfassen u. a. folgende: **Quelle/Typ** Erforderlich Der Typ des Repositorys, das den zu erstellenden Quellcode enthält. Gültige Werte sind: + `CODECOMMIT` + `CODEPIPELINE` + `GITHUB` + `GITHUB_ENTERPRISE` + `GITLAB` + `GITLAB_SELF_MANAGED` + `BITBUCKET` + `S3` + `NO_SOURCE` Wenn Sie `NO_SOURCE` verwenden, kann die Build-Spezifikation keine Datei sein, da das Projekt nicht über eine Quelle verfügt. Stattdessen müssen Sie das `buildspec`-Attribut verwenden, um eine YAML-formatierte Zeichenfolge für Ihre Build-Spezifikation zu verwenden. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt ohne Quelle](no-source.md). **Quelle/ Ort** Erforderlich, sofern Sie nicht auf eingestellt ** haben. `CODEPIPELINE` Der Speicherort des Quellcodes für den angegebenen Repository-Typ. + Zum CodeCommit Beispiel die HTTPS-Klon-URL zum Repository, das den Quellcode und die Buildspec-Datei enthält (z. B.). `https://git-codecommit..amazonaws.com/v1/repos/` + Für Amazon S3 der Name des Build-Eingabe-Buckets, gefolgt vom Pfad und Namen der ZIP-Datei, die den Quellcode und die Buildspec enthält. Zum Beispiel: + Für eine ZIP-Datei, die sich im Stammverzeichnis des Eingabe-Buckets befindet:. `/.zip` + Für eine ZIP-Datei, die sich in einem Unterordner im Eingabe-Bucket befindet:`//.zip`. + Für GitHub die HTTPS-Klon-URL zum Repository, das den Quellcode und die Buildspec-Datei enthält. Die URL muss „github.com“ enthalten. Sie müssen Ihr Konto mit Ihrem AWS Konto verbinden. GitHub Verwenden Sie dazu die CodeBuild Konsole, um ein Build-Projekt zu erstellen. + Wählen Sie **Authorize application**. (Nachdem Sie sich mit Ihrem GitHub Konto verbunden haben, müssen Sie die Erstellung des Build-Projekts nicht abschließen. Sie können die CodeBuild Konsole schließen.) + Für GitHub Enterprise Server die HTTP- oder HTTPS-Klon-URL zum Repository, das den Quellcode und die Buildspec-Datei enthält. Sie müssen Ihr Konto auch mit Ihrem GitHub Enterprise AWS Server-Konto verbinden. Verwenden Sie dazu die CodeBuild Konsole, um ein Build-Projekt zu erstellen. 1. Erstellen Sie ein persönliches Zugriffstoken in GitHub Enterprise Server. 1. Kopieren Sie dieses Token in Ihre Zwischenablage, damit Sie es bei der Erstellung Ihres CodeBuild Projekts verwenden können. Weitere Informationen finden Sie auf der GitHub Hilfeseite unter [Erstellen eines persönlichen Zugriffstokens für die Befehlszeile](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/). 1. Wenn Sie die Konsole verwenden, um Ihr CodeBuild Projekt zu erstellen, wählen Sie in **Source** für **Source Provider** die Option **GitHubEnterprise** aus. 1. Für **Personal Access Token** fügen Sie das Token ein, das in Ihre Zwischenablage kopiert wurde. Wählen Sie **Save Token**. Ihr CodeBuild Konto ist jetzt mit Ihrem GitHub Enterprise Server-Konto verbunden. + Für GitLab und GitLab selbst verwaltet, die HTTPS-Klon-URL zum Repository, das den Quellcode und die Buildspec-Datei enthält. Beachten Sie, dass die URL bei Verwendung GitLab gitlab.com enthalten muss. Wenn du GitLab Self-managed verwendest, muss die URL nicht gitlab.com enthalten. Du musst dein Konto mit deinem AWS Konto GitLab oder GitLab deinem selbst verwalteten Konto verbinden. Verwenden Sie dazu die CodeBuild-Konsole, um ein Build-Projekt zu erstellen. + Wählen Sie im Navigationsbereich der Developer Tools die Optionen **Einstellungen**, **Verbindungen** und anschließend **Verbindung erstellen** aus. Erstellen Sie auf dieser Seite entweder eine GitLab oder eine GitLab selbstverwaltete Verbindung und wählen Sie dann **Connect** aus. GitLab + Für Bitbucket handelt es sich um die HTTPS-Klon-URL des Repositorys, das den Quellcode und die buildspec-Datei enthält. Die URL muss „bitbucket.org“ enthalten. Du musst dein Konto außerdem mit deinem AWS Bitbucket-Konto verbinden. Verwende dazu die CodeBuild Konsole, um ein Build-Projekt zu erstellen. 1. Wenn Sie die Konsole zum Verbinden (oder Wiederverbinden) mit Bitbucket verwenden, wählen Sie auf der Seite **Confirm access to your account** die Option **Grant access**. (Nachdem du dich mit deinem Bitbucket-Konto verbunden hast, musst du die Erstellung des Build-Projekts nicht abschließen. Du kannst die CodeBuild Konsole schließen.) + Für AWS CodePipeline, geben Sie keinen `location` Wert für an`source`. CodePipeline ignoriert diesen Wert CodePipeline, da Sie beim Erstellen einer Pipeline in den Quellcodepfad der Pipeline den Speicherort des Quellcodes angeben. Quelle/ **gitCloneDepth** Optional. Die Tiefe des herunterzuladenden Verlaufs. Der Mindestwert ist 0. Ist dieser Wert 0, größer als 25 oder nicht angegeben, wird für jedes Build-Projekt der vollständige Verlauf heruntergeladen. Wenn Ihr Quelltyp Amazon S3 ist, wird dieser Wert nicht unterstützt. **Quelle/ Buildspec** Optional. Die zu verwendende Build-Spezifikationsdefinition oder -datei. Wenn der Wert nicht angegeben oder eine leere Zeichenfolge ist, muss der Quellcode eine `buildspec.yml`-Datei im Stammverzeichnis enthalten. Wenn dieser Wert gesetzt ist, kann es sich entweder um eine Inline-Buildspec-Definition, den Pfad zu einer alternativen Buildspec-Datei relativ zum Stammverzeichnis Ihrer Primärquelle oder um den Pfad zu einem S3-Bucket handeln. Der Bucket muss sich in derselben Region wie das Build-Projekt befinden AWS . Geben Sie die buildspec-Datei mit ihrem ARN an (z. B. `arn:aws:s3:::/buildspec.yml`). Weitere Informationen finden Sie unter [Dateiname der Build-Spezifikation und Speicherort](build-spec-ref.md#build-spec-ref-name-storage). **Quelle/Authentifizierung** Enthält Informationen über die Autorisierungseinstellungen für den CodeBuild Zugriff auf den zu erstellenden Quellcode. **Quelle/Autor/Typ** Erforderlich Der zu verwendende Autorisierungstyp. Gültige Werte für sind: + `OAUTH` + `CODECONNECTIONS` + `SECRETS_MANAGER` **Quelle/Autor/Ressource** Optional. Der Ressourcenwert, der auf den angegebenen Autorisierungstyp angewendet wird. Dies kann der Secrets Manager ARN oder der CodeConnections ARN sein. Quelle/ **reportBuildStatus** Gibt an, ob Ihr Quell-Anbieter den Status eines Build-Starts und -Abschlusses sendet. Wenn Sie dies mit einem anderen Quellanbieter als GitHub GitHub Enterprise Server oder Bitbucket festlegen, `invalidInputException` wird ein ausgelöst. Um den Build-Status an den Quell-Provider melden zu können, muss der mit dem Quell-Provider verknüpfte Benutzer Schreibzugriff auf das Repo 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). Quelle/ **buildStatusConfig** Enthält Informationen, die definieren, wie das CodeBuild Build-Projekt den Build-Status an den Quellanbieter meldet. Diese Option wird nur verwendet, wenn der Quelltyp `GITHUB``GITHUB_ENTERPRISE`, oder ist`BITBUCKET`. **Quelle/buildStatusConfig/Kontext** Bei Bitbucket-Quellen wird dieser Parameter für den `name` Parameter im Bitbucket-Commit-Status verwendet. Bei GitHub Quellen wird dieser Parameter für den `context` Parameter im GitHub Commit-Status verwendet. Sie können zum Beispiel die Build-Nummer `context` enthalten und den Webhook-Trigger mithilfe der CodeBuild Umgebungsvariablen auslösen: ``` AWS CodeBuild sample-project Build #$CODEBUILD_BUILD_NUMBER - $CODEBUILD_WEBHOOK_TRIGGER ``` Dies führt dazu, dass der Kontext für Build \$124, ausgelöst durch ein Webhook-Pull-Request-Ereignis, wie folgt aussieht: ``` AWS CodeBuild sample-project Build #24 - pr/8 ``` **Quelle/ ZielURL buildStatusConfig** Bei Bitbucket-Quellen wird dieser Parameter für den `url` Parameter im Bitbucket-Commit-Status verwendet. Bei GitHub Quellen wird dieser Parameter für den `target_url` Parameter im GitHub Commit-Status verwendet. Sie können beispielsweise den Wert `targetUrl` auf setzen `https://aws.amazon.com/codebuild/` und der Commit-Status wird auf diese URL verweisen. Sie können auch CodeBuild Umgebungsvariablen in die aufnehmen`targetUrl`, um der URL zusätzliche Informationen hinzuzufügen. Um beispielsweise die Build-Region zur URL hinzuzufügen, setzen Sie den Wert `targetUrl` auf: ``` "targetUrl": "https://aws.amazon.com/codebuild/?region=$AWS_REGION" ``` Wenn die Build-Region ist`us-east-2`, wird dies erweitert auf: ``` https://aws.amazon.com/codebuild/?region=us-east-2 ``` Quelle/ **gitSubmodulesConfig** Optional. Informationen zur Konfiguration der Git-Submodule. Wird nur mit CodeCommit GitHub, GitHub Enterprise Server und Bitbucket verwendet. **quelle///fetchSubmodules gitSubmodulesConfig** Legen Sie für `fetchSubmodules` `true` fest, wenn die Git-Submodule in Ihr Repository aufgenommen werden sollen. Die einbezogenen Git-Submodule müssen als HTTPS konfiguriert werden. Quelle/ **InsecureSsl** Optional. Wird nur mit GitHub Enterprise Server verwendet. Setzen Sie diesen Wert auf, `true` um TLS-Warnungen zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise Server-Projekt-Repository herstellen. Der Standardwert ist `false`. `InsecureSsl` sollte nur für Testzwecke verwendet werden. Es sollte nicht in einer Produktionsumgebung verwendet werden. **Quelle/ SourceIdentifier** Ein benutzerdefinierter Bezeichner für die Projektquelle. Optional für die Primärquelle. Für Sekundärquellen erforderlich. #### **secondarySources** Optional. Eine Reihe von [ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html)Objekten, die Informationen zu den Sekundärquellen für ein Build-Projekt enthalten. Sie können bis zu 12 Sekundärquellen hinzufügen. Die `secondarySources` Objekte verwenden dieselben Eigenschaften wie das [**source**](#cli.source) Objekt. In einem sekundären Quellobjekt `sourceIdentifier` ist der erforderlich. #### **secondarySourceVersions** Optional. Ein Array von [ProjectSourceVersion](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSourceVersion.html)-Objekten. Wenn `secondarySourceVersions` auf Build-Ebene angegeben ist, haben sie Vorrang vor dieser Angabe. #### **sourceVersion** Optional. Die Version der Build-Eingabe, die für dieses Projekt erstellt werden soll. Ist dieser Parameter nicht angegeben, wird die neueste Version verwendet. Ist er festgelegt, muss er Folgendes sein: + Für CodeCommit die zu verwendende Commit-ID, den Branch oder das Git-Tag. + Für GitHub die Commit-ID, die Pull-Request-ID, den Branch-Namen oder den Tag-Namen, der der Version des Quellcodes entspricht, den Sie erstellen möchten. Wenn eine Pull-Anforderungs-ID angegeben ist, muss diese das Format `pr/pull-request-ID` aufweisen (Beispiel: `pr/25`). Wenn ein Branch-Name angegeben wird, wird die Commit-ID von HEAD verwendet. Wenn sie nicht angegeben ist, wird die Commit-ID von HEAD für den Standard-Branch verwendet. + Für GitLab die Commit-ID, die Pull-Request-ID, den Branchennamen, den Tag-Namen oder die Referenz und eine Commit-ID. Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). + Für Bitbucket, Commit-ID, Branch-Name oder Tag-Name, die/der der Version des Quellcodes entspricht, die Sie erstellen möchten. Wenn ein Branch-Name angegeben wird, wird die Commit-ID von HEAD verwendet. Wenn sie nicht angegeben ist, wird die Commit-ID von HEAD für den Standard-Branch verwendet. + Für Amazon S3 die Versions-ID des Objekts, das die zu verwendende Build-Eingabe-ZIP-Datei darstellt. Wenn `sourceVersion` auf Build-Ebene angegeben ist, hat jene Version Vorrang vor dieser Version `sourceVersion` (auf Projektebene). Weitere Informationen finden Sie unter [Beispiel für eine Quellversion mit AWS CodeBuild](sample-source-version.md). #### **Artefakte** Erforderlich Ein [ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html)Objekt, das Informationen über die Einstellungen für das Ausgabeartefakt dieses Build-Projekts enthält. Nachdem Sie ein `artifacts`-Objekt hinzugefügt haben, können Sie mit [secondaryArtifacts](#cli.secondaryartifacts) bis zu zwölf weitere Artefakte hinzufügen. Diese Einstellungen umfassen u. a. folgende: **Artefakte/Typ** Erforderlich Der Typ des Build-Ausgabeartefakts. Gültige Werte für sind: + `CODEPIPELINE` + `NO_ARTIFACTS` + `S3` Artefakte/ **Standort** Wird nur mit dem Artefakttyp verwendet. `S3` Wird nicht für andere Artefakttypen verwendet. Der Name des Ausgabe-Buckets, den Sie erstellt oder in den Voraussetzungen identifiziert haben. **Artefakte/Pfad** Wird nur mit dem Artefakttyp verwendet. `S3` Wird nicht für andere Artefakttypen verwendet. Der Pfad im Ausgabe-Bucket, in den die ZIP-Datei oder der Ordner eingefügt werden sollen. Wenn Sie keinen Wert für angeben`path`, CodeBuild verwendet `namespaceType` (falls angegeben) und, `name` um den Pfad und den Namen der Build-Ausgabe-ZIP-Datei oder des Ordners zu ermitteln. Wenn Sie beispielsweise für `path` und `MyPath` `MyArtifact.zip` für angeben`name`, würden der Pfad und der Name wie folgt lauten`MyPath/MyArtifact.zip`. **Artefakte/ namespaceType** Wird nur mit dem Artefakttyp verwendet. `S3` Wird nicht für andere Artefakttypen verwendet. Der Namespace der ZIP-Datei oder des Ordners für die Build-Ausgabe. Gültige Werte sind `BUILD_ID` und `NONE`. Verwenden Sie `BUILD_ID`, um die Build-ID in den Pfad und den Namen für die ZIP-Datei oder den Ordner einzubeziehen. Verwenden Sie andernfalls `NONE`. Wenn Sie keinen Wert für angeben`namespaceType`, CodeBuild verwendet `path` (falls angegeben) und, `name` um den Pfad und den Namen der ZIP-Datei oder des Ordners der Build-Ausgabe zu ermitteln. Wenn Sie beispielsweise für, `MyPath` für `path` und `BUILD_ID` `MyArtifact.zip` für angeben`namespaceType`, würden der Pfad und der Name wie folgt lauten`MyPath/build-ID/MyArtifact.zip`. `name` artifacts/**name** Wird nur mit dem `S3` Artefakttyp verwendet. Wird nicht für andere Artefakttypen verwendet. Der Name der ZIP-Datei oder des Ordners in der `location` Build-Ausgabe. Wenn Sie beispielsweise für `path` und `MyPath` `MyArtifact.zip` für angeben`name`, würden der Pfad und der Name wie folgt lauten`MyPath/MyArtifact.zip`. Artefakte/ **overrideArtifactName** Wird nur mit dem Artefakttyp S3 verwendet. Wird nicht für andere Artefakttypen verwendet. Optional. Wenn auf gesetzt`true`, hat der im `artifacts` Block der Buildspec-Datei angegebene Name Vorrang. `name` Weitere Informationen finden Sie unter [Referenz zur Build-Spezifikation für CodeBuild](build-spec-ref.md). **Artefakte/ Verpackung** Wird nur mit dem Artefakttyp verwendet. `S3` Wird nicht für andere Artefakttypen verwendet. Optional. Gibt an, wie die Artefakte verpackt werden sollen. Die zulässigen Werte sind: NONE Erstellen Sie einen Ordner, der die Build-Artefakte enthält. Dies ist der Standardwert. ZIP Erstellen Sie eine ZIP-Datei, die die Build-Artefakte enthält. #### secondaryArtifacts Optional. Eine Reihe von [ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html)Objekten, die Informationen zu den Einstellungen für sekundäre Artefakte für ein Build-Projekt enthalten. Sie können bis zu zwölf sekundäre Attribute hinzufügen. `secondaryArtifacts` verwendet viele der Einstellungen, die vom [**Artefakte**](#cli.artifacts)-Objekt verwendet werden. #### Cache Erforderlich Ein [ProjectCache](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectCache.html)Objekt, das Informationen zu den Cache-Einstellungen dieses Build-Projekts enthält. Weitere Informationen finden Sie unter [Cache-Builds](build-caching.md). #### Umgebung Erforderlich Ein [ProjectEnvironment](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html)Objekt, das Informationen über die Build-Umgebungseinstellungen dieses Projekts enthält. Diese Einstellungen umfassen Folgendes: **Umgebung/Typ** Erforderlich Der Typ der Build-Umgebung. Weitere Informationen finden Sie unter [type](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-type) in der *CodeBuild API-Referenz.* **Umgebung/Bild** Erforderlich Der Bezeichner des Docker-Images, den diese Build-Umgebung nutzt. In der Regel wird dieser Bezeichner wie folgt ausgedrückt*image-name*:*tag*. In dem Docker-Repository, das zur Verwaltung seiner Docker-Images CodeBuild verwendet wird, könnte dies beispielsweise der Fall sein. `aws/codebuild/standard:5.0` Im Docker Hub: `maven:3.3.9-jdk-8`. In Amazon ECR,`account-id.dkr.ecr.region-id.amazonaws.com/your-Amazon-ECR-repo-name:tag`. Weitere Informationen finden Sie unter [Docker-Images bereitgestellt von CodeBuild](build-env-ref-available.md). **Umgebung/ ComputeType** Erforderlich Gibt die Rechenressourcen an, die von dieser Build-Umgebung verwendet werden. Weitere Informationen finden Sie unter [ComputeType](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-computeType) in der *CodeBuild API-Referenz*. **Umgebung/Zertifikat** Optional. Der ARN des Amazon S3 S3-Buckets, das Pfadpräfix und der Objektschlüssel, der das PEM-kodierte Zertifikat enthält. Der Objektschlüssel kann entweder nur die .pem-Datei oder eine .zip-Datei mit dem PEM-codierten Zertifikat sein. Wenn Ihr Amazon S3 S3-Bucket-Name beispielsweise lautet``, Ihr Pfadpräfix ist `` und Ihr Objektschlüsselname lautet``, dann `certificate` sind die akzeptablen Formate für `` oder`arn:aws:s3:::`. **Umgebung/Umgebungsvariablen** Optional. Ein Array von [EnvironmentVariable](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html)Objekten, das die Umgebungsvariablen enthält, die Sie für diese Build-Umgebung angeben möchten. Jede Umgebungsvariable wird als Objekt ausgedrückt, das ein `name``value`, und `type` von `name``value`, und enthält`type`. Konsole und AWS CLI Benutzer können alle Umgebungsvariablen sehen. Wenn Sie keine Bedenken hinsichtlich der Sichtbarkeit Ihrer Umgebungsvariablen haben, setzen Sie `name` und und `value` setzen Sie `type` sie auf`PLAINTEXT`. Wir empfehlen Ihnen, Umgebungsvariablen mit sensiblen Werten wie einer AWS Zugriffsschlüssel-ID, einem AWS geheimen Zugriffsschlüssel oder einem Passwort als Parameter im Amazon EC2 Systems Manager Parameter Store oder zu speichern AWS Secrets Manager. Geben `name` Sie für diesen gespeicherten Parameter einen Bezeichner ein, CodeBuild auf den verwiesen werden soll. Wenn Sie Amazon EC2 Systems Manager Parameter Store für verwenden`value`, legen Sie den Namen des Parameters so fest, wie er im Parameter Store gespeichert ist. Setzen Sie `type` auf `PARAMETER_STORE`. Verwenden Sie einen `/CodeBuild/dockerLoginPassword` als Beispiel benannten Parameter und setzen Sie ihn `name` auf`LOGIN_PASSWORD`. Setzen Sie `value` auf `/CodeBuild/dockerLoginPassword`. Setzen Sie `type` auf `PARAMETER_STORE`. Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, empfehlen wir Ihnen, Parameter mit Parameternamen zu speichern, die mit `/CodeBuild/` (z. B.`/CodeBuild/dockerLoginPassword`) beginnen. Sie können die CodeBuild Konsole verwenden, um einen Parameter in Amazon EC2 Systems Manager zu erstellen. Wählen Sie **Create a parameter (Parameter erstellen)** aus und befolgen Sie dann die Anweisungen im Dialogfeld. (In diesem Dialogfeld können Sie für **KMS-Schlüssel** den ARN eines AWS KMS Schlüssels in Ihrem Konto angeben. Amazon EC2 Systems Manager verwendet diesen Schlüssel, um den Wert des Parameters beim Speichern zu verschlüsseln und beim Abrufen zu entschlüsseln.) Wenn Sie die CodeBuild Konsole verwenden, um einen Parameter zu erstellen, beginnt die Konsole den Parameternamen mit dem, `/CodeBuild/` wie er gespeichert wird. Weitere Informationen finden Sie unter [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) und [Systems Manager Parameter Store Console Walkthrough](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console) im *Amazon EC2 Systems Manager Manager-Benutzerhandbuch*. Wenn Ihr Build-Projekt auf Parameter Store von Amazon EC2 Systems Manager gespeicherte Parameter verweist, muss die Service-Rolle des Build-Projekts die `ssm:GetParameters` Aktion zulassen. Wenn Sie zuvor **Neue Servicerolle** ausgewählt haben, wird CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt aufgenommen. Wenn Sie jedoch **Existing service role (Vorhandene Servicerolle)** ausgewählt haben, müssen Sie diese Aktion separat in Ihre Servicerolle aufnehmen. Wenn sich Ihr Build-Projekt auf Parameter Store von Amazon EC2 Systems Manager mit Parameternamen bezieht, die nicht mit beginnen`/CodeBuild/`, und Sie **Neue Servicerolle** wählen, müssen Sie diese Servicerolle aktualisieren, um Zugriff auf Parameternamen zu gewähren, die nicht mit beginnen`/CodeBuild/`. Dies liegt daran, dass diese Service-Rolle nur auf Parameternamen zugreift, die mit `/CodeBuild/` beginnen. Wenn Sie **Neue Servicerolle** wählen, beinhaltet die Servicerolle die Berechtigung, alle Parameter unter dem `/CodeBuild/` Namespace im Amazon EC2 Systems Manager Parameter Store zu entschlüsseln. Von Ihnen gesetzte Umgebungsvariablen ersetzen vorhandene Umgebungsvariablen. Wenn das Docker-Image beispielsweise bereits eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `my_value` enthält und Sie eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `other_value` festlegen, wird `my_value` durch `other_value` ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `/usr/local/sbin:/usr/local/bin` enthält und Sie eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `$PATH:/usr/share/ant/bin` festlegen, wird `/usr/local/sbin:/usr/local/bin` durch den Literalwert `$PATH:/usr/share/ant/bin` ersetzt. Legen Sie keine Umgebungsvariable mit einem Namen fest, der mit `CODEBUILD_` beginnt. Dieses Präfix ist zur -internen Verwendung reserviert. Wenn eine Umgebungsvariable mit identischem Namen an mehreren Orten definiert ist, wird der Wert folgendermaßen bestimmt: + Der Wert im Aufruf zum Starten des Build-Vorgangs hat den höchsten Vorrang. + Der Wert in der Build-Projektdefinition folgt darauf. + Der Wert in der buildspec-Deklaration hat die niedrigste Priorität. Wenn Sie Secrets Manager verwenden, geben Sie für den Namen des Parameters an`value`, wie er in Secrets Manager gespeichert ist. Setzen Sie `type` auf `SECRETS_MANAGER`. Verwenden Sie ein `/CodeBuild/dockerLoginPassword` als Beispiel benanntes Geheimnis und legen Sie `name` den Wert auf fest`LOGIN_PASSWORD`. Setzen Sie `value` auf `/CodeBuild/dockerLoginPassword`. Setzen Sie `type` auf `SECRETS_MANAGER`. Wenn Sie Secrets Manager verwenden, empfehlen wir, Secrets mit Namen zu speichern, die mit `/CodeBuild/` (z. B.`/CodeBuild/dockerLoginPassword`) beginnen. Weitere Informationen finden Sie unter [Was ist AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) im *AWS Secrets Manager -Benutzerhandbuch*. Wenn sich Ihr Build-Projekt auf Geheimnisse bezieht, die in Secrets Manager gespeichert sind, muss die Service-Rolle des Build-Projekts die `secretsmanager:GetSecretValue` Aktion zulassen. Wenn Sie zuvor **Neue Servicerolle** ausgewählt haben, wird CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt aufgenommen. Wenn Sie jedoch **Existing service role (Vorhandene Servicerolle)** ausgewählt haben, müssen Sie diese Aktion separat in Ihre Servicerolle aufnehmen. Wenn sich Ihr Build-Projekt auf Geheimnisse bezieht, die in Secrets Manager mit geheimen Namen gespeichert sind, die nicht mit beginnen`/CodeBuild/`, und Sie **Neue Dienstrolle** ausgewählt haben, müssen Sie die Servicerolle aktualisieren, um Zugriff auf geheime Namen zu ermöglichen, die nicht mit beginnen`/CodeBuild/`. Dies liegt daran, dass die Servicerolle nur den Zugriff auf geheime Namen ermöglicht, die mit beginnen`/CodeBuild/`. Wenn Sie **Neue Dienstrolle** wählen, beinhaltet die Dienstrolle die Berechtigung, alle Geheimnisse unter dem `/CodeBuild/` Namespace im Secrets Manager zu entschlüsseln. **Umgebung/RegistryCredential** Optional. Ein [RegistryCredential](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_RegistryCredential.html)Objekt, das die Anmeldeinformationen angibt, die den Zugriff auf eine private Docker-Registrierung ermöglichen. **Umgebung/RegistryCredential/ Credential** Gibt den ARN oder Namen der Anmeldeinformationen an, die mit erstellt wurden AWS Managed Services. Sie können den Namen der Anmeldeinformationen nur verwenden, wenn diese in Ihrer aktuellen Region vorhanden sind. **Environment/RegistryCredential/ CredentialProvider** Der einzige gültige Wert ist `SECRETS_MANAGER`. Wenn diese Eigenschaft festgelegt ist: + muss `imagePullCredentials` auf `SERVICE_ROLE` festgelegt sein. + Das Bild kann kein kuratiertes Bild oder ein Amazon ECR-Bild sein. **Umgebung/Typ imagePullCredentials** Optional. Der Typ der Anmeldeinformationen, die zum Abrufen von Images in Ihrem Build CodeBuild verwendet werden. Es gibt zwei gültige Werte: CODEBUILD `CODEBUILD`gibt an, dass es seine eigenen Anmeldeinformationen CodeBuild verwendet. Sie müssen Ihre Amazon ECR-Repository-Richtlinie bearbeiten, um dem CodeBuild Service Principal zu vertrauen. SERVICE\$1ROLE Gibt an, dass die Servicerolle Ihres Build-Projekts CodeBuild verwendet wird. Wenn Sie ein kontoübergreifendes oder privates Registrierungs-Image verwenden, müssen Sie `SERVICE_ROLE`-Anmeldeinformationen verwenden. Wenn Sie ein CodeBuild kuratiertes Image verwenden, müssen Sie `CODEBUILD` Anmeldeinformationen verwenden. **Umgebung/ PrivilegedMode** `true`Nur festlegen, wenn Sie dieses Build-Projekt zum Erstellen von Docker-Images verwenden möchten. Andernfalls schlagen alle zugehörigen Builds fehl, die versuchen, mit dem Docker-Daemon zu interagieren. Sie müssen zudem den Docker-Daemon müssen, damit Ihre Builds interagieren können. Eine Möglichkeit besteht darin, den Docker-Daemon in der `install`-Phase der buildspec-Datei zu initialisieren, indem Sie die folgenden Build-Befehle ausführen. Führen Sie diese Befehle nicht aus, wenn Sie ein Build-Umgebungs-Image angegeben haben, das von CodeBuild mit Docker-Support bereitgestellt wird. Standardmäßig ist der Docker-Daemon für Nicht-VPC-Builds aktiviert. Wenn Sie Docker-Container für VPC-Builds verwenden möchten, lesen Sie auf der Docker Docs-Website unter [Runtime Privilege and Linux Capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) nach und aktivieren Sie den privilegierten Modus. Außerdem unterstützt Windows den privilegierten Modus nicht. ``` - 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" ``` #### serviceRole Erforderlich Der ARN der Servicerolle, der CodeBuild verwendet wird, um im Namen des Benutzers mit Diensten zu interagieren (z. B.`arn:aws:iam::account-id:role/role-name`). #### autoRetryLimit Optional. Die Anzahl zusätzlicher automatischer Wiederholungen nach einem fehlgeschlagenen Build. Wenn das Limit für automatische Wiederholungen beispielsweise auf 2 festgelegt ist, CodeBuild wird die `RetryBuild` API aufgerufen, um Ihren Build automatisch bis zu 2 weitere Male zu wiederholen. #### timeoutInMinutes Optional. Die Anzahl der Minuten, zwischen 5 und 2160 (36 Stunden), nach der der Build CodeBuild gestoppt wird, falls er nicht abgeschlossen ist. Wenn Sie keinen anderen Wert angeben, wird der Standardwert von 60 verwendet. Führen Sie den Befehl aus, um festzustellen, ob und wann ein Build aufgrund eines Timeouts CodeBuild gestoppt wurde. `batch-get-builds` Überprüfen Sie die Ausgabe eines `buildStatus`-Werts von `FAILED`, um festzustellen, ob ein Build-Vorgang angehalten wurde. Überprüfen Sie die Ausgabe des `endTime`-Werts in Verbindung mit einem `phaseStatus`-Wert von `TIMED_OUT`, um festzustellen, wann die Zeitbeschränkung bei einem Build-Vorgang überschritten wurde. #### queuedTimeoutInMinuten Optional. Die Anzahl der Minuten zwischen 5 und 480 (8 Stunden), nach denen der Build CodeBuild gestoppt wird, falls er sich noch in der Warteschlange befindet. Wenn Sie keinen anderen Wert angeben, wird der Standardwert von 60 verwendet. #### encryptionKey Optional. Der Alias oder ARN des, der von AWS KMS key verwendet wird CodeBuild , um die Build-Ausgabe zu verschlüsseln. Verwenden Sie zur Angabe eines Alias das Format `arn:aws:kms:region-ID:account-ID:key/key-ID` oder (bei vorhandenem Alias) `alias/key-alias`. Falls nicht angegeben, wird der AWS-managed KMS-Schlüssel für Amazon S3 verwendet. #### tags Optional. Ein Array von [Tag-Objekten](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Tag.html), die die Tags bereitstellen, die Sie diesem Build-Projekt zuordnen möchten. Sie können bis zu 50 Tags angeben. Diese Tags können von jedem AWS Dienst verwendet werden, der CodeBuild Build-Projekt-Tags unterstützt. Jedes Tag wird als Objekt mit a `key` und a ausgedrückt`value`. #### vpcConfig Optional. Ein [VpcConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_VpcConfig.html)Objekt, das Informationsinformationen zur VPC-Konfiguration für Ihr Projekt enthält. Weitere Informationen finden Sie unter [Verwendung AWS CodeBuild mit Amazon Virtual Private Cloud](vpc-support.md). Zu diesen Eigenschaften gehören: vpcId Erforderlich Die VPC-ID, die CodeBuild verwendet wird. Führen Sie diesen Befehl aus, um eine Liste aller VPC IDs in Ihrer Region abzurufen: ``` aws ec2 describe-vpcs --region ``` Subnetze Erforderlich Eine Reihe von Subnetzen IDs , die Ressourcen enthalten, die von verwendet werden. CodeBuild Führen Sie diesen Befehl aus, um Folgendes zu erhalten: IDs ``` aws ec2 describe-subnets --filters "Name=vpc-id,Values=" --region ``` securityGroupIds Erforderlich Ein Array von Sicherheitsgruppen, das von IDs verwendet wird CodeBuild , um den Zugriff auf Ressourcen in der VPC zu ermöglichen. Führen Sie diesen Befehl aus, um Folgendes zu erhalten: IDs ``` aws ec2 describe-security-groups --filters "Name=vpc-id,Values=" -- ``` #### badgeEnabled Optional. Gibt an, ob Build-Badges in Ihr Projekt aufgenommen werden sollen. CodeBuild Stellen Sie diese Option auf `true` ein, um Build-Badges zu aktivieren, oder `false` auf eine andere Einstellung. Weitere Informationen finden Sie unter [Beispiel für Badges erstellen mit CodeBuild](sample-build-badges.md). #### LogsConfig Ein [LogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_LogsConfig.html)Objekt, das Informationen darüber enthält, wo sich die Logs dieses Builds befinden. LogsConfig/ **cloudWatchLogs** Ein [CloudWatchLogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CloudWatchLogsConfig.html)Objekt, das Informationen darüber enthält, wie Logs in Logs übertragen werden. CloudWatch **LogsConfig/ S3Logs** Ein [LogsConfigS3-Objekt](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_S3LogsConfig.html), das Informationen zur Übertragung von Protokollen an Amazon S3 enthält. #### fileSystemLocations Optional. Eine Reihe von [ProjectFileSystemsLocation](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectFileSystemLocation.html)Objekten, die Informationen über Ihre Amazon EFS-Konfiguration enthalten. #### buildBatchConfig Optional. Das `buildBatchConfig` Objekt ist eine [ProjectBuildBatchConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectBuildBatchConfig.html)Struktur, die die Batch-Build-Konfigurationsinformationen für das Projekt enthält. buildBatchConfig/**serviceRole** Die Dienstrolle ARN für das Batch-Build-Projekt. buildBatchConfig/**Kombiniere Artefakte** Ein boolescher Wert, der angibt, ob die Build-Artefakte für den Batch-Build an einem einzigen Artefakt-Speicherort kombiniert werden sollen. buildBatchConfig/Einschränkungen/ **maximumBuildsAllowed** Die maximal zulässige Anzahl von Builds. buildBatchConfig/Einschränkungen/ **computeTypesAllowed** Ein Array von Zeichenfolgen, die die Datenverarbeitungstypen angeben, die für den Stapel-Build zulässig sind. Informationen zu diesen Werten finden Sie unter [Berechnungstypen für die Build-Umgebung](https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-compute-types.html). buildBatchConfig**/restrictions/ flottenAllowed** Ein Array von Zeichenketten, die die Flotten angeben, die für den Batch-Build zulässig sind. Weitere Informationen finden [Sie unter Builds auf Flotten mit reservierter Kapazität ausführen](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html). buildBatchConfig/**timeoutInMinutes** Die maximale Zeit in Minuten, in der der Batch-Build abgeschlossen sein muss. buildBatchConfig/**batchReportMode** Gibt an, wie Build-Statusberichte an den Quellanbieter für den Batch-Build gesendet werden. Gültige Werte sind: `REPORT_AGGREGATED_BATCH` (Standard) Aggregieren Sie alle Erstellungsstatus in einem einzigen Statusbericht. `REPORT_INDIVIDUAL_BUILDS` Senden Sie für jeden einzelnen Build einen separaten Statusbericht. #### concurrentBuildLimit Die maximale Anzahl gleichzeitiger Builds, die für dieses Projekt zulässig sind. Neue Builds werden nur gestartet, wenn die aktuelle Anzahl der Builds dieses Limit unterschreitet oder ihm entspricht. Wenn die aktuelle Build-Anzahl dieses Limit erreicht, werden neue Builds gedrosselt und nicht ausgeführt. ### Erstellen des Projekts Um das Projekt zu erstellen, führen Sie den **[https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html)** Befehl erneut aus und übergeben Sie Ihre JSON-Datei: ``` aws codebuild create-project --cli-input-json file:// ``` Bei Erfolg wird die JSON-Darstellung eines [Projektobjekts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html) in der Konsolenausgabe angezeigt. Ein Beispiel für diese Daten finden Sie in der [CreateProject Antwortsyntax](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CreateProject.html#API_CreateProject_ResponseSyntax). Abgesehen vom Namen des Build-Projekts können Sie alle Einstellungen des Build-Projekts zu einem späteren Zeitpunkt ändern. Weitere Informationen finden Sie unter [Ändern der Einstellungen eines Build-Projekts (AWS CLI)](change-project.md#change-project-cli). Weitere Informationen zum Starten der Build-Ausführung finden Sie in [Ausführen eines Build (AWS CLI)](run-build-cli.md). Wenn Ihr Quellcode in einem GitHub Repository gespeichert ist und Sie den Quellcode jedes Mal neu erstellen CodeBuild möchten, wenn eine Codeänderung in das Repository übertragen wird, finden Sie weitere Informationen unter[Ausführung von Builds automatisch starten (AWS CLI)](run-build-cli-auto-start.md). ## Erstellen eines Build-Projekts (AWS SDKs) Informationen zur Verwendung AWS CodeBuild mit dem AWS SDKs finden Sie unter[AWS SDKs und Werkzeug-Referenz](sdk-ref.md). ## Erstellen eines Build-Projekts (CloudFormation) Informationen zur Verwendung von AWS CodeBuild mit CloudFormation finden Sie in [der CloudFormation Vorlage für CodeBuild](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-project.html) im *AWS CloudFormation Benutzerhandbuch*.