Ändern der Einstellungen eines Build-Projekts (Konsole)

Führen Sie zum Ändern der Einstellungen für ein Build-Projekt das folgende Verfahren durch:

1. Öffnen SieAWS CodeBuildconsole beihttps://console.aws.amazon.com/codesuite/codebuild/homeaus.

2. Wählen Sie im linken Navigationsbereich Build projects aus.

3. Führen Sie eine der folgenden Aufgaben aus:

   • Klicken Sie auf den Link des Build-Projekts, das Sie bearbeiten möchten, und klicken Sie dann auf Build details (Build-Details).

   • Aktivieren Sie das Optionsfeld neben dem Build-Projekt, das Sie ändern möchten, klicken Sie auf View details (Details anzeigen) und klicken Sie dann auf Build details (Build-Details).

Sie können die folgenden Abschnitte ändern:

Projektkonfiguration

In derProjektkonfiguration-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieUpdate-Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern.

Beschreibung

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

Badge-Status

Wählen Sie Enable build badge (Build Badge aktivieren) aus, damit der Build-Status Ihres Projekts sichtbar und integrierbar ist. Weitere Informationen finden Sie unter Build Badges-Beispiel.

Anmerkung

Build Badge gilt nicht, wenn Ihr Quellanbieter Amazon S3 ist.

Gleichzeitiges Build-Limit aktivieren

Führen Sie zum Beschränken der Anzahl gleichzeitiger Builds für dieses Projekt folgende Schritte aus:

1. SelectBeschränken Sie die Anzahl gleichzeitiger Builds, die dieses Projekt starten kannaus.

2. In :Gleichzeitiges Build-Limit, geben Sie 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 gleichzeitige Build-Limit. Wenn Sie versuchen, eine Zahl einzugeben, die größer als das Kontolimit ist, 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.

Öffentliche Build-Zugriff aktivieren

Um die Build-Ergebnisse Ihres Projekts der Öffentlichkeit zugänglich zu machen, einschließlich Benutzern ohne Zugriff auf eineAWSAccount und wählen Sie ausÖffentliche Build-Zugriff aktivierenUnd bestätigen Sie, dass Sie die Build-Ergebnisse öffentlich machen möchten. Die folgenden Eigenschaften werden für öffentliche Build-Projekte verwendet:

Rolle des öffentlichen Build-Dienstes

SelectNeue DienstrolleWenn Sie möchten, dass CodeBuild eine neue Servicerolle für Sie erstellt, oderVorhandene ServicerolleWenn Sie eine vorhandene Servicerolle verwenden möchten.

Die Rolle des öffentlichen Build-Dienstes ermöglicht CodeBuild, die CloudWatch Logs zu lesen und die Amazon S3 S3-Artefakte für die Builds des Projekts herunterzuladen. Dies ist erforderlich, um die Build-Protokolle und Artefakte des Projekts der Öffentlichkeit zugänglich zu machen.

Servicerolle

Geben Sie den Namen der neuen Servicerolle oder einer vorhandenen Servicerolle ein.

Um die Build-Ergebnisse Ihres Projekts privat zu machen, klarÖffentliche Build-Zugriff aktivierenaus.

Weitere Informationen finden Sie unter Öffentliche Build-Projekte inAWS CodeBuild.

Warnung

Beachten Sie Folgendes, wenn Sie die Build-Ergebnisse Ihres Projekts veröffentlichen:

• Alle Build-Ergebnisse, Protokolle und Artefakte eines Projekts, einschließlich Builds, die ausgeführt wurden, als das Projekt privat war, stehen der Öffentlichkeit zur Verfügung.

