Erstellen Sie ein Build-Projekt (Konsole) - AWS CodeBuild
ProjektkonfigurationQuelleUmgebungBuild-SpezifikationBatch-Konfiguration-ArtefakteLogs (Protokolle)

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 (Konsole)

Öffnen Sie die -AWS CodeBuildKonsole unter https://console.aws.amazon.com/codesuite/codebuild/home.

Wenn eine CodeBuild Informationsseite angezeigt wird, wählen Sie Build-Projekt erstellen aus. Erweitern Sie andernfalls im Navigationsbereich Build , wählen Sie Build-Projekte und dann Build-Projekt erstellen 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 Build-Projekt erstellen aus.

Projektkonfiguration

Project name

Geben Sie einen Namen für dieses Build-Projekt ein. Build-Projektnamen müssen in allen AWS-Konten eindeutig sein.

Beschreibung

Geben Sie eine optionale Beschreibung des Build-Projekts ein, um anderen Benutzern zu helfen zu verstehen, wofür dieses Projekt verwendet wird.

Abzeichen erstellen

(Optional) Wählen Sie Build-Auszeichnung aktivieren aus, um den Build-Status Ihres Projekts sichtbar und einbettbar zu machen. Weitere Informationen finden Sie unter Build Badges-Beispiel.

Anmerkung

Build-Abzeichen gelten nicht, wenn Ihr Quellanbieter Amazon S3 ist.

Gleichzeitiges Build-Limit aktivieren

(Optional) Wenn Sie die Anzahl der gleichzeitigen Builds für dieses Projekt begrenzen möchten, führen Sie die folgenden Schritte aus:

  1. Wählen Sie Anzahl der gleichzeitigen Builds einschränken aus, mit denen dieses Projekt starten kann.

  2. Geben Sie unter Limit für gleichzeitige Builds die maximale Anzahl gleichzeitiger Builds ein, die für dieses Projekt zulässig sind. Dieses Limit darf nicht größer sein als das für das Konto festgelegte Limit für gleichzeitige Builds. 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 unter Tags Namen und Werte für Tags ein, die in unterstützten AWS-Services 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 Quellcode-Anbietertyp aus. Verwenden Sie die folgenden Listen, um eine Auswahl zu treffen, die für Ihren Quellanbieter geeignet ist:

Anmerkung

CodeBuild unterstützt Bitbucket Server nicht.

Amazon S3
Bucket

Wählen Sie den Namen des Eingabe-Buckets aus, 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.

CodeCommit
Repository

Wählen Sie das Repository aus, das Sie verwenden möchten.

Referenztyp

Wählen Sie Verzweigung , Git-Tag oder Commit-ID, um die Version Ihres Quellcodes anzugeben. Weitere Informationen finden Sie unter Beispiel für eine Quellversion mit AWS CodeBuild.

Anmerkung

Wir empfehlen Ihnen, Git-Verzweigungsnamen auszuwählen, die nicht wie Commit-IDs aussehen, z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder 5392f7. Auf diese Weise können Sie Git-Checkout-Konflikte mit tatsächlichen Commits vermeiden.

Git-Klontiefe

Wählen Sie , um einen flachen Klon mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt wurde. 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
Repository

Wählen Sie Verbinden über OAuth oder Verbinden mit einem Bitbucket-App-Passwort und folgen Sie den Anweisungen, um eine Verbindung mit Bitbucket herzustellen (oder erneut zu verbinden).

Wählen Sie ein öffentliches Repository oder ein Repository in Ihrem Konto aus.

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.

Anmerkung

Wir empfehlen Ihnen, Git-Verzweigungsnamen auszuwählen, die nicht wie Commit-IDs aussehen, z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder 5392f7. Auf diese Weise können Sie Git-Checkout-Konflikte mit tatsächlichen Commits vermeiden.

Git-Klontiefe

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 an den Quellanbieter melden aus, wenn Ihre Builds gestartet und abgeschlossen werden sollen, wenn der Status des Starts und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet werden soll.

Um den Build-Status an den Quellanbieter melden zu können, muss der dem Quellanbieter zugeordnete 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 Quellanbieter.

Geben Sie für Statuskontext den Wert ein, der für den name Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter Build in der Bitbucket-API-Dokumentation.

Geben Sie für Ziel-URL den Wert ein, der für den url Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter Build in der Bitbucket-API-Dokumentation.

