Ändern Sie die Build-Projekteinstellungen in AWS CodeBuild - AWS CodeBuild
Ändern der Einstellungen eines Build-Projekts (Konsole)Ändern der Einstellungen eines Build-Projekts (AWS CLI)Ändern Sie die Einstellungen eines Build-Projekts (AWS SDKs)

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.

Ändern Sie die Build-Projekteinstellungen in AWS CodeBuild

Sie können die AWS CodeBuild Konsole oder verwenden AWS CLI, AWS SDKs um die Einstellungen eines Build-Projekts zu ändern.

Wenn Sie einem Build-Projekt Testberichte hinzufügen, stellen Sie sicher, dass Ihre IAM Rolle über die unter beschriebenen Berechtigungen verfügtBerechtigungen für Testberichte.

Ändern der Einstellungen eines Build-Projekts (Konsole)

Gehen Sie wie folgt vor, um die Einstellungen für ein Build-Projekt zu ändern:

  1. Öffnen Sie die AWS CodeBuild Konsole unter https://console.aws.amazon.com/codesuite/codebuild/home.

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

  3. Führen Sie eine der folgenden Aktionen 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:

Konfiguration des Projekts

Wählen Sie im Abschnitt Projektkonfiguration die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern.

Beschreibung

Geben Sie optional eine Beschreibung des Build-Projekts ein, damit andere Benutzer verstehen, wofür dieses Projekt verwendet wird.

Badge erstellen

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

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

Aktivieren Sie das Limit für gleichzeitige Builds

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.

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

Aktivieren Sie den öffentlichen Build-Zugriff

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

Rolle im Public-Build-Dienst

Wählen Sie Neue Servicerolle aus, wenn Sie eine neue Servicerolle für Sie CodeBuild erstellen möchten, oder Bestehende Servicerolle, wenn Sie eine bestehende Servicerolle verwenden möchten.

Die öffentliche Build-Servicerolle ermöglicht es 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-Logs und Artefakte des Projekts der Öffentlichkeit zugänglich zu machen.

Rolle im Dienst

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

Um die Build-Ergebnisse Ihres Projekts privat zu machen, deaktivieren Sie die Option Öffentlichen Build-Zugriff aktivieren.

Weitere Informationen finden Sie unter Holen Sie sich ein öffentliches Build-Projekt URLs.

Warnung

Wenn Sie die Build-Ergebnisse Ihres Projekts veröffentlichen, sollten Sie Folgendes beachten:

  • Alle Build-Ergebnisse, Logs und Artefakte eines Projekts, einschließlich Builds, die ausgeführt wurden, als das Projekt privat war, sind öffentlich zugänglich.

  • Alle Build-Logs und Artefakte sind öffentlich zugänglich. Umgebungsvariablen, Quellcode und andere vertrauliche Informationen wurden möglicherweise in die Build-Logs und -Artefakte ausgegeben. Sie müssen vorsichtig sein, welche Informationen in die Build-Logs ausgegeben werden. Einige bewährte Methoden sind:

    • Speichern Sie keine sensiblen Werte, insbesondere AWS Zugriffsschlüssel IDs und geheime Zugriffsschlüssel, in Umgebungsvariablen. Wir empfehlen, einen Amazon EC2 Systems Manager Manager-Parameterspeicher AWS Secrets Manager zu verwenden oder sensible Werte zu speichern.

    • Folgen Sie diesen Regeln, Bewährte Methoden für die Verwendung von Webhooks um einzuschränken, welche Entitäten einen Build auslösen können, und speichern Sie die Buildspec nicht im Projekt selbst, 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-Requests zu überprüfen, um sicherzustellen, dass es sich bei der Pull-Anfrage um eine legitime Änderung handelt. Wir empfehlen außerdem, dass Sie alle Artefakte anhand ihrer Prüfsummen überprüfen, um sicherzustellen, dass die richtigen Artefakte heruntergeladen werden.

Zusätzliche Informationen

Geben Sie unter 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

Wählen Sie im Bereich Quelle die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Quellanbieter

Wählen Sie den Typ des Quellcode-Anbieters. Verwenden Sie die folgenden Listen, um die für Ihren Quellanbieter geeignete Auswahl zu treffen:

Anmerkung

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.

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.

Anmerkung

Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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 das Repository ein. URL

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, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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.

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

