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 AWS SDKs verwenden AWS CLI, 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ügt. Berechtigungen 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:
Öffnen Sie die AWS CodeBuild Konsole unter https://console.aws.amazon.com/codesuite/codebuild/home.
-
Wählen Sie im linken Navigationsbereich Build projects aus.
-
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.
- Abzeichen 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.
Das Build Badge gilt nicht, wenn Ihr Quellanbieter Amazon S3 ist.
- Aktivieren Sie das Limit für gleichzeitige Builds
-
Wenn Sie die Anzahl gleichzeitiger Builds für dieses Projekt einschränken möchten, gehen Sie wie folgt vor:
-
Wählen Sie „Anzahl gleichzeitiger Builds einschränken“, die mit diesem Projekt gestartet werden können.
-
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 für das Konto festgelegte Limit für gleichzeitige Builds. Wenn Sie versuchen, eine Zahl einzugeben, die das Kontenlimit überschreitet, 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 AWS Kontozugriff, wählen Sie Öffentlichen Build-Zugriff aktivieren aus und bestätigen Sie, dass Sie die Build-Ergebnisse veröffentlichen möchten. Die folgenden Eigenschaften werden für öffentliche Build-Projekte verwendet:
- Rolle des öffentlichen Build-Dienstes
-
Wählen Sie Neue Servicerolle, wenn Sie eine neue Servicerolle für Sie CodeBuild erstellen lassen möchten, oder Bestehende Servicerolle, wenn Sie eine vorhandene Servicerolle verwenden möchten.
Die öffentliche Build-Servicerolle CodeBuild ermöglicht das Lesen der CloudWatch Protokolle und das Herunterladen der Amazon S3-Artefakte für die Builds des Projekts. Dies ist erforderlich, um die Build-Protokolle und Artefakte des Projekts der Öffentlichkeit zugänglich zu machen.
- Rolle „Dienst“
-
Geben Sie den Namen der neuen Servicerolle oder einer vorhandenen Servicerolle ein.
Um die Build-Ergebnisse Ihres Projekts als privat zu kennzeichnen, deaktivieren Sie die Option Öffentlichen Build-Zugriff aktivieren.
Weitere Informationen finden Sie unter URLs für öffentliche Build-Projekte abrufen.
Folgendes sollte beachtet werden, wenn Sie die Build-Ergebnisse Ihres Projekts veröffentlichen:
-
Alle Build-Ergebnisse, Logs und Artefakte eines Projekts, einschließlich Builds, die ausgeführt wurden, als das Projekt privat war, sind der Öffentlichkeit 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 vertraulichen Werte, insbesondere AWS Zugriffsschlüssel-IDs und geheime Zugriffsschlüssel, in Umgebungsvariablen. Wir empfehlen, einen Amazon EC2 Systems Manager Parameter Store oder AWS Secrets Manager zum Speichern vertraulicher Werte zu verwenden.
-
Gehen Sie wie folgt vor, Bewährte Methoden für die Verwendung von Webhooks um zu begrenzen, 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 verbreiten. Wir empfehlen Projektadministratoren, alle Pull Requests zu überprüfen, um sicherzustellen, dass es sich bei dem Pull Request um eine legitime Änderung handelt. Wir empfehlen außerdem, alle Artefakte anhand ihrer Prüfsummen zu validieren, um sicherzustellen, dass die richtigen Artefakte heruntergeladen werden.
- Zusätzliche Informationen
-
Geben Sie für Tags den Namen und den Wert aller Tags ein, die unterstützende AWS Dienste verwenden sollen. Verwenden Sie Add row, um ein Tag hinzuzufügen. Sie können bis zu 50 Tags hinzufügen.
Quelle
Wählen Sie im Abschnitt 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 Quellcode-Anbietertyp. Verwenden Sie die folgenden Listen, um die für Ihren Quellanbieter geeignete Auswahl zu treffen:
CodeBuild unterstützt Bitbucket Server nicht.
- Amazon S3
-
- Bucket
-
Wähle 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 unterBeispiel für eine Quellversion mit AWS CodeBuild.
- CodeCommit
-
- Repository
-
Wählen Sie das Repository aus, das Sie verwenden möchten.
- Typ der Referenz
-
Wähle Branch, Git-Tag oder Commit ID, um die Version deines Quellcodes anzugeben. Weitere Informationen finden Sie unter Beispiel für eine Quellversion mit AWS CodeBuild.
Wir empfehlen, Git-Branch-Namen zu wählen, die nicht wie Commit-IDs aussehen, wie z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. Das hilft dir, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden.
- Tiefe des Git-Clones
-
Wähle, ob du einen Shallow Clone erstellen möchtest, 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
-
- Anmeldeinformationen
-
Wählen Sie Standard-Quell-Anmeldeinformationen oder Benutzerdefinierte Quell-Anmeldeinformationen und folgen Sie den Anweisungen, um die Standard-Quell-Anmeldeinformationen zu verwalten oder die Quell-Anmeldeinformationen anzupassen.
- Art der Verbindung
-
Wählen Sie OAuth CodeConnections , App-Passwort oder Persönliches Zugriffstoken, mit dem Sie eine Verbindung herstellen möchten. CodeBuild
- Connection (Verbindung)
-
Wähle eine Bitbucket-Verbindung oder einen Secrets Manager-Schlüssel aus, um dich über deinen angegebenen Verbindungstyp zu verbinden.
- Repository
-
Wähle „Repository“ in meinem Bitbucket-Konto oder „Öffentliches Repository“ und gib die Repository-URL ein.
- Quellversion
-
Geben Sie 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.
Wir empfehlen, Git-Branch-Namen zu wählen, die nicht wie Commit-IDs aussehen, wie z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. Das hilft dir, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden.
- Tiefe des Git-Clones
-
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ähle Build-Status an den Quellanbieter melden, wenn deine Builds beginnen und enden, wenn du möchtest, dass der Status von Start und Abschluss deines Builds deinem Quellanbieter gemeldet wird.
Um den Build-Status an den Quellanbieter melden zu können, muss der Benutzer, der dem Quellanbieter zugeordnet ist, Schreibzugriff auf das Repo haben. Wenn der Benutzer keinen Schreibzugriff hat, kann der Build-Status nicht aktualisiert werden. Weitere Informationen finden Sie unter Zugriff auf den Quellanbieter.
Gib für den Statuskontext den Wert ein, der für den name Parameter im Bitbucket-Commit-Status verwendet werden soll. Weitere Informationen finden Sie unter Build in der Bitbucket-API-Dokumentation.
Gib als 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 durch einen Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Damit der Status eines Builds, der über die Konsole oder einen API-Aufruf gestartet wird, an den Quellanbieter gemeldet wird, müssen Sie diese Einstellung auswählen.
Wenn die Builds Ihres Projekts durch einen Webhook ausgelöst werden, müssen Sie einen neuen Commit in das Repo übertragen, damit eine Änderung dieser Einstellung wirksam wird.
Wählen Sie unter Primäre Quell-Webhook-Ereignisse die Option Jedes Mal 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
-
- Anmeldeinformationen
-
Wählen Sie Standard-Quell-Anmeldeinformationen oder Benutzerdefinierte Quell-Anmeldeinformationen und folgen Sie den Anweisungen, um die Standard-Quell-Anmeldeinformationen zu verwalten oder die Quell-Anmeldeinformationen 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-Geheimnis aus, um eine Verbindung über den von Ihnen angegebenen Verbindungstyp herzustellen.
- Repository
-
Wählen Sie „Repository“ in meinem GitHub Konto, „Öffentliches Repository“ oder „GitHub Bereichsbezogener Webhook“ und geben Sie die Repository-URL ein.
- Quellversion
-
Geben Sie 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.
Wir empfehlen, Git-Branch-Namen zu wählen, die nicht wie Commit-IDs aussehen, wie z. B. 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. Das hilft dir, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden.
- Tiefe des Git-Clones
-
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 aus, wenn Sie möchten, dass der Status des Beginns und der Fertigstellung Ihres Builds Ihrem Quellanbieter gemeldet wird.
Um den Build-Status an den Quellanbieter melden zu können, muss der Benutzer, der dem Quellanbieter zugeordnet ist, Schreibzugriff auf das Repo haben. Wenn der Benutzer keinen Schreibzugriff hat, kann der Build-Status nicht aktualisiert werden. Weitere Informationen finden Sie unter Zugriff auf den Quellanbieter.
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 Ziel-URL den Wert ein, der für den target_url Parameter im GitHub Commit-Status verwendet werden soll. Weitere Informationen finden Sie im GitHub Entwicklerhandbuch unter Einen Commit-Status erstellen.
Der Status eines durch einen Webhook ausgelösten Builds wird immer an den Quellanbieter gemeldet. Damit der Status eines Builds, der über die Konsole oder einen API-Aufruf gestartet wird, an den Quellanbieter gemeldet wird, müssen Sie diese Einstellung auswählen.
Wenn die Builds Ihres Projekts durch einen Webhook ausgelöst werden, müssen Sie einen neuen Commit in das Repo übertragen, damit eine Änderung dieser Einstellung wirksam wird.
Wählen Sie unter Primäre Quell-Webhook-Ereignisse die Option Jedes Mal 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
-
- Anmeldeinformationen
-
Wählen Sie Standard-Quell-Anmeldeinformationen oder Benutzerdefinierte Quell-Anmeldeinformationen und folgen Sie den Anweisungen, um die Standard-Quell-Anmeldeinformationen zu verwalten oder die Quell-Anmeldeinformationen anzupassen.
- Art der Verbindung
-
Wählen Sie CodeConnections oder Persönliches Zugriffstoken, mit dem Sie eine Verbindung herstellen möchten CodeBuild.
- Connection (Verbindung)
-
Wählen Sie eine GitHub Enterprise-Verbindung oder einen Secrets Manager-Schlüssel aus, um eine Verbindung über den von Ihnen angegebenen Verbindungstyp herzustellen.
- Repository
-
Wählen Sie „Repository“ in meinem GitHub Enterprise-Konto oder „GitHub Enterprise Scope“ -Webhook aus und geben Sie die Repository-URL ein.
- Quellversion
-
Geben Sie einen Pull-Request, 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.
Wir empfehlen, Git-Branch-Namen zu wählen, die nicht wie Commit-IDs aussehen, wie zum Beispiel 811dd1ba1aba14473856cee38308caed7190c0d oder5392f7. Das hilft dir, Git-Checkout-Kollisionen mit tatsächlichen Commits zu vermeiden.
- Tiefe des Git-Clones
-
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
-