Der Status eines von einem Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Um den Status eines Builds zu erhalten, der über die Konsole gestartet wird, oder einen API-Aufruf, der dem 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 Webhook-Ereignisse der primären Quelle die Option Neu erstellen aus, wenn eine Codeänderung an dieses Repository übertragen wird, wenn Sie den Quellcode jedes Mal erstellen CodeBuild möchten, wenn eine Codeänderung an dieses Repository übertragen wird. Weitere Informationen zu Webhooks und Filtergruppen finden Sie unter Bitbucket-Webhook-Ereignisse.

GitHub
Repository

Wählen Sie Verbinden mit OAuth oder Verbinden mit einem GitHub persönlichen Zugriffstoken und folgen Sie den Anweisungen, um eine Verbindung zu herzustellen (oder erneut eine Verbindung herzustellen) GitHub und den Zugriff auf zu autorisierenAWS CodeBuild.

Wählen Sie ein öffentliches Repository oder ein Repository in Ihrem Konto aus.

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.

Anmerkung

Wir empfehlen Ihnen, Git-Verzweigungsnamen auszuwählen, die nicht wie Commit-IDs aussehen, z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder 5392f7. Auf diese Weise können Sie Git-Checkout-Konflikte mit tatsächlichen Commits vermeiden.

Git-Klontiefe

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 an den Quellanbieter melden aus, wenn Ihre Builds gestartet und abgeschlossen werden sollen, wenn Sie möchten, dass der Status des Starts und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird.

Um den Build-Status an den Quellanbieter melden zu können, muss der dem Quellanbieter zugeordnete 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 Quellanbieter.

Geben Sie für Statuskontext den Wert ein, der für den context Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub Entwicklerhandbuch für .

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 unter Erstellen eines Commit-Status im GitHub Entwicklerhandbuch für .

Der Status eines von einem Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Um den Status eines Builds zu erhalten, der über die Konsole gestartet wird, oder einen API-Aufruf, der dem 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 Webhook-Ereignisse der primären Quelle die Option Neu erstellen aus, wenn eine Codeänderung an dieses Repository übertragen wird, wenn Sie den Quellcode jedes Mal erstellen CodeBuild möchten, wenn eine Codeänderung an dieses Repository übertragen wird. Weitere Informationen zu Webhooks und Filtergruppen finden Sie unter GitHub Webhook-Ereignisse.

GitHub Enterprise Server
GitHub Persönliches Zugriffstoken für Unternehmen

GitHub Beispiel für Enterprise Server Informationen zum Kopieren eines persönlichen Zugriffstokens in Ihre Zwischenablage finden Sie unter . Fügen Sie das Token in das Textfeld ein und wählen Sie anschließend Save Token (Token speichern) aus.

Anmerkung

Sie müssen das private Zugriffstoken nur einmal eingeben und speichern. CodeBuild verwendet dieses Token in allen zukünftigen Projekten.

Quellversion

Geben Sie eine Pull-Anforderung, Verzweigung, Commit-ID, Tag oder Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter Beispiel für eine Quellversion mit AWS CodeBuild.

Anmerkung

Wir empfehlen Ihnen, Git-Verzweigungsnamen auszuwählen, die nicht wie Commit-IDs aussehen, z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder 5392f7. Auf diese Weise können Sie Git-Checkout-Konflikte mit tatsächlichen Commits vermeiden.

Git-Klontiefe

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 an den Quellanbieter melden aus, wenn Ihre Builds gestartet und abgeschlossen werden sollen, wenn Sie möchten, dass der Status des Starts und Abschlusses Ihres Builds Ihrem Quellanbieter gemeldet wird.

Um den Build-Status an den Quellanbieter melden zu können, muss der dem Quellanbieter zugeordnete 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 Quellanbieter.

Geben Sie für Statuskontext den Wert ein, der für den context Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub Entwicklerhandbuch für .

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 unter Erstellen eines Commit-Status im GitHub Entwicklerhandbuch für .

Der Status eines von einem Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Um den Status eines Builds zu erhalten, der über die Konsole gestartet wird, oder einen API-Aufruf, der dem 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 aus, um SSL-Warnungen zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise-Projekt-Repository herstellen.

Wählen Sie unter Webhook-Ereignisse der primären Quelle die Option Neu erstellen aus, 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 Informationen zu Webhooks und Filtergruppen finden Sie unter GitHub Webhook-Ereignisse.

Umgebung

Bereitstellungsmodell

Führen Sie eine der folgenden Aktionen aus:

  • Um On-Demand-Flotten zu verwenden, die von verwaltet werdenAWS CodeBuild, wählen Sie On-Demand . Bei On-Demand-Flotten CodeBuild bietet Rechenleistung für Ihre Builds. Die Maschinen werden nach Abschluss des Builds zerstört. On-Demand-Flotten werden vollständig verwaltet und umfassen automatische Skalierungsfunktionen, um Nachfragespitzen zu bewältigen.

  • Um Flotten mit reservierter Kapazität zu verwenden, die von verwaltet werdenAWS 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, können sofort Builds oder Tests verarbeiten und reduzieren die Build-Dauer. Bei Flotten mit reservierter Kapazität laufen Ihre Maschinen immer und verursachen weiterhin Kosten, solange sie bereitgestellt werden.