Geben Sie für Target den Wert einURL, der für den url Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen findest du in der API Bitbucket-Dokumentation unter Build.

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 Anrufs an den Quellanbieter gemeldet werden, 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

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 das Repository ein. URL

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, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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.

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.

Geben Sie für Target den Wert einURL, 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.

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 Anrufs an den Quellanbieter gemeldet werden, 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 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 CodeConnectionsoder 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 das Repository ein. URL

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.

Anmerkung

Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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.

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.

Geben Sie für Target den Wert einURL, 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.

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 Anrufs an den Quellanbieter gemeldet werden, 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.

Unsicher SSL

Wählen Sie Unsicher aktivieren, um SSL Warnungen SSL zu ignorieren, während Sie eine Verbindung zu Ihrem GitHub Enterprise-Projekt-Repository herstellen.

Wählen Sie unter Webhook-Ereignisse für Primärquellen 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

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

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

Anmerkung

Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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.

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

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

Anmerkung

Wir empfehlen, Git-Branchnamen zu wählen, die nicht wie Commit aussehenIDs, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. 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.

Umgebung

Wählen Sie im Bereich Umgebung die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

Bereitstellungsmodell

Um das Bereitstellungsmodell zu ändern, wählen Sie Bereitstellungsmodell ändern aus und führen Sie einen der folgenden Schritte 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.

Bild der Umgebung

Um das Build-Image zu ändern, wählen Sie Override image und führen Sie einen der folgenden Schritte 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 Linux ARMGPU, Linux oder Windows aus. Wenn Sie Andere Registrierung wählenURL, geben Sie für Externe Registrierung 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 entscheidenECR, verwenden Sie das ECRAmazon-Repository und ECRdas Amazon-Image, um das Docker-Image in Ihrem AWS Konto auszuwählen.

  • Um ein privates Docker-Image zu verwenden, wählen Sie Benutzerdefiniertes Image. Wählen Sie als Umgebungstyp Linux ARMGPU, Linux oder Windows aus. Wählen Sie für Image-Registrierung die ARN Option Andere Registrierung aus und geben Sie dann die 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.

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

Wählen Sie Dieses Flag aktivieren, wenn Sie Docker-Images erstellen oder Ihren Builds erweiterte Rechte gewähren möchten. nur, 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 sich für ein Image der Build-Umgebung entschieden haben, das von CodeBuild mit Docker-Unterstützung bereitgestellt wird.

Anmerkung

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

  • Wählen Sie für VPCdie VPC ID, die CodeBuild verwendet wird.

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

  • Wählen Sie für VPCSicherheitsgruppen die Sicherheitsgruppen aus, die CodeBuild den Zugriff auf Ressourcen in der ermöglichen. VPCs

Weitere Informationen finden Sie unter Verwendung AWS CodeBuild mit Amazon Virtual Private Cloud.

Datenverarbeitung

Wählen Sie eine der verfügbaren Optionen.

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.

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

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.

Wichtig

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 als KMSSchlüssel die Nummer 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 und Systems Manager Parameter Store Console Walkthrough 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.

Wichtig

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

Wählen Sie im Abschnitt Buildspec die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

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. Sucht standardmäßig nach einer Datei mit dem Namen buildspec.yml im Quellcode-Stammverzeichnis. CodeBuild Wenn Ihre Buildspec-Datei einen anderen Namen oder Speicherort verwendet, geben Sie ihren Pfad vom Quellstammverzeichnis aus im 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 ihrer 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 wenn Sie eine lange Befehlsliste 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 Buildspec.yml im Quellcode-Stammverzeichnis verwenden aus.

Weitere Informationen hierzu finden Sie unter Build-Spezifikationsreferenz.

Batch-Konfiguration

Wählen Sie im Abschnitt Batch-Konfiguration die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern. Weitere Informationen finden Sie unter Builds stapelweise ausführen.

Sie können die folgenden Eigenschaften ändern:

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 mussStartBuild, die RetryBuild AktionenStopBuild, 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.

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.

Anmerkung

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

Wählen Sie im Abschnitt Artefakte die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um die neue Konfiguration zu speichern.