• Alle Build-Protokolle und Artefakte sind der Öffentlichkeit zugänglich. Umgebungsvariablen, Quellcode und andere sensible Informationen wurden möglicherweise an die Build-Protokolle und Artefakte ausgegeben. Sie müssen vorsichtig sein, welche Informationen an die Build-Protokolle ausgegeben werden. Einige Best Practices sind:

  • Speichern Sie keine sensiblen Werte, insbesondereAWSZugriff auf Schlüssel-IDs und geheime Zugriffsschlüssel in Umgebungsvariablen. Wir empfehlen Ihnen, einen Amazon EC2 Systems Manager Parameter Store zu verwenden oderAWS Secrets Managerum sensible Werte zu speichern.

  • FollowBewährte Methoden für die Verwendung von Webhooksum zu beschränken, welche Entitäten einen Build auslösen können und die Buildspec nicht im Projekt selbst speichern, um sicherzustellen, dass Ihre Webhooks so sicher wie möglich sind.

• Ein böswilliger Benutzer kann öffentliche Builds verwenden, um bösartige Artefakte zu verteilen. Wir empfehlen Projektadministratoren, alle Pull-Anfragen zu überprüfen, um zu überprüfen, ob es sich bei der Pull-Anfrage um eine legitime Änderung handelt. Wir empfehlen Ihnen auch, alle Artefakte mit ihren Prüfsummen zu validieren, um sicherzustellen, dass die richtigen Artefakte heruntergeladen werden.

Zusätzliche Informationen

FürTagsGeben Sie den Namen und den Wert aller Tags ein, die unterstützt werden sollenAWSzu verwendende Dienste. Verwenden Sie Add row, um ein Tag hinzuzufügen. Sie können bis zu 50 Tags hinzufügen.

Source

In derSource-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Quellanbieter

Wählen Sie den Quellcode-Anbietertyp aus. Mithilfe der folgenden Listen können Sie eine geeignete Auswahl für Ihren Quell-Anbieter treffen:

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 repräsentiert. 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

Klicken Sie aufVerzweigen,Git-Tag, oderCommit-IDum die Version Ihres Quellcodes anzugeben. Weitere Informationen finden Sie unter Beispiel für eine Quellversion mit AWS CodeBuild.

Git-Klons

Wählen Sie diese Option 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.

Bitbucket

Repository

Klicken Sie aufConnect Sie mit OAuthoderMit einem Bitbucket-App-Passwort ConnectFolgen Sie den Anweisungen, um eine Verbindung zu Bitbucket herzustellen (oder erneut herzustellen).

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

Quellversion

Geben Sie einen Branch, eine Commit-ID, einen Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unterBeispiel für eine Quellversion mit AWS CodeBuild

Git-Klons

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

SelectMelden Sie den Build-Status an den Quellanbieter, wenn Ihre Builds beginnen und beendenwenn der Status des Build-Starts und -Abschlusses an Ihren Quell-Anbieter gemeldet werden soll.

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

FürStatuskontextGeben Sie den Wert ein, der für denname-Parameter im Bitbucket-Commit-Status. Weitere Informationen finden Sie unter Build in der Bitbucket-API-Dokumentation.

FürZiel-URLGeben Sie den Wert ein, der für denurl-Parameter im Bitbucket-Commit-Status. Weitere Informationen finden Sie unter Build in der Bitbucket-API-Dokumentation.

Der Status eines durch einen Webhook ausgelösten Builds wird stets an den Quell-Anbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder ein API-Aufruf 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 ein neues Commit an das Repo schieben, damit eine Änderung dieser Einstellung wirksam wird.

In :Webhook-Ereignissewählen Sie aus.Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wirdWenn CodeBuild den Quellcode jedes Mal erstellt, sobald eine Codeänderung an dieses Repository übergeben wird. Weitere Informationen zu Webhooks und Filtergruppen finden Sie unter.Bitbucket-Webhook-Ereignissenaus.

GitHub

Repository

Klicken Sie aufConnect Sie mit OAuthoderConnect Sie sich mit einem persönlichen GitHub-Zugriffstokenund folgen Sie den Anweisungen, um sich mit GitHub zu verbinden (oder erneut neu zu verbinden) und den Zugriff aufAWS CodeBuildaus.

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

Quellversion

Geben Sie einen Branch, eine Commit-ID, einen Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unterBeispiel für eine Quellversion mit AWS CodeBuild

Git-Klons

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