Weitere Informationen finden Sie unter Arbeiten mit reservierter Kapazität in AWS CodeBuild.

Umgebungs-Image

Führen Sie eine der folgenden Aktionen aus:

  • Um ein Docker-Image zu verwenden, das von AWS CodeBuild verwaltet wird, wählen Sie Managed image (Verwaltetes Image) aus und wählen Sie anschließend die gewünschten Optionen für Operating system (Betriebssystem), Runtime (Laufzeit), Image und Image version (Image-Version) aus. 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 für Umgebungstyp ARM ,Linux ,Linux GPU oder Windows aus. Wenn Sie Andere Registrierung auswählen, geben Sie für Externe Registrierungs-URL den Namen und das Tag des Docker-Images in Docker Hub im Format eindocker repository/docker image name. Wenn Sie Amazon ECR wählen, verwenden Sie das Amazon-ECR-Repository und das Amazon-ECR-Image, um das Docker-Image in Ihrem AWS Konto auszuwählen.

  • Um ein privates Docker-Image zu verwenden, wählen Sie Benutzerdefiniertes Image aus. Wählen Sie für 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? im AWS Secrets Manager-Benutzerhandbuch.

Anmerkung

CodeBuild überschreibt die ENTRYPOINT für benutzerdefinierte Docker-Images.

Datenverarbeitung

Führen Sie eine der folgenden Aktionen aus:

  • Um EC2-Computing zu verwenden, wählen Sie EC2. EC2-Computing bietet optimierte Flexibilität bei Aktionsausführungen.

  • Um Lambda-Datenverarbeitung zu verwenden, wählen Sie Lambda aus. Lambda Compute bietet optimierte Startup-Geschwindigkeiten für Ihre Builds. Lambda unterstützt schnellere Builds aufgrund einer geringeren Startlatenz. Lambda skaliert auch automatisch, sodass Builds nicht in der Warteschlange auf ihre Ausführung warten. Weitere Informationen finden Sie unter Arbeiten mit AWS Lambda Datenverarbeitung in AWS CodeBuild.

Servicerolle

Führen Sie eine der folgenden Aktionen aus:

  • Wenn Sie keine CodeBuild Servicerolle haben, wählen Sie Neue Servicerolle aus. Geben Sie unter Rollenname einen Namen für die neue Rolle ein.

  • Wenn Sie über eine CodeBuild Servicerolle verfügen, wählen Sie Vorhandene Servicerolle aus. Wählen Sie unter Rollen-ARN die Servicerolle aus.

Anmerkung

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
Timeout (Zeitüberschreitung)

Geben Sie einen Wert zwischen 5 Minuten und 8 Stunden an, nach dem den Build CodeBuild stoppt, wenn 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 möchten, dass Ihre Builds nur dann erhöhte Berechtigungen 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 Build-Umgebungs-Image ausgewählt haben, das von CodeBuild mit Docker-Unterstützung bereitgestellt wird.

Anmerkung

Standardmäßig ist Docker-Daemon für Nicht-VPC-Builds aktiviert. Wenn Sie Docker-Container für VPC-Builds verwenden möchten, finden Sie weitere Informationen unter Laufzeitberechtigung und Linux-Funktionen auf der Docker-Docs-Website 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 CodeBuild arbeiten möchten:

  • Wählen Sie für VPC die VPC-ID aus, die CodeBuild verwendet.

  • Wählen Sie für VPC-Subnetze die Subnetze aus, die Ressourcen enthalten, die CodeBuild verwendet.

  • Wählen Sie für VPC-Sicherheitsgruppen die Sicherheitsgruppen aus, die CodeBuild verwendet, um den Zugriff auf Ressourcen in den VPCs zu ermöglichen.

Weitere Informationen finden Sie unter BenutzenAWS CodeBuildmit Amazon Virtual Private Cloud.

Datenverarbeitung

Wählen Sie eine der verfügbaren Optionen aus.

Umgebungsvariablen

Geben Sie den Namen und den Wert ein und wählen Sie dann den Typ jeder zu verwendenden Umgebungsvariablen aus.

Anmerkung

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_ACCOUNT_ID

  • IMAGE_REPO_NAME

  • IMAGE_TAG

Konsolen-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.