Sie können die folgenden Eigenschaften ändern:

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 ECR Amazon-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:

    • Wenn Sie Ihren Projektnamen für die ZIP Build-Ausgabedatei oder den Ordner verwenden möchten, lassen Sie Name leer. Geben Sie andernfalls den Namen ein. (Wenn Sie eine ZIP Datei ausgeben möchten und die ZIP Datei eine Dateierweiterung haben soll, stellen Sie sicher, dass Sie diese nach dem ZIP Dateinamen angeben.)

    • 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 zuvor in diesem Verfahren Build-Befehle einfügen ausgewählt haben, geben Sie unter Ausgabedateien die Speicherorte der Dateien aus dem Build ein, die Sie in die ZIP Build-Ausgabedatei oder den Build-Ausgabeordner einfügen möchten. 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 Aktionen aus:

  • Um Von AWS verwalteter Schlüssel 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 zur Verschlüsselung der Build-Ausgabeartefakte zu verwenden, geben Sie im Feld Verschlüsselungsschlüssel 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-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. Weitere Informationen zum Caching finden Sie unter Cache-Builds zur Verbesserung der Leistung.

Logs (Protokolle)

Wählen Sie im Abschnitt Logs die Option Bearbeiten aus. Wenn Ihre Änderungen abgeschlossen sind, wählen Sie Konfiguration aktualisieren, um 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-Protokolle wünschen:

CloudWatch Logs

Wählen Sie CloudWatch Protokolle aus.

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.

Ändern der Einstellungen eines Build-Projekts (AWS CLI)

Informationen zur Verwendung von AWS CLI with AWS CodeBuild finden Sie unterBefehlszeilenreferenz.

Um ein CodeBuild Projekt mit dem zu aktualisieren AWS CLI, erstellen Sie eine JSON Datei mit den aktualisierten Eigenschaften und übergeben diese Datei an den update-projectBefehl. Alle Eigenschaften, die nicht in der Aktualisierungsdatei enthalten sind, bleiben unverändert.

In der JSON Aktualisierungsdatei sind nur die name Eigenschaft und die geänderten Eigenschaften erforderlich. Die name Eigenschaft identifiziert das zu ändernde Projekt. Bei allen geänderten Strukturen müssen auch die erforderlichen Parameter für diese Strukturen enthalten sein. Um beispielsweise die Umgebung für das Projekt zu ändern, sind die environment/computeType Eigenschaften environment/type und erforderlich. Hier ist ein Beispiel, das das Umgebungsbild aktualisiert:

{
  "name": "<project-name>",
  "environment": {
    "type": "LINUX_CONTAINER",
    "computeType": "BUILD_GENERAL1_SMALL",
    "image": "aws/codebuild/amazonlinux2-x86_64-standard:4.0"
  }
}

Wenn Sie die aktuellen Eigenschaftswerte für ein Projekt abrufen müssen, verwenden Sie den batch-get-projectsBefehl, um die aktuellen Eigenschaften des Projekts abzurufen, das Sie ändern, und schreiben Sie die Ausgabe in eine Datei.

aws codebuild batch-get-projects --names "<project-name>" > project-info.json

Das Tool project-info.json Die Datei enthält eine Reihe von Projekten und kann daher nicht direkt zur Aktualisierung eines Projekts verwendet werden. Sie können jedoch die Eigenschaften, die Sie ändern möchten, aus der Datei kopieren project-info.json Datei und fügen Sie sie als Grundlage für die Eigenschaften, die Sie ändern möchten, in Ihre Aktualisierungsdatei ein. Weitere Informationen finden Sie unter Anzeigen der Details eines Build-Projekts (AWS CLI).

Ändern Sie die JSON Aktualisierungsdatei wie unter beschriebenErstellen eines Build-Projekts (AWS CLI), und speichern Sie Ihre Ergebnisse. Wenn Sie mit dem Ändern der JSON Aktualisierungsdatei fertig sind, führen Sie den update-projectBefehl aus und übergeben Sie die JSON Aktualisierungsdatei.

aws codebuild update-project --cli-input-json file://<update-project-file>

Bei Erfolg wird das aktualisierte Projekt in der Ausgabe JSON angezeigt. Wenn erforderliche Parameter fehlen, wird in der Ausgabe eine Fehlermeldung angezeigt, die die fehlenden Parameter identifiziert. Dies ist beispielsweise die Fehlermeldung, die angezeigt wird, wenn der environment/type Parameter fehlt:

aws codebuild update-project --cli-input-json file://update-project.json

Parameter validation failed:
Missing required parameter in environment: "type"

Ändern Sie die Einstellungen eines Build-Projekts (AWS SDKs)

Informationen zur Verwendung AWS CodeBuild mit dem AWS SDKs finden Sie unterAWS SDKs- und Tools-Referenz.