SelectMelden Sie den Build-Status an den Quellanbieter, wenn Ihre Builds beginnen und beendenwenn der Status des Build-Starts und -Abschlusses an Ihren Quell-Anbieter gemeldet werden soll.

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

FürStatuskontextGeben Sie den Wert ein, der für dencontext-Parameter im GitHub-Commit-Status. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub-Entwicklerhandbuch.

FürZiel-URLGeben Sie den Wert ein, der für dentarget_url-Parameter im GitHub-Commit-Status. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub-Entwicklerhandbuch.

Der Status eines durch einen Webhook ausgelösten Builds wird stets an den Quell-Anbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder ein API-Aufruf 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 ein neues Commit an das Repo schieben, damit eine Änderung dieser Einstellung wirksam wird.

In :Webhook-Ereignissewählen Sie aus.Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wirdWenn CodeBuild den Quellcode jedes Mal erstellt, sobald eine Codeänderung an dieses Repository übergeben wird. Weitere Informationen zu Webhooks und Filtergruppen finden Sie unter.GitHub-Webhook-Ereignissenaus.

GitHub Enterprise Server

GitHub Enterprise persönlicher Zugriffstoken

Siehe .GitHub Enterprise Server-Beispielum Informationen darüber zu erhalten, wie Sie ein persönliches Zugriffs-Token in Ihre Zwischenablage kopieren. 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, einen Branch, eine Commit-ID, einen Tag oder eine Referenz und eine Commit-ID ein. Weitere Informationen finden Sie unter Beispiel für eine Quellversion mit AWS CodeBuild.

Git-Klons

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

SelectMelden Sie den Build-Status an den Quellanbieter, wenn Ihre Builds beginnen und beendenwenn der Status des Build-Starts und -Abschlusses an Ihren Quell-Anbieter gemeldet werden soll.

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

FürStatuskontextGeben Sie den Wert ein, der für dencontext-Parameter im GitHub-Commit-Status. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub-Entwicklerhandbuch.

FürZiel-URLGeben Sie den Wert ein, der für dentarget_url-Parameter im GitHub-Commit-Status. Weitere Informationen finden Sie unter Erstellen eines Commit-Status im GitHub-Entwicklerhandbuch.

Der Status eines durch einen Webhook ausgelösten Builds wird stets an den Quell-Anbieter gemeldet. Damit der Status eines Builds, der von der Konsole aus gestartet wird, oder ein API-Aufruf 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 ein neues Commit an das Repo schieben, damit eine Änderung dieser Einstellung wirksam wird.

Unsicheres SSL

Wählen Sie Enable insecure SSL (Unsicheres SSL aktivieren), um SSL-Warnungen zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise-Projekt-Repository einrichten.

In :Webhook-Ereignissewählen Sie aus.Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wirdWenn CodeBuild den Quellcode jedes Mal erstellt, sobald eine Codeänderung an dieses Repository übergeben wird. Weitere Informationen zu Webhooks und Filtergruppen finden Sie unter.GitHub-Webhook-Ereignissenaus.

Environment

In derUmgebung-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Umgebungs-Image

Um das Build-Image zu ändern, wählen SieÜberschreiben des Bildesund führen Sie einen der folgenden Schritte 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. FürUmgebungstyp, wählenARM,Linux,Linux-GPU, oderWindowsaus. Wenn Sie angebenAndere Registry, fürExterne Registrierungs-URL, geben Sie unter Verwendung des Formats den Namen und das Tag des Docker-Images in Docker Hub eindocker repository/docker image nameaus. Wenn Sie angebenAmazon ECR, benutzeAmazon ECR-RepositoryundAmazon-ECR-Bildum das Docker-Bild in IhremAWSKonto.

• Wenn Sie ein privates Docker-Image verwenden möchten, wählen SieBenutzerdefiniertes Imageaus. FürUmgebungstyp, wählenARM,Linux,Linux-GPU, oderWindowsaus. 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 überschreibtENTRYPOINTfür benutzerdefinierte Docker-Images.

Privileged