Es wird empfohlen, eine Umgebungsvariable mit einem sensiblen Wert, wie z. B. eine AWS Zugriffsschlüssel-ID, einen AWS geheimen Zugriffsschlüssel oder ein Passwort, als Parameter im Amazon EC2 Systems Manager Parameter Store oder zu speichernAWS Secrets Manager.

Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, wählen Sie für Typ die Option Parameter aus. Geben Sie für Name eine Kennung ein, auf die verwiesen werden CodeBuild soll. Geben Sie für Wert 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.

Wichtig

Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, empfehlen wir, Parameter mit Parameternamen zu speichern, die mit beginnen /CodeBuild/ (z. B. /CodeBuild/dockerLoginPassword). 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 den KMS-Schlüssel den ARN eines -AWS KMSSchlüssels in Ihrem Konto angeben. Amazon EC2 Systems Manager verwendet diesen Schlüssel, um den Wert des Parameters während des Speichers zu verschlüsseln und während des Abrufs zu entschlüsseln.) Wenn Sie die CodeBuild Konsole verwenden, um einen Parameter zu erstellen, startet die Konsole den Parameternamen mit , /CodeBuild/ während er gespeichert wird. Weitere Informationen finden Sie unter Systems Manager Parameter Store und Systems Manager Parameter Store Console Walkthrough im Amazon EC2 Systems Manager-Benutzerhandbuch.

Wenn sich Ihr Build-Projekt auf Parameter bezieht, die im Amazon EC2 Systems Manager Parameter Store gespeichert sind, muss die Servicerolle des Build-Projekts die ssm:GetParameters Aktion zulassen. Wenn Sie zuvor Neue Servicerolle ausgewählt haben, CodeBuild schließt diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt ein. 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 bezieht, die im Amazon EC2 Systems Manager Parameter Store mit Parameternamen gespeichert sind, die nicht mit beginnen/CodeBuild/, und Sie Neue Servicerolle ausgewählt haben, müssen Sie diese Servicerolle aktualisieren, um den Zugriff auf Parameternamen zu ermöglichen, 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, enthält die Servicerolle die Berechtigung zum Entschlüsseln aller Parameter im /CodeBuild/ Namespace im Amazon EC2 Systems Manager Parameter Store.

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 Typ die Option Secrets Manager aus. Geben Sie für Name eine Kennung ein, auf die verwiesen werden CodeBuild 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.

Wichtig

Wenn Sie Secrets Manager verwenden, empfehlen wir Ihnen, Secrets zu speichern, deren Namen mit beginnen /CodeBuild/ (z. B. /CodeBuild/dockerLoginPassword). Weitere Informationen finden Sie unter Was ist AWS Secrets Manager? im AWS Secrets Manager-Benutzerhandbuch.

Wenn sich Ihr Build-Projekt auf Secrets bezieht, die in Secrets Manager gespeichert sind, muss die Servicerolle des Build-Projekts die secretsmanager:GetSecretValue Aktion zulassen. Wenn Sie zuvor Neue Servicerolle ausgewählt haben, CodeBuild schließt diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt ein. 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 Secrets bezieht, die in Secrets Manager mit Secret-Namen gespeichert sind, die nicht mit beginnen/CodeBuild/, und Sie Neue Servicerolle ausgewählt haben, müssen Sie die Servicerolle aktualisieren, um den Zugriff auf Secret-Namen zu erlauben, die nicht mit beginnen/CodeBuild/. Dies liegt daran, dass die Servicerolle nur Zugriff auf geheime Namen gewährt, die mit beginnen/CodeBuild/.

Wenn Sie Neue Servicerolle auswählen, enthält die Servicerolle die Berechtigung zum Entschlüsseln aller Secrets unter dem /CodeBuild/ Namespace im Secrets Manager.

Build-Spezifikation