SelectPrivilegedNur wenn Sie vorhaben, dieses Build-Projekt zum Erstellen von Docker-Images zu verwenden und das von Ihnen ausgewählte Build-Umgebungs-Image von CodeBuild nicht mit Docker-Support bereitgestellt wird. 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-Support bereitgestellt wird.

Anmerkung

Standardmäßig erlauben Docker-Container keinen Zugriff auf Geräte. Der privilegierte Modus gewährt dem Docker-Container eines Build-Projekts Zugriff auf alle Geräte. Weitere Informationen finden Sie unter Laufzeitberechtigungen und Linux-Funktionen auf der Docker-Docs-Website.

- 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"

Servicerolle

Führen Sie eine der folgenden Aufgaben aus:

• Wenn Sie keine CodeBuild-Servicerolle haben, wählen SieNeue Dienstrolleaus. In :RollennameGeben Sie einen Namen für die neue Rolle ein.

• Wenn Sie eine CodeBuild-Dienstrolle haben, wählen SieVorhandene Servicerolleaus. In :ARN der RolleWählen Sie 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

Geben Sie einen Wert zwischen 5 und 8 Stunden an, nach dem CodeBuild den Build-Vorgang beendet, wenn dieser noch nicht abgeschlossen wurde. Wenn Sie die Felder hours und minutes leer lassen, wird der Standardwert von 60 Minuten verwendet.

VPC

Wenn Sie möchten, dass CodeBuild mit Ihrer VPC arbeitet:

• FürVPCWählen Sie die VPC-ID aus, die CodeBuild verwendet.

• FürVPC-SubnetzeWählen Sie die Subnetze aus, die von CodeBuild verwendete Ressourcen enthalten.

• FürVPC-Sicherheitsgruppenwählen Sie die Sicherheitsgruppen aus, die CodeBuild verwendet, um den Zugriff auf Ressourcen in den VPCs zu erlauben.

Weitere Informationen finden Sie unter Verwenden vonAWS CodeBuildmit Amazon Virtual Private Cloud.

Datenverarbeitung

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

Umgebungsvariablen

Geben Sie den Namen und Wert ein und wählen Sie dann den Typ jeder Umgebungsvariablen aus, die für die Builds verwendet werden soll.

Anmerkung

CodeBuild legt die Umgebungsvariable fürAWSRegion automatisch. 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.

Wir empfehlen Ihnen, eine Umgebungsvariable mit einem sensiblen Wert wie z. B.AWSZugriffsschlüssel-ID, einAWSoder ein Passwort als Parameter in Amazon EC2 Systems Manager Parameter Store oderAWS Secrets Manageraus.

Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, gehen Sie fürTyp, wählenParameteraus. FürNameGeben Sie einen Bezeichner für CodeBuild ein. FürValue, geben Sie den Namen des Parameters ein, der in 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 als Name die Zeichenfolge „LOGIN_PASSWORD“ ein. Geben Sie für Wert /CodeBuild/dockerLoginPassword ein.

Wichtig

Wenn Sie Amazon EC2 Systems Manager Parameter Store verwenden, empfehlen wir Ihnen, Parameter mit Parameternamen zu speichern, die mit beginnen/CodeBuild/(z. B./CodeBuild/dockerLoginPassword) enthalten. 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 fürKMS-Schlüsselkönnen Sie den ARN einesAWS KMSgeben Sie Ihr Konto ein. 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, startet die Konsole den Parameternamen mit/CodeBuild/wie es gespeichert wird. Weitere Informationen finden Sie unterSystems Manager Parameter StoreundExemplarische Vorgehensweise für Systems Manager Parameter Store KonsoleimAmazon EC2 Systems Manager Manager-Benutzerhandbuchaus.

Bezieht sich Ihr Build-Projekt auf Parameter, die in Amazon EC2 Systems Manager Parameter Store gespeichert sind, muss die Servicerolle des Build-Projekts diessm:GetParametersAktion Wenn Sie gewählt habenNeue Dienstrollezuvor nimmt CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt auf. Wenn Sie jedoch Existing service role (Vorhandene Servicerolle) ausgewählt haben, müssen Sie diese Aktion separat in Ihre Servicerolle aufnehmen.

Bezieht sich Ihr Build-Projekt auf Parameter, die in Amazon EC2 Systems Manager Parameter Store mit Parameternamen gespeichert sind, die nicht mit beginnen/CodeBuild/und Sie haben gewähltNeue Dienstrollemüssen Sie diese Dienstrolle aktualisieren, um Zugriff auf Parameternamen zu ermöglichen, die nicht mit beginnen/CodeBuild/aus. Dies liegt daran, dass diese Service-Rolle nur auf Parameternamen zugreift, die mit /CodeBuild/ beginnen.

Wenn Sie angebenNeue Dienstrolleenthält die Servicerolle die Berechtigung, alle Parameter unter dem/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, fürTyp, wählenSecrets Manageraus. FürNameGeben Sie einen Bezeichner für CodeBuild ein. 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

Wir empfehlen, Secrets Manager in Secrets mit Namen zu speichern, die mit beginnen/CodeBuild/(z. B./CodeBuild/dockerLoginPassword) enthalten. Weitere Informationen finden Sie unter Was ist AWS Secrets Manager? im AWS Secrets Manager-Benutzerhandbuch.

Bezieht sich Ihr Build-Projekt auf Secrets, die in Secrets Manager gespeichert sind, muss die Servicerolle des Build-Projekts diesecretsmanager:GetSecretValueAktion Wenn Sie gewählt habenNeue Dienstrollezuvor nimmt CodeBuild diese Aktion in die Standard-Servicerolle für Ihr Build-Projekt auf. 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 gespeichert sind, mit geheimen Namen, die nicht mit beginnen/CodeBuild/und Sie haben gewähltNeue Dienstrollemüssen Sie die Dienstrolle aktualisieren, um Zugriff auf geheime Namen zu ermöglichen, die nicht mit beginnen/CodeBuild/aus. Dies liegt daran, dass die Servicerolle nur auf geheime Namen zugreift, die mit beginnen/CodeBuild/aus.

Wenn Sie angebenNeue Dienstrolleenthält die Servicerolle die Berechtigung, alle Geheimnisse unter der/CodeBuild/Namespace im Secrets Manager.

Buildspec

In derBuildspec-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Technische Daten erstellen

Führen Sie eine der folgenden Aufgaben 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 mit dem Namenbuildspec.ymlim Quellcode-Stammverzeichnis. Wenn Ihre buildspec-Datei einen anderen Namen oder Speicherort verwendet, geben Sie den Pfad aus dem Quellstammverzeichnis inBuildspec name (Name der Build-Spezifikation)(z. B.buildspec-two.ymloderconfiguration/buildspec.ymlaus. Wenn sich die buildspec-Datei in einem S3-Bucket befindet, muss sie sich im selben befindenAWSRegion als Ihr Build-Projekt. Geben Sie die buildspec-Datei mit ihrem ARN an (z. B.arn:aws:s3:::my-codebuild-sample2/buildspec.yml) enthalten.

• 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). So führen Sie Befehle in anderen Phasen aus, oder wenn Sie eine lange Liste von Befehlen fürbuildphase, füge einbuildspec.ymlDatei in das Quellcode-Stammverzeichnis, fügen Sie die Befehle zur Datei hinzu und wählen Sie dannVerwenden Sie buildspec.yml im Quellcode-Stammverzeichnisaus.

Weitere Informationen hierzu finden Sie unter Build-Spezifikationsreferenz.

Batchkonfiguration

In derBatchkonfiguration-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern. Weitere Informationen finden Sie unter Batch baut einAWS CodeBuild.

Sie können die folgenden Eigenschaften ändern:

Batch-Servicerolle

Stellt die Dienstrolle für Batch-Builds bereit.

Wählen Sie eine der folgenden Optionen aus:

• Wenn Sie keine Batch-Service-Rolle erstellt haben, wählen SieNeue Dienstrolleaus. In :ServicerolleGeben Sie einen Namen für die neue Rolle ein.