Build-Spezifikationen

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 aus dem Quellstamm unter Buildspec-Name ein (z. B. buildspec-two.yml oder configuration/buildspec.yml. Wenn sich die buildspec-Datei in einem S3-Bucket befindet, muss sie sich in derselben AWS Region wie Ihr Build-Projekt befinden. Geben Sie die buildspec-Datei mit ihrem ARN an (z. B. arn:aws:s3:::<my-codebuild-sample2>/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 eine lange Liste von Befehlen für die -buildPhase zu haben, fügen Sie eine buildspec.yml Datei zum Quellcode-Stammverzeichnis hinzu, fügen Sie die Befehle der Datei hinzu und wählen Sie dann im Quellcode-Stammverzeichnis die Option buildspec.yml verwenden aus.

Weitere Informationen hierzu finden Sie unter Build-Spezifikationsreferenz.

Batch-Konfiguration

Sie können eine Gruppe von Builds als einen einzigen Vorgang ausführen. Weitere Informationen finden Sie unter Batch-Builds in AWS CodeBuild.

Definieren der Batch-Konfiguration

Wählen Sie aus, 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 unter Servicerolle einen Namen für die neue Rolle ein.

  • Wenn Sie über eine Batch-Servicerolle verfügen, wählen Sie Vorhandene 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 in Ihrem Namen die RetryBuild Aktionen StartBuild, und aufrufen CodeBuild kannStopBuild, um Builds als Teil eines Batches auszuführen. Kunden sollten aus zwei Gründen eine neue und nicht dieselbe Rolle verwenden, die sie in ihrem Build verwenden:

  • Wenn Sie der Build-Rolle StartBuild-, - und -RetryBuildBerechtigungen erteilenStopBuild, kann ein einzelner Build mehr Builds über die Build-Spezifikation starten.

  • CodeBuild Batch-Builds bieten Einschränkungen, die die Anzahl der Builds und Rechentypen einschränken, die für die Builds im Batch verwendet werden können. Wenn die Build-Rolle über diese Berechtigungen verfügt, könnten die Builds selbst diese Einschränkungen umgehen.

Zulässiger Rechentyp(e) für Batch

Wählen Sie die für den Batch zulässigen Datenverarbeitungstypen aus. Wählen Sie alle zutreffenden aus.

Maximale Anzahl zulässiger Builds im Batch

Geben Sie die maximale Anzahl von Builds ein, die im Batch zulässig sind. Wenn ein Batch diesen Grenzwert überschreitet, schlägt der Batch fehl.

Batch-Timeout

Geben Sie die maximale Zeitspanne ein, bis der Stapelaufbau abgeschlossen ist.

Kombinieren von Artefakten

Wählen Sie Alle Artefakte aus Batch an einem einzigen Ort kombinieren aus, damit alle Artefakte aus dem Batch an einem einzigen Ort zusammengefasst werden.

Batch-Berichtsmodus

Wählen Sie den gewünschten Build-Statusberichtsmodus für Batch-Builds aus.

Anmerkung

Dieses Feld ist nur verfügbar GitHub, wenn die Projektquelle Bitbucket oder GitHub Enterprise ist, und Build-Status an den Quellanbieter melden, wenn Ihre Builds gestartet und beendet werden, ist unter Quelle ausgewählt.

Aggregierte Builds

Wählen Sie aus, damit die Status für alle Builds im Batch zu einem einzigen Statusbericht zusammengefasst werden.

Einzelne Builds

Wählen Sie aus, damit die Build-Status für alle Builds im Batch separat gemeldet werden.

-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 pushen 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.

    • 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.

    • 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.

  2. Wählen Sie Add artifact (Artefakt hinzufügen) aus.

  3. Führen Sie die vorherigen Schritte aus, um die sekundären Artefakte zu konfigurieren.

  4. Wählen Sie Save artifact (Artefakt speichern) aus.

Zusätzliche Konfiguration
Verschlüsselungsschlüssel

(Optional) Führen Sie eine der folgenden Optionen aus:

  • Um die Von AWS verwalteter Schlüssel für Amazon S3 in Ihrem Konto zum Verschlüsseln 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 unter 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 Cache-Pfadpräfix ein Amazon 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. Weitere Informationen zum Caching finden Sie unter Build-Caching in AWS CodeBuild.

Logs (Protokolle)

Wählen Sie die Protokolle aus, die Sie erstellen möchten. Sie können Amazon CloudWatch Logs, Amazon S3-Protokolle oder beides erstellen.

CloudWatch

Wenn Sie Amazon- CloudWatch Logs-Protokolle benötigen:

CloudWatch Protokolle

Wählen Sie CloudWatch logs (CW-Protokolle).

Group name (Gruppenname)

Geben Sie den Namen Ihrer Amazon- CloudWatch Logs-Protokollgruppe ein.

Stream-Name

Geben Sie den Namen Ihres Amazon- CloudWatch Logs-Protokollstreams ein.

S3

Wenn Sie Amazon S3-Protokolle benötigen:

S3-Protokolle

Wählen Sie S3 logs (S3-Protokolle).

Bucket

Wählen Sie den Namen des S3-Buckets für Ihre Protokolle aus.

Pfadpräfix

Geben Sie das Präfix für Ihre Protokolle ein.

Deaktivieren der S3-Protokollverschlüsselung

Wählen Sie aus, wenn Ihre S3-Protokolle nicht verschlüsselt werden sollen.