• Wenn Sie eine Batch-Service-Rolle haben, wählen SieVorhandene Servicerolleaus. In :ServicerolleWählen Sie die Servicerolle aus.

Batch-Builds führen eine neue Sicherheitsrolle in der Batch-Konfiguration ein. Diese neue Rolle ist erforderlich, da CodeBuild in der Lage sein muss, dieStartBuild,StopBuild, undRetryBuildAktionen in Ihrem Namen, um Builds als Teil eines Stapels auszuführen. Kunden sollten aus zwei Gründen eine neue Rolle und nicht die gleiche Rolle verwenden, die sie in ihrem Build verwenden:

• Die Build-Rolle gebenStartBuild,StopBuild, undRetryBuildBerechtigungen würden es einem einzelnen Build ermöglichen, mehr Builds über die Buildspec zu starten.

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

Zulässige Compute-Typ (en) für Stapel

Wählen Sie die für den Stapel zulässigen Berechnungstypen aus. Wählen Sie alle zutreffenden aus.

Maximal zulässige Builds im Stapel

Geben Sie die maximale Anzahl der zulässigen Builds im Stapel ein. Wenn ein Stapel diese Grenze überschreitet, schlägt der Stapel fehl.

Batch-Timeout

Geben Sie die Höchstdauer des Batch-Builds ein.

Kombiniere Artefakte

SelectKombiniere alle Artefakte aus dem Stapel zu einem einzigen Ortum alle Artefakte aus dem Stapel zu einem einzigen Ort zusammenzufassen.

Batch-Berichtsmodus

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

Anmerkung

Dieses Feld ist nur verfügbar, wenn die Projektquelle Bitbucket, GitHub oder GitHub Enterprise ist undMelden Sie den Build-Status an den Quellanbieter, wenn Ihre Builds beginnen und beendenist unter ausgewähltSourceaus.

Aggregierte Builds

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

Individuelle Builds

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

Artifacts

In der-Artefakte-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Typ

Führen Sie eine der folgenden Aufgaben 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 an ein Amazon ECR-Repository übergeben möchten.

• Um die Build-Ausgabe in einem S3-Bucket zu speichern, wählen SieAmazon S3wie folgt:

  • 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

Führen Sie eine der folgenden Aufgaben aus:

• So verwenden Sie denVon AWS verwalteter SchlüsselWenn Amazon S3 in Ihrem Konto die Build-Ausgabeartefakte verschlüsselt, verlassen SieVerschlüsselungsschlüsselleer. Dies ist die Standardeinstellung.

• Um einen vom Kunden verwalteten Schlüssel zum Verschlüsseln der Build-Ausgabeartefakte zu verwenden, gehen Sie unter unterVerschlüsselungsschlüsselGeben Sie den ARN des vom Kunden verwalteten 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 S3-Cache verwenden möchten, wählen SieAmazon S3wie folgt:

  • Wählen Sie für Bucket den Namen des S3-Buckets, in dem der Cache gespeichert wird.

  • (Optional) FürCache-Pfad-Präfixein, geben Sie ein Amazon S3-Pfad-Prä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. DieARM_CONTAINERundLINUX_GPU_CONTAINERUmgebungstypen und dasBUILD_GENERAL1_2XLARGECompute-Typ unterstützt die Verwendung eines lokalen Caches nicht.

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

In derProtokolle-Bereich und wählen Sie ausBearbeitenaus. Wenn Ihre Änderungen abgeschlossen sind, wählen SieAktualisierung der Konfigurationum die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

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 wünschen:

CloudWatch-Protokolle

SelectCloudWatch-Protokolleaus.

Group name (Gruppenname)

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

Stream-Name

Geben Sie Ihren Namen des Amazon CloudWatch Logs Log-Streams ein.

S3

Wenn Sie möchten, dass Amazon S3 S3-Protokolle:

S3-Protokolle

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

Bucket

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

Pfad-Präfix

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

Deaktivieren Sie S3-Protokollverschlüsselung

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