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.
# Verwenden Sie Webhooks mit AWS CodeBuild
AWS CodeBuild unterstützt die Webhook-Integration mit GitHub GitHub Enterprise Server GitLab, GitLab Self Managed und Bitbucket.
**Topics**
+ [Bewährte Methoden für die Verwendung von Webhooks mit AWS CodeBuild](#webhook-best-practices)
+ [Bitbucket-Webhook-Ereignisse](bitbucket-webhook.md)
+ [GitHub globale Webhooks und organisatorische Webhooks](github-global-organization-webhook.md)
+ [GitHub manuelle Webhooks](github-manual-webhook.md)
+ [GitHub Webhook-Ereignisse](github-webhook.md)
+ [GitLab Gruppen-Webhooks](gitlab-group-webhook.md)
+ [GitLab manuelle Webhooks](gitlab-manual-webhook.md)
+ [GitLab Webhook-Ereignisse](gitlab-webhook.md)
+ [Manuelle Webhooks von Buildkite](buildkite-manual-webhook.md)
+ [Genehmigung eines Pull-Request-Kommentars](pull-request-build-policy.md)
## Bewährte Methoden für die Verwendung von Webhooks mit AWS CodeBuild
Für Projekte, die öffentliche Repositorien zur Einrichtung von Webhooks verwenden, empfehlen wir die folgenden Optionen:
Filter einrichten `ACTOR_ACCOUNT_ID`
Fügen Sie `ACTOR_ACCOUNT_ID` Filter zu den Webhook-Filtergruppen Ihres Projekts hinzu, um festzulegen, welche Benutzer einen Build auslösen können. Jedes Webhook-Ereignis, an das gesendet CodeBuild wird, enthält Absenderinformationen, die die Kennung des Akteurs angeben. CodeBuild filtert die Webhooks auf der Grundlage des in den Filtern angegebenen Musters für reguläre Ausdrücke. Sie können die spezifischen Benutzer angeben, die Builds mit diesem Filter auslösen dürfen. Weitere Informationen erhalten Sie unter [GitHub Webhook-Ereignisse](github-webhook.md) und [Bitbucket-Webhook-Ereignisse](bitbucket-webhook.md).
`FILE_PATH`Filter einrichten
Fügen Sie `FILE_PATH` Filter zu den Webhook-Filtergruppen Ihres Projekts hinzu, um die Dateien ein- oder auszuschließen, die bei Änderung einen Build auslösen können. Sie können beispielsweise Build-Anfragen für Änderungen an der `buildspec.yml` Datei ablehnen, indem Sie ein reguläres Ausdrucksmuster wie`^buildspec.yml$`, zusammen mit der `excludeMatchedPattern` Eigenschaft verwenden. Weitere Informationen erhalten Sie unter [GitHub Webhook-Ereignisse](github-webhook.md) und [Bitbucket-Webhook-Ereignisse](bitbucket-webhook.md).
Schränken Sie die Berechtigungen für Ihre Build-IAM-Rolle ein
Durch einen Webhook ausgelöste Builds verwenden die im Projekt angegebene IAM-Servicerolle. Wir empfehlen, die Berechtigungen in der Servicerolle auf die Mindestanzahl an Berechtigungen festzulegen, die zur Ausführung des Builds erforderlich sind. Erstellen Sie beispielsweise in einem Test- und Bereitstellungsszenario ein Projekt zum Testen und ein anderes Projekt für die Bereitstellung. Das Testprojekt akzeptiert Webhook-Builds aus dem Repository, gewährt jedoch keine Schreibberechtigungen für Ihre Ressourcen. Das Bereitstellungsprojekt gewährt Schreibberechtigungen für Ihre Ressourcen, und der Webhook-Filter ist so konfiguriert, dass nur vertrauenswürdige Benutzer Builds auslösen können.
Verwenden Sie eine Inline- oder eine in Amazon S3 gespeicherte Buildspec
Wenn Sie Ihre Buildspec-Datei direkt im Projekt selbst definieren oder die Buildspec-Datei in einem Amazon S3 S3-Bucket speichern, ist die Buildspec-Datei nur für den Projekteigentümer sichtbar. Dadurch wird verhindert, dass Pull-Anfragen Codeänderungen an der Buildspec-Datei vornehmen und unerwünschte Builds auslösen. *Weitere Informationen finden Sie unter [ProjectSource.buildspec](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-buildspec) in der API-Referenz. CodeBuild*
# Bitbucket-Webhook-Ereignisse
Sie können Webhook-Filtergruppen verwenden, um anzugeben, welche Bitbucket-Webhook-Ereignisse einen Build auslösen. Du kannst beispielsweise angeben, dass ein Build nur bei Änderungen an bestimmten Branches ausgelöst wird.
Sie können eine oder mehrere Webhook-Filtergruppen erstellen, um anzugeben, welche Webhook-Ereignisse einen Build auslösen. Ein Build wird ausgelöst, wenn eine Filtergruppe den Wert true ergibt. Dies ist der Fall, wenn alle Filter in der Gruppe den Wert true ergeben. Wenn Sie eine Filtergruppe erstellen, geben Sie Folgendes an:
**Ein Ereignis**
Für Bitbucket kannst du eines oder mehrere der folgenden Ereignisse wählen:
+ `PUSH`
+ `PULL_REQUEST_CREATED`
+ `PULL_REQUEST_UPDATED`
+ `PULL_REQUEST_MERGED`
+ `PULL_REQUEST_CLOSED`
Der Webhook-Ereignistyp befindet sich im Header des Feldes `X-Event-Key`. Aus der folgende Tabelle geht die Zuordnung der `X-Event-Key`-Header-Werte zu Ereignistypen hervor.
Sie müssen das `merged`-Ereignis in Ihren Bitbucket-Webhook-Einstellungen aktivieren, wenn Sie eine Webhook-Filtergruppe erstellen, die den `PULL_REQUEST_MERGED`-Ereignistyp verwendet. Du musst das `declined` Ereignis auch in deiner Bitbucket-Webhook-Einstellung aktivieren, wenn du eine Webhook-Filtergruppe erstellst, die den Ereignistyp verwendet. `PULL_REQUEST_CLOSED`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/bitbucket-webhook.html)
Denn `PULL_REQUEST_MERGED` wenn ein Pull-Request mit der Squash-Strategie zusammengeführt wird und der Pull-Request-Branch geschlossen wird, ist der ursprüngliche Pull-Request-Commit nicht mehr vorhanden. In diesem Fall enthält die `CODEBUILD_WEBHOOK_MERGE_COMMIT` Umgebungsvariable den Bezeichner des gequetschten Merge-Commits.
**Ein oder mehrere optionale Filter**
Verwenden Sie einen regulären Ausdruck, um einen Filter anzugeben. Damit ein Ereignis einen Build auslöst, muss jeder Filter innerhalb der Gruppe, die diesem Ereignis zugeordnet ist, als wahr ausgewertet werden.
`ACTOR_ACCOUNT_ID`(`ACTOR_ID`in der Konsole)
Ein Webhook-Ereignis löst einen Build aus, wenn eine Bitbucket-Konto-ID dem Muster für reguläre Ausdrücke entspricht. Dieser Wert wird in der Eigenschaft `account_id` des Objekts `actor` in der Webhook-Filternutzlast angezeigt.
`HEAD_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Head-Referenz mit dem Muster für reguläre Ausdrücke übereinstimmt (zum Beispiel und`refs/heads/branch-name`). `refs/tags/tag-name` Ein `HEAD_REF`-Filter wertet den Git-Referenznamen für den Branch oder Tag aus. Die Branch- oder Tag-Name wird im Feld `name` des Objekts `new` im Objekt `push` der Webhook-Nutzlast angezeigt. Bei Pull-Anforderungsereignissen wird der Branch-Name im Feld `name` im Objekt `branch` des Objekts `source` in der Webhook-Nutzlast angezeigt.
`BASE_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Basisreferenz mit dem Muster des regulären Ausdrucks übereinstimmt. Ein `BASE_REF`-Filter kann nur für Pull-Anfrageereignisse verwendet werden (z. B. `refs/heads/branch-name`). Ein `BASE_REF`-Filter wertet den Git-Referenznamen für die Verzweigung aus. Der Branch-Name wird im Feld `name` des Objekts `branch` im Objekt `destination` in der Webhook-Nutzlast angezeigt.
`FILE_PATH`
Ein Webhook löst einen Build aus, wenn der Pfad einer geänderten Datei dem Muster für reguläre Ausdrücke entspricht.
`COMMIT_MESSAGE`
Ein Webhook löst einen Build aus, wenn die Head-Commit-Nachricht dem Muster für reguläre Ausdrücke entspricht.
`WORKFLOW_NAME`
Ein Webhook löst einen Build aus, wenn der Workflow-Name mit dem Muster des regulären Ausdrucks übereinstimmt.
**Anmerkung**
Sie finden die Webhook-Nutzlast in den Webhook-Einstellungen in Ihrem Bitbucket-Repository.
**Topics**
+ [Filtern von BitBucket-Webhook-Ereignissen (Konsole)](bitbucket-webhook-events-console.md)
+ [Filtern von BitBucket-Webhook-Ereignissen (SDK)](bitbucket-webhook-events-sdk.md)
+ [Filtern von Bitbucket-Webhook-Ereignissen (CloudFormation)](bitbucket-webhook-events-cfn.md)
# Filtern von BitBucket-Webhook-Ereignissen (Konsole)
Um Webhook-Ereignisse AWS-Managementkonsole zu filtern, gehen Sie wie folgt vor:
1. Wählen Sie beim Erstellen Ihres Projekts **Rebuild every time a code change is pushed to this repository (Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wird)** aus.
1. Wählen Sie unter **Event type (Ereignistyp)** eines oder mehrere Ereignisse aus.
1. Wenn Sie Fälle filtern möchten, in denen ein Ereignis einen Build auslöst, fügen Sie unter **Start a build under these conditions (Unter diesen Bedingungen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wenn Sie Fälle filtern möchten, in denen kein Ereignis ausgelöst wird, fügen Sie unter **Don't start a build under these conditions (Unter diesen Bedingungen keinen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wählen Sie **Add filter group (Filtergruppe hinzufügen)** aus, um eine weitere Filtergruppe hinzuzufügen.
Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *AWS CodeBuild -API-Referenz*.
In diesem Beispiel löst eine Webhook-Filtergruppe nur für Pull-Anfragen einen Build aus:
![\[Eine Webhook-Filtergruppe, die einen Build nur für Pull-Requests auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-bitbucket.png)
Bei Verwendung eines Beispiels mit zwei Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/branch1!` entsprechen, erstellt oder aktualisiert werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/branch1$` entsprechen.
![\[Ein Beispiel für zwei Filtergruppen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-bitbucket.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für alle Anfragen mit Ausnahme von Tag-Ereignissen aus.
![\[Eine Webhook-Filtergruppe, die einen Build für alle Anfragen außer Tag-Ereignissen auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-bitbucket.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur einen Build aus, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck `^buildspec.*` entsprechen.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn Dateien mit Namen angegeben sind, die dem regulären Ausdruck entsprechen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur dann einen Build aus, wenn Dateien in Ordnern `src` oder `test` geändert werden.
![\[Eine Webhook-Filtergruppe, die einen Build nur auslöst, wenn Dateien in bestimmten Ordnern geändert werden.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur einen Build aus, wenn eine Änderung von einem Bitbucket-Benutzer vorgenommen wird, der nicht über eine Konto-ID verfügt, die dem regulären Ausdruck `actor-account-id` entspricht.
**Anmerkung**
Informationen dazu, wie du deine Bitbucket-Konto-ID findest, findest du unter https://api.bitbucket.org/2.0/users/*user-name*, wo dein Bitbucket-Benutzername *user-name* ist.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn eine Änderung von einem Bitbucket-Benutzer vorgenommen wird, der keine Account-ID hat.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-bitbucket.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für ein Push-Ereignis aus, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
![\[Eine Webhook-Filtergruppe, die einen Build für ein Push-Ereignis auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck übereinstimmt.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
# Filtern von BitBucket-Webhook-Ereignissen (SDK)
Um das AWS CodeBuild SDK zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie das `filterGroups` Feld in der Anforderungssyntax der `CreateWebhook` oder `UpdateWebhook` API-Methoden. Weitere Informationen finden Sie unter [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *CodeBuild -API-Referenz*.
Um einen Webhook-Filter zu erstellen, der nur für Pull-Anfragen einen Build auslöst, fügen Sie Folgendes in die Anfragesyntax ein:
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
Um einen Webhook-Filter zu erstellen, der nur für die angegebenen Verzweigungen einen Build auslöst, verwenden Sie den Parameter `pattern`, um einen regulären Ausdruck zum Filtern von Verzweigungsnamen anzugeben. Bei Verwendung eines Beispiels mit zwei Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/myBranch$` entsprechen, erstellt oder aktualisiert werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/myBranch$` entsprechen.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
Sie können den Parameter `excludeMatchedPattern` verwenden, um anzugeben, welche Ereignisse keinen Build auslösen. In diesem Beispiel wird für alle Anfragen mit Ausnahme von Tag-Ereignissen ein Build ausgelöst.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
Sie können einen Filter erstellen, der nur einen Build auslöst, wenn ein Bitbucket-Benutzer mit der Konto-ID `actor-account-id` eine Änderung vornimmt.
**Anmerkung**
Informationen dazu, wie du deine Bitbucket-Konto-ID findest, findest du unter https://api.bitbucket.org/2.0/users/*user-name*, wo dein Bitbucket-Benutzername *user-name* ist.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
Sie können einen Filter erstellen, der nur einen Build auslöst, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck in dem Argument `pattern` entsprechen. In diesem Beispiel gibt die Filtergruppe an, dass nur ein Build ausgelöst wird, wenn Dateien geändert werden, deren Name dem regulären Ausdruck `^buildspec.*` entspricht.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur ausgelöst wird, wenn Dateien in Ordnern `src` oder `test` Ordnern geändert werden.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
Sie können einen Filter erstellen, der einen Build nur dann auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck im Musterargument übereinstimmt. In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur dann ausgelöst wird, wenn die Head-Commit-Nachricht des Push-Ereignisses mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# Filtern von Bitbucket-Webhook-Ereignissen (CloudFormation)
Um eine CloudFormation Vorlage zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie die `FilterGroups` Eigenschaft des AWS CodeBuild Projekts. Mit dem folgenden in YAML formatierten Teil einer CloudFormation -Vorlage werden zwei Filtergruppen erstellt. Diese lösen zusammen einen Build aus, wenn mindestens eine Gruppe als wahr ausgewertet wird.
+ Die erste Filtergruppe gibt an, dass Pull-Anfragen in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, von einem Bitbucket-Benutzer, der über keine Konto-ID `12345` verfügt, erstellt oder aktualisiert werden.
+ Die zweite Filtergruppe gibt an, dass Push-Anfragen in Verzweigungen mit Git-Referenznamen erstellt werden, die dem regulären Ausdruck `^refs/heads/.*` entsprechen.
+ Die dritte Filtergruppe gibt eine Push-Anforderung mit einer Head Commit-Nachricht an, die dem regulären Ausdruck `\[CodeBuild\]` entspricht.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
```
# GitHub globale Webhooks und organisatorische Webhooks
Sie können CodeBuild GitHub globale oder organisatorische Webhooks verwenden, um Builds auf Webhook-Ereignissen aus einem beliebigen Repository innerhalb einer GitHub Organisation oder eines Unternehmens zu starten. Globale Webhooks und Organisations-Webhooks funktionieren mit allen vorhandenen GitHub Webhook-Ereignistypen und können konfiguriert werden, indem beim Erstellen eines Webhooks eine Bereichskonfiguration hinzugefügt wird. CodeBuild Sie können auch globale Webhooks und Organisations-Webhooks verwenden, um [selbst gehostete GitHub Action-Runner einzurichten, um `WORKFLOW_JOB_QUEUED` Ereignisse aus mehreren Repositorys innerhalb eines CodeBuild](action-runner.md) einzigen Projekts zu empfangen.
**Topics**
+ [Richten Sie einen globalen oder organisatorischen Webhook ein GitHub](github-global-organization-webhook-setup.md)
+ [Filtert GitHub globale oder organisatorische Webhook-Ereignisse (Konsole)](github-global-organization-webhook-events-console.md)
+ [Webhook-Ereignisse der GitHub Organisation filtern ()CloudFormation](github-organization-webhook-events-cfn.md)
# Richten Sie einen globalen oder organisatorischen Webhook ein GitHub
Die allgemeinen Schritte zum Einrichten eines globalen oder organisatorischen GitHub Webhooks lauten wie folgt. Weitere Informationen zu globalen Webhooks und GitHub Organisations-Webhooks finden Sie unter. [GitHub globale Webhooks und organisatorische Webhooks](github-global-organization-webhook.md)
1. Stellen Sie den Quellspeicherort Ihres Projekts auf ein`CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`.
1. Stellen Sie in der Bereichskonfiguration des Webhooks den Bereich entweder auf `GITHUB_ORGANIZATION` oder ein, `GITHUB_GLOBAL` je nachdem, ob es sich um einen organisatorischen oder einen [globalen Webhook](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks) handeln soll. Weitere Informationen finden Sie unter [Typen von Webhooks.](https://docs.github.com/en/webhooks/types-of-webhooks)
1. Geben Sie einen Namen als Teil der Bereichskonfiguration des Webhooks an. Für Organisations-Webhooks ist dies der Organisationsname und für globale Webhooks ist dies der Unternehmensname.
**Anmerkung**
Wenn der Quelltyp des Projekts lautet`GITHUB_ENTERPRISE`, müssen Sie im Rahmen der Konfiguration des Webhook-Bereichs auch eine Domäne angeben.
1. (Optional) Wenn Sie nur Webhook-Ereignisse für bestimmte Repositorys innerhalb Ihrer Organisation oder Ihres Unternehmens erhalten möchten, können Sie dies bei der Erstellung des Webhooks `REPOSITORY_NAME` als Filter angeben.
1. Wenn Sie einen Organisations-Webhook erstellen, stellen Sie sicher, dass dieser CodeBuild über die erforderlichen Berechtigungen zum Erstellen von Webhooks auf Organisationsebene verfügt. GitHub Sie können ein GitHub persönliches Zugriffstoken mit Webhook-Berechtigungen für Organisationen erstellen oder verwenden. CodeBuild OAuth Weitere Informationen finden Sie unter [GitHub und GitHub Enterprise Server-Zugriffstoken](access-tokens-github.md).
Beachten Sie, dass Organisations-Webhooks mit allen vorhandenen GitHub Webhook-Ereignistypen funktionieren.
1. Wenn Sie einen globalen Webhook erstellen, muss der Webhook manuell erstellt werden. Weitere Hinweise zum manuellen Erstellen eines Webhooks innerhalb GitHub finden Sie unter. [GitHub manuelle Webhooks](github-manual-webhook.md)
Beachten Sie, dass globale Webhooks nur den `WORKFLOW_JOB_QUEUED` Ereignistyp unterstützen. Weitere Informationen finden Sie unter [Tutorial: Einen CodeBuild -gehosteten GitHub Actions-Runner konfigurieren](action-runner.md).
# Filtert GitHub globale oder organisatorische Webhook-Ereignisse (Konsole)
Wenn Sie ein GitHub Projekt über die Konsole erstellen, wählen Sie die folgenden Optionen aus, um innerhalb des Projekts einen GitHub globalen oder organisatorischen Webhook zu erstellen. Weitere Informationen zu globalen Webhooks und GitHub Organisations-Webhooks finden Sie unter. [GitHub globale Webhooks und organisatorische Webhooks](github-global-organization-webhook.md)
1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md).
+ In **Source (Quelle)**:
+ **Wählen **GitHub**Sie als **Quellanbieter** oder Enterprise. GitHub**
+ Wählen Sie für **Repository** die Option **GitHubScoped** Webhook aus.
Das GitHub Repository wird automatisch auf `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` gesetzt. Dies ist der erforderliche Quellpfad für globale Webhooks und Organisations-Webhooks.
**Anmerkung**
Wenn Sie Organisations-Webhooks verwenden, stellen Sie sicher, dass diese Person über die erforderlichen Rechte zum Erstellen von Webhooks auf Organisationsebene CodeBuild verfügt. GitHub Wenn Sie eine [bestehende OAuth Verbindung](oauth-app-github.md) verwenden, müssen Sie die Verbindung möglicherweise neu generieren, um diese Berechtigung zu erteilen CodeBuild . [Alternativ können Sie den Webhook mithilfe der manuellen Webhooks-Funktion CodeBuild manuell erstellen.](github-manual-webhook.md) Beachten Sie, dass Sie, wenn Sie über ein vorhandenes GitHub OAuth Token verfügen und zusätzliche Organisationsberechtigungen hinzufügen möchten, die [Genehmigung des OAuth Tokens widerrufen und das Token](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps) über die Konsole erneut verbinden können. CodeBuild
![\[Die Konfiguration des Webhooks mit GitHub Gültigkeitsbereich.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-organization-webhook-source.png)
+ Unter **Webhook-Ereignisse in der Primärquelle:**
+ Wählen Sie als **Bereichstyp** die Option **Organisationsebene** aus, wenn Sie einen Organisations-Webhook erstellen, oder **Unternehmensebene**, wenn Sie einen globalen Webhook erstellen.
+ Geben Sie als **Name** entweder den Unternehmens- oder Organisationsnamen ein, je nachdem, ob es sich bei dem Webhook um einen globalen Webhook oder einen Organisations-Webhook handelt.
Wenn der Quelltyp des Projekts lautet`GITHUB_ENTERPRISE`, müssen Sie im Rahmen der Webhook-Organisationskonfiguration auch eine Domäne angeben. Wenn die URL Ihrer Organisation beispielsweise lautet**https://domain.com/orgs/org-name**, dann ist die Domain. **https://domain.com**
**Anmerkung**
Dieser Name kann nicht geändert werden, nachdem der Webhook erstellt wurde. Um den Namen zu ändern, können Sie den Webhook löschen und neu erstellen. Wenn Sie den Webhook vollständig entfernen möchten, können Sie den Speicherort der Projektquelle auch auf ein Repository aktualisieren. GitHub
![\[Die Konfiguration von globalen oder organisatorischen Webhooks.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-organization-webhook-primary-events.png)
+ (Optional) In **Webhook-Ereignisfiltergruppen** können Sie angeben, welche [Ereignisse einen neuen Build auslösen sollen](github-webhook.md). Sie können auch `REPOSITORY_NAME` als Filter angeben, dass nur Builds für Webhook-Ereignisse aus bestimmten Repositorys ausgelöst werden.
![\[Ein Filter, der nur Builds auf Webhook-Ereignissen aus bestimmten Repositorys auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
Sie können den Ereignistyp auch auf festlegen, `WORKFLOW_JOB_QUEUED` um selbst gehostete Actions-Runner GitHub einzurichten. Weitere Informationen finden Sie unter [Tutorial: Einen CodeBuild -gehosteten GitHub Actions-Runner konfigurieren](action-runner.md).
1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**.
# Webhook-Ereignisse der GitHub Organisation filtern ()CloudFormation
Um eine CloudFormation Vorlage zum Filtern von Organisation-Webhook-Ereignissen zu verwenden, verwenden Sie die Eigenschaft des AWS CodeBuild `ScopeConfiguration` Projekts. Weitere Informationen zu globalen Webhooks und GitHub Organisations-Webhooks finden Sie unter. [GitHub globale Webhooks und organisatorische Webhooks](github-global-organization-webhook.md)
**Anmerkung**
Globale Webhooks und GitHub Enterprise-Webhooks werden von nicht unterstützt. CloudFormation
Der folgende Teil einer CloudFormation Vorlage im YAML-Format erstellt vier Filtergruppen. Zusammen lösen sie einen Build aus, wenn eine oder alle Werte den Wert true ergeben:
+ Die erste Filtergruppe gibt an, dass Pull-Requests für Branches mit Git-Referenznamen, die dem regulären Ausdruck entsprechen, `^refs/heads/main$` von einem GitHub Benutzer, der keine Konto-ID hat, erstellt oder aktualisiert `12345` werden.
+ Die zweite Filtergruppe gibt an, dass Push-Anfragen für Dateien, deren Namen dem regulären Ausdruck `READ_ME` entsprechen, in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/.*` entsprechen, erstellt werden.
+ Die dritte Filtergruppe gibt eine Push-Anforderung mit einer Head Commit-Nachricht an, die dem regulären Ausdruck `\[CodeBuild\]` entspricht.
+ Die vierte Filtergruppe spezifiziert eine Workflow-Auftragsanforderung für GitHub Aktionen mit einem Workflow-Namen, der dem regulären Ausdruck entspricht`\[CI-CodeBuild\]`.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: organization-name
Scope: GITHUB_ORGANIZATION
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitHub manuelle Webhooks
Sie können manuelle GitHub Webhooks so konfigurieren, dass CodeBuild nicht automatisch versucht wird, darin einen Webhook zu erstellen. GitHub CodeBuild gibt im Rahmen des Aufrufs zur Erstellung des Webhooks eine Payload-URL zurück und kann verwendet werden, um den darin enthaltenen Webhook manuell zu erstellen. GitHub Auch wenn CodeBuild das Erstellen eines Webhooks in Ihrem GitHub Konto nicht erlaubt ist, können Sie dennoch manuell einen Webhook für Ihr Build-Projekt erstellen.
Gehen Sie wie folgt vor, um einen GitHub manuellen Webhook zu erstellen.
**Um einen GitHub manuellen Webhook zu erstellen**
1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md).
+ In **Source (Quelle)**:
+ Wählen Sie als **Quellanbieter**. **GitHub**
+ Wählen Sie unter **Repository** die Option **Repository in meinem GitHub Konto** aus.
+ Geben Sie als **Repository URL (Repository-URL)** die URL **https://github.com/*user-name*/*repository-name*** ein.
+ Unter **Webhook-Ereignisse der Primärquelle**:
+ Wählen Sie für **Webhook — optional** die Option **Jedes Mal neu erstellen, wenn eine Codeänderung in dieses Repository übertragen wird**.
+ Wählen Sie **Zusätzliche Konfiguration** und für **Manuelle Erstellung — optional** die Option **Manuell einen Webhook für dieses Repository in GitHub der Konsole erstellen** aus. .
1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**. Notieren Sie sich die Werte **Payload-URL** und **Secret**, da Sie diese später verwenden werden.
![\[Payload-URL und Secret-Konfiguration für manuelle Webhooks.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-manual-webhook-values.png)
1. Öffnen Sie die GitHub Konsole unter `https://github.com/user-name/repository-name/settings/hooks` und wählen Sie Webhook **hinzufügen**.
+ Geben Sie für **Payload-URL** den Payload-URL-Wert ein, den Sie sich zuvor notiert haben.
+ **Wählen Sie für **Inhaltstyp** die Option application/json aus.**
+ Geben Sie für **Secret** den Wert Secret ein, den Sie sich zuvor notiert haben.
+ Konfigurieren Sie die einzelnen Ereignisse, an die eine Webhook-Payload gesendet werden soll. CodeBuild Für **welche Ereignisse möchten Sie diesen Webhook auslösen**? **, wählen Sie **Lassen Sie mich einzelne Ereignisse auswählen** und wählen Sie dann aus den folgenden Ereignissen: **Pushes**, **Pull Requests** und Releases.** Wenn Sie Builds für `WORKFLOW_JOB_QUEUED` Ereignisse starten möchten, wählen Sie **Workflow-Jobs**. Weitere Informationen zu GitHub Actions-Runnern finden Sie unter[Tutorial: Einen CodeBuild -gehosteten GitHub Actions-Runner konfigurieren](action-runner.md). Weitere Informationen zu Ereignistypen, die von unterstützt werden CodeBuild, finden Sie unter[GitHub Webhook-Ereignisse](github-webhook.md).
1. Wählen Sie **Webhook hinzufügen** aus.
# GitHub Webhook-Ereignisse
Sie können Webhook-Filtergruppen verwenden, um anzugeben, welche GitHub Webhook-Ereignisse einen Build auslösen. Sie können beispielsweise angeben, dass ein Build nur bei Änderungen an bestimmten Branches ausgelöst wird.
Sie können eine oder mehrere Webhook-Filtergruppen erstellen, um anzugeben, welche Webhook-Ereignisse einen Build auslösen. Ein Build wird ausgelöst, wenn eine Filtergruppe als wahr ausgewertet wird. Dies ist der Fall, wenn alle Filter in der Gruppe den Wert true ergeben. Wenn Sie eine Filtergruppe erstellen, geben Sie Folgendes an:
**Ein Ereignis**
Für GitHub können Sie eines oder mehrere der folgenden Ereignisse auswählen:`PUSH`,`PULL_REQUEST_CREATED`,`PULL_REQUEST_UPDATED`,`PULL_REQUEST_REOPENED`,`PULL_REQUEST_MERGED`, `PULL_REQUEST_CLOSED``RELEASED`,`PRERELEASED`, und`WORKFLOW_JOB_QUEUED`. Der Webhook-Ereignistyp ist im `X-GitHub-Event`-Header in der Webhook-Nutzlast zu finden. Im `X-GitHub-Event`-Header befindet sich möglicherweise `pull_request` oder `push`. Bei einem Pull-Anforderungstyp befindet sich der Typ im Feld `action` der Webhook-Ereignisnutzlast. Aus der folgenden Tabelle geht die Zuordnung der `X-GitHub-Event`-Header-Werte und der Werte im Feld `action` der Webhook-Pull-Anforderungsnutzlast zu den verfügbaren Ereignistypen hervor.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/github-webhook.html)
Der `PULL_REQUEST_REOPENED` Ereignistyp kann nur mit GitHub GitHub Enterprise Server verwendet werden. Der `PRERELEASED` Ereignistyp `RELEASED` und kann GitHub nur mit verwendet werden. Weitere Informationen zu `WORKFLOW_JOB_QUEUED` finden Sie unter [Tutorial: Einen CodeBuild -gehosteten GitHub Actions-Runner konfigurieren](action-runner.md).
**Ein oder mehrere optionale Filter**
Verwenden Sie einen regulären Ausdruck, um einen Filter anzugeben. Damit ein Ereignis einen Build auslöst, muss jeder Filter innerhalb der Gruppe, die diesem Ereignis zugeordnet ist, als wahr ausgewertet werden.
`ACTOR_ACCOUNT_ID`(`ACTOR_ID`in der Konsole)
Ein Webhook-Ereignis löst einen Build aus, wenn eine GitHub oder GitHub Enterprise Server-Konto-ID dem regulären Ausdrucksmuster entspricht. Dieser Wert befindet sich in der Eigenschaft `id` des Objekts `sender` in der Webhook-Nutzlast.
`HEAD_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Hauptreferenz mit dem Muster eines regulären Ausdrucks übereinstimmt (z. B. `refs/heads/branch-name` oder`refs/tags/tag-name`). Bei einem Push-Ereignis ist der Referenzname in der Eigenschaft `ref` in der Webhook-Nutzlast zu finden. Bei Pull-Anforderungsereignissen befindet sich der Branch-Name in der Eigenschaft `ref` des Objekts `head` in der Webhook-Nutzlast.
`BASE_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Basisreferenz mit dem Muster eines regulären Ausdrucks übereinstimmt (z. B.`refs/heads/branch-name`). Ein `BASE_REF`-Filter kann nur für Pull-Anforderungsereignisse verwendet werden. Der Branch-Name befindet sich in der Eigenschaft `ref` des Objekts `base` in der Webhook-Nutzlast.
`FILE_PATH`
Ein Webhook löst einen Build aus, wenn der Pfad einer geänderten Datei dem Muster regulärer Ausdrücke entspricht. Ein `FILE_PATH` Filter kann für GitHub Push- und Pull-Request-Ereignisse sowie für GitHub Enterprise Server-Push-Ereignisse verwendet werden. Er kann nicht mit GitHub Enterprise Server-Pull-Request-Ereignissen verwendet werden.
`COMMIT_MESSAGE`
Ein Webhook löst einen Build aus, wenn die Head-Commit-Nachricht dem Muster eines regulären Ausdrucks entspricht. Ein `COMMIT_MESSAGE` Filter kann für GitHub Push- und Pull-Request-Ereignisse sowie für GitHub Enterprise Server-Push-Ereignisse verwendet werden. Er kann nicht mit GitHub Enterprise Server-Pull-Request-Ereignissen verwendet werden.
`TAG_NAME`
Ein Webhook löst einen Build aus, wenn der Tag-Name der Version mit dem Muster des regulären Ausdrucks übereinstimmt. Ein `TAG_NAME` Filter kann für GitHub veröffentlichte und vorab veröffentlichte Anforderungsereignisse verwendet werden.
`RELEASE_NAME`
Ein Webhook löst einen Build aus, wenn der Versionsname mit dem Muster eines regulären Ausdrucks übereinstimmt. Ein `RELEASE_NAME` Filter kann für GitHub veröffentlichte und vorab veröffentlichte Anforderungsereignisse verwendet werden.
`REPOSITORY_NAME`
Ein Webhook löst einen Build aus, wenn der Name des Repositorys dem Muster eines regulären Ausdrucks entspricht. Ein `REPOSITORY_NAME` Filter kann nur mit GitHub globalen oder organisatorischen Webhooks verwendet werden.
`ORGANIZATION_NAME`
Ein Webhook löst einen Build aus, wenn der Name der Organisation dem Muster eines regulären Ausdrucks entspricht. Ein `ORGANIZATION_NAME` Filter kann nur mit GitHub globalen Webhooks verwendet werden.
`WORKFLOW_NAME`
Ein Webhook löst einen Build aus, wenn der Workflow-Name mit dem Muster des regulären Ausdrucks übereinstimmt. Ein `WORKFLOW_NAME` Filter kann für Ereignisse in der Warteschlange von Aufträgen im GitHub Aktionsworkflow verwendet werden.
**Anmerkung**
Sie finden die Webhook-Payload in den Webhook-Einstellungen Ihres Repositorys. GitHub
**Topics**
+ [GitHub Webhook-Ereignisse filtern (Konsole)](github-webhook-events-console.md)
+ [GitHub Webhook-Ereignisse filtern (SDK)](github-webhook-events-sdk.md)
+ [GitHub Webhook-Ereignisse filtern ()CloudFormation](github-webhook-events-cfn.md)
# GitHub Webhook-Ereignisse filtern (Konsole)
Verwenden Sie die folgenden Anweisungen, um GitHub Webhook-Ereignisse mithilfe von zu filtern. AWS-Managementkonsole Weitere Hinweise zu GitHub Webhook-Ereignissen finden Sie unter. [GitHub Webhook-Ereignisse](github-webhook.md)
Wählen Sie unter **Primäre Webhook-Ereignisse** die folgenden Optionen aus. Dieser Abschnitt ist nur verfügbar, wenn Sie **in Mein GitHub Konto für das Quell-Repository** die Option Repository ausgewählt haben.
1. Wählen Sie beim Erstellen Ihres Projekts **Rebuild every time a code change is pushed to this repository (Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wird)** aus.
1. Wählen Sie unter **Event type (Ereignistyp)** eines oder mehrere Ereignisse aus.
1. Wenn Sie Fälle filtern möchten, in denen ein Ereignis einen Build auslöst, fügen Sie unter **Start a build under these conditions (Unter diesen Bedingungen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wenn Sie Fälle filtern möchten, in denen kein Ereignis ausgelöst wird, fügen Sie unter **Don't start a build under these conditions (Unter diesen Bedingungen keinen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wählen **Sie Filtergruppe** hinzufügen, um bei Bedarf eine weitere Filtergruppe hinzuzufügen.
Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *AWS CodeBuild -API-Referenz*.
In diesem Beispiel löst eine Webhook-Filtergruppe nur für Pull-Anfragen einen Build aus:
![\[Eine Webhook-Filtergruppe, die einen Build nur für Pull-Requests auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter.png)
Bei Verwendung eines Beispiels mit zwei Webhook-Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/branch1$` entsprechen, erstellt, aktualisiert oder erneut geöffnet werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/branch1$` entsprechen.
![\[Ein Beispiel für zwei Filtergruppen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für alle Anfragen mit Ausnahme von Tag-Ereignissen aus.
![\[Eine Webhook-Filtergruppe, die einen Build für alle Anfragen außer Tag-Ereignissen auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur einen Build aus, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck `^buildspec.*` entsprechen.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn Dateien mit Namen angegeben sind, die dem regulären Ausdruck entsprechen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur dann einen Build aus, wenn Dateien in Ordnern `src` oder `test` geändert werden.
![\[Eine Webhook-Filtergruppe, die einen Build nur auslöst, wenn Dateien in bestimmten Ordnern geändert werden.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build nur dann aus, wenn eine Änderung von einem bestimmten Benutzer GitHub oder einem GitHub Enterprise Server-Benutzer mit einer Konto-ID vorgenommen wird, die dem regulären Ausdruck entspricht. `actor-account-id`
**Anmerkung**
Informationen darüber, wie Sie Ihre GitHub Konto-ID finden https://api.github.com/users/*user-name*, finden Sie unter Wo *user-name* ist Ihr GitHub Benutzername.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn eine Änderung von einem angegebenen GitHub Benutzer mit einer Konto-ID vorgenommen wird, die dem regulären Ausdruck entspricht.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-actor.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für ein Push-Ereignis aus, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
![\[Eine Webhook-Filtergruppe, die einen Build für ein Push-Ereignis auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck übereinstimmt.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build nur für GitHub Aktions-Workflow-Auftragsereignisse aus.
**Anmerkung**
CodeBuild verarbeitet GitHub Aktions-Workflow-Jobs nur, wenn ein Webhook Filtergruppen enthält, die den **WORKFLOW\$1JOB\$1QUEUED-Ereignisfilter** enthalten.
![\[Eine Webhook-Filtergruppe löst einen Build nur für Aktions-Workflow-Auftragsereignisse aus. GitHub\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-actions-workflow-job-queued-no-highlight.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für einen Workflow-Namen aus, der dem regulären Ausdruck entspricht. `CI-CodeBuild`
![\[Eine Webhook-Filtergruppe löst einen Build für einen Workflow-Namen aus, der dem regulären Ausdruck entspricht.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-actions-workflow-job-specific.png)
# GitHub Webhook-Ereignisse filtern (SDK)
Um das AWS CodeBuild SDK zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie das `filterGroups` Feld in der Anforderungssyntax der `CreateWebhook` `UpdateWebhook` API-Methoden oder. Weitere Informationen finden Sie unter [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *CodeBuild -API-Referenz*.
Weitere Informationen zu GitHub Webhook-Ereignissen finden Sie unter. [GitHub Webhook-Ereignisse](github-webhook.md)
Um einen Webhook-Filter zu erstellen, der nur für Pull-Anfragen einen Build auslöst, fügen Sie Folgendes in die Anfragesyntax ein:
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
Um einen Webhook-Filter zu erstellen, der nur für die angegebenen Verzweigungen einen Build auslöst, verwenden Sie den Parameter `pattern`, um einen regulären Ausdruck zum Filtern von Verzweigungsnamen anzugeben. Bei Verwendung eines Beispiels mit zwei Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/myBranch$` entsprechen, erstellt, aktualisiert oder erneut geöffnet werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/myBranch$` entsprechen.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
Sie können den Parameter `excludeMatchedPattern` verwenden, um anzugeben, welche Ereignisse keinen Build auslösen. In diesem Beispiel etwa wird für alle Anfragen mit Ausnahme von Tag-Ereignissen ein Build ausgelöst.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
Sie können einen Filter erstellen, der nur einen Build auslöst, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck in dem Argument `pattern` entsprechen. In diesem Beispiel gibt die Filtergruppe an, dass nur ein Build ausgelöst wird, wenn Dateien geändert werden, deren Name dem regulären Ausdruck `^buildspec.*` entspricht.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur ausgelöst wird, wenn Dateien in `test` Ordnern `src` oder geändert werden.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
Sie können einen Filter erstellen, der einen Build nur auslöst, wenn eine Änderung von einem bestimmten Benutzer GitHub oder einem GitHub Enterprise Server-Benutzer mit Konto-ID vorgenommen wird`actor-account-id`.
**Anmerkung**
Informationen darüber, wie Sie Ihre GitHub Konto-ID finden https://api.github.com/users/*user-name*, finden Sie unter Wo *user-name* ist Ihr GitHub Benutzername.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
Sie können einen Filter erstellen, der einen Build nur dann auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck im Musterargument übereinstimmt. In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur dann ausgelöst wird, wenn die Head-Commit-Nachricht des Push-Ereignisses mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
Um einen Webhook-Filter zu erstellen, der einen Build nur für Workflow-Jobs für GitHub Aktionen auslöst, fügen Sie Folgendes in die Anforderungssyntax ein:
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "WORKFLOW_JOB_QUEUED"
}
]
]
```
# GitHub Webhook-Ereignisse filtern ()CloudFormation
Um eine CloudFormation Vorlage zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie die Eigenschaft des AWS CodeBuild `FilterGroups` Projekts.
Weitere Informationen zu GitHub Webhook-Ereignissen finden Sie unter. [GitHub Webhook-Ereignisse](github-webhook.md)
Mit dem folgenden in YAML formatierten Teil einer CloudFormation -Vorlage werden zwei Filtergruppen erstellt. Diese lösen zusammen einen Build aus, wenn mindestens eine Gruppe als wahr ausgewertet wird.
+ Die erste Filtergruppe gibt an, dass Pull-Requests für Branches mit Git-Referenznamen, die dem regulären Ausdruck entsprechen, `^refs/heads/main$` von einem GitHub Benutzer, der keine Konto-ID hat, erstellt oder aktualisiert `12345` werden.
+ Die zweite Filtergruppe gibt an, dass Push-Anfragen für Dateien, deren Namen dem regulären Ausdruck `READ_ME` entsprechen, in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/.*` entsprechen, erstellt werden.
+ Die dritte Filtergruppe gibt eine Push-Anforderung mit einer Head Commit-Nachricht an, die dem regulären Ausdruck `\[CodeBuild\]` entspricht.
+ Die vierte Filtergruppe spezifiziert eine Workflow-Auftragsanforderung für GitHub Aktionen mit einem Workflow-Namen, der dem regulären Ausdruck entspricht`\[CI-CodeBuild\]`.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab Gruppen-Webhooks
Sie können CodeBuild GitLab Gruppen-Webhooks verwenden, um Builds für Webhook-Ereignisse von jedem Repository innerhalb einer Gruppe aus zu starten. GitLab Gruppen-Webhooks funktionieren mit allen vorhandenen GitLab Webhook-Ereignistypen und können konfiguriert werden, indem beim Erstellen eines Webhooks eine Bereichskonfiguration hinzugefügt wird. CodeBuild Sie können Gruppen-Webhooks auch verwenden, um [selbst gehostete GitLab Runner einzurichten, um `WORKFLOW_JOB_QUEUED` Ereignisse aus mehreren Repositorys innerhalb eines CodeBuild](gitlab-runner.md) einzigen Projekts zu empfangen.
**Topics**
+ [Richten Sie einen Gruppen-Webhook ein GitLab](gitlab-group-webhook-setup.md)
+ [Filtert GitLab Gruppen-Webhook-Ereignisse (Konsole)](gitlab-group-webhook-events-console.md)
+ [GitLab Gruppen-Webhook-Ereignisse filtern ()CloudFormation](gitlab-group-webhook-events-cfn.md)
# Richten Sie einen Gruppen-Webhook ein GitLab
Die allgemeinen Schritte zum Einrichten eines GitLab Gruppen-Webhooks lauten wie folgt. Weitere Informationen zu GitLab Gruppen-Webhooks finden Sie unter. [GitLab Gruppen-Webhooks](gitlab-group-webhook.md)
1. Stellen Sie den Quellpfad Ihres Projekts auf ein`CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`.
1. Stellen Sie in der Bereichskonfiguration des Webhooks den Bereich auf `GITLAB_GROUP` ein.
1. Geben Sie einen Namen als Teil der Bereichskonfiguration des Webhooks an. Für Gruppen-Webhooks ist dies der Gruppenname.
**Anmerkung**
Wenn der Quelltyp des Projekts lautet`GITLAB_SELF_MANAGED`, müssen Sie im Rahmen der Konfiguration des Webhook-Bereichs auch eine Domain angeben.
1. (Optional) Wenn Sie nur Webhook-Ereignisse für bestimmte Repositorys innerhalb Ihrer Organisation oder Ihres Unternehmens erhalten möchten, können Sie dies bei der Erstellung des Webhooks `REPOSITORY_NAME` als Filter angeben.
1. Wenn Sie einen Gruppen-Webhook erstellen, stellen Sie sicher, dass CodeBuild Sie berechtigt sind, innerhalb von Gruppen Webhooks auf Gruppenebene zu erstellen. GitLab Dazu können Sie jedoch verwenden CodeBuild OAuth . CodeConnections Weitere Informationen finden Sie unter [GitLab Zugriff in CodeBuild](access-tokens-gitlab-overview.md).
Beachten Sie, dass Gruppen-Webhooks mit allen vorhandenen GitLab Webhook-Ereignistypen funktionieren.
# Filtert GitLab Gruppen-Webhook-Ereignisse (Konsole)
Wenn Sie ein GitLab Projekt über die Konsole erstellen, wählen Sie die folgenden Optionen aus, um einen GitLab Gruppen-Webhook innerhalb des Projekts zu erstellen. Weitere Informationen zu GitLab Gruppen-Webhooks finden Sie unter. [GitLab Gruppen-Webhooks](gitlab-group-webhook.md)
1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md).
+ In **Source (Quelle)**:
+ **Wählen Sie als **Quellanbieter **GitLab****oder GitLab Self Managed.**
+ Wählen Sie für **Repository** die Option **GitLabScoped** Webhook aus.
Das GitLab Repository wird automatisch auf `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` gesetzt. Dies ist der erforderliche Quellpfad für Gruppen-Webhooks.
**Anmerkung**
Wenn Sie Gruppen-Webhooks verwenden, stellen Sie sicher, dass Sie CodeBuild über die erforderlichen Rechte verfügen, um innerhalb dieser Webhooks auf Gruppenebene zu erstellen. GitLab Wenn Sie eine [bestehende OAuth Verbindung](access-tokens-gitlab-overview.md#connections-gitlab) verwenden, müssen Sie die Verbindung möglicherweise neu generieren, um diese Berechtigung zu erteilen CodeBuild .
![\[Die Konfiguration eines Webhooks mit GitLab Gültigkeitsbereich.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/gitlab-group-source.png)
+ Unter **Webhook-Ereignisse der Primärquelle:**
+ Geben Sie **unter Gruppenname** den Gruppennamen ein.
Wenn der Quelltyp des Projekts lautet`GITLAB_SELF_MANAGED`, müssen Sie im Rahmen der Webhook-Gruppenkonfiguration auch eine Domäne angeben. Wenn die URL Ihrer Gruppe beispielsweise lautet**https://domain.com/group/group-name**, dann ist die Domain. **https://domain.com**
**Anmerkung**
Dieser Name kann nicht geändert werden, nachdem der Webhook erstellt wurde. Um den Namen zu ändern, können Sie den Webhook löschen und neu erstellen. Wenn Sie den Webhook vollständig entfernen möchten, können Sie den Speicherort der Projektquelle auch auf ein Repository aktualisieren. GitLab
![\[Die Konfiguration von Gruppen-Webhooks.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/gitlab-group-webhook-primary-events.png)
+ (Optional) In **Webhook-Ereignisfiltergruppen** können Sie angeben, welche [Ereignisse Sie einen neuen Build auslösen möchten](gitlab-webhook.md). Sie können auch `REPOSITORY_NAME` als Filter angeben, dass nur Builds für Webhook-Ereignisse aus bestimmten Repositorys ausgelöst werden.
![\[Ein Filter, der nur Builds auf Webhook-Ereignissen aus bestimmten Repositorys auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
Sie können den Ereignistyp auch auf festlegen, `WORKFLOW_JOB_QUEUED` um selbst GitLab gehostete Runner einzurichten. Weitere Informationen finden Sie unter [Selbstverwaltete Läufer GitLab in AWS CodeBuild](gitlab-runner.md).
1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**.
# GitLab Gruppen-Webhook-Ereignisse filtern ()CloudFormation
Um eine CloudFormation Vorlage zum Filtern von Gruppen-Webhook-Ereignissen zu verwenden, verwenden Sie die Eigenschaft des AWS CodeBuild `ScopeConfiguration` Projekts. Weitere Informationen zu GitLab Gruppen-Webhooks finden Sie unter. [GitLab Gruppen-Webhooks](gitlab-group-webhook.md)
Der folgende Teil einer CloudFormation Vorlage im YAML-Format erstellt vier Filtergruppen. Zusammen lösen sie einen Build aus, wenn eine oder alle Werte den Wert true ergeben:
+ Die erste Filtergruppe gibt an, dass Pull-Requests für Branches mit Git-Referenznamen, die dem regulären Ausdruck entsprechen, `^refs/heads/main$` von einem GitLab Benutzer ohne Konto-ID erstellt oder aktualisiert `12345` werden.
+ Die zweite Filtergruppe gibt an, dass Push-Anfragen für Dateien, deren Namen dem regulären Ausdruck `READ_ME` entsprechen, in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/.*` entsprechen, erstellt werden.
+ Die dritte Filtergruppe gibt eine Push-Anforderung mit einer Head Commit-Nachricht an, die dem regulären Ausdruck `\[CodeBuild\]` entspricht.
+ Die vierte Filtergruppe gibt einen GitLab CI/CD pipeline job request with a CI/CD Pipeline-Namen an, der dem regulären Ausdruck entspricht`\[CI-CodeBuild\]`.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: group-name
Scope: GITLAB_GROUP
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab manuelle Webhooks
Sie können manuelle GitLab Webhooks so konfigurieren, dass CodeBuild nicht automatisch versucht wird, darin einen Webhook zu erstellen. GitLab CodeBuild gibt im Rahmen des Aufrufs zur Erstellung des Webhooks eine Payload-URL zurück und kann verwendet werden, um den darin enthaltenen Webhook manuell zu erstellen. GitLab Auch wenn CodeBuild das Erstellen eines Webhooks in Ihrem GitLab Konto nicht erlaubt ist, können Sie dennoch manuell einen Webhook für Ihr Build-Projekt erstellen.
Gehen Sie wie folgt vor, um einen GitLab manuellen Webhook zu erstellen.
**Um einen GitLab manuellen Webhook zu erstellen**
1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md).
+ In **Source (Quelle)**:
+ Wählen Sie als **Quellanbieter**. **GitLab**
+ Wählen Sie unter **Repository** die Option **Repository in meinem GitLab Konto** aus.
+ Geben Sie als **Repository URL (Repository-URL)** die URL **https://gitlab.com/*user-name*/*repository-name*** ein.
+ Unter **Webhook-Ereignisse der Primärquelle**:
+ Wählen Sie für **Webhook — optional** die Option **Jedes Mal neu erstellen, wenn eine Codeänderung in dieses Repository übertragen wird**.
+ Wählen Sie **Zusätzliche Konfiguration** und für **Manuelle Erstellung — optional** die Option **Manuell einen Webhook für dieses Repository in GitLab der Konsole erstellen** aus. .
1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**. Notieren Sie sich die Werte **Payload-URL** und **Secret**, da Sie diese später verwenden werden.
1. Öffnen Sie die GitLab Konsole unter `https://gitlab.com/user-name/repository-name/-/hooks` und wählen Sie **Neuen Webhook hinzufügen**.
+ Geben Sie für **URL** den Wert der Payload-URL ein, den Sie sich zuvor notiert haben.
+ Geben Sie für **Secret Token** den Secret-Wert ein, den Sie zuvor zur Kenntnis genommen haben.
+ Konfigurieren Sie die einzelnen Ereignisse, an die eine Webhook-Payload gesendet werden soll. CodeBuild Wählen Sie für **Trigger** aus den folgenden Ereignissen: **Push-Ereignisse**, **Merge-Request-Ereignisse**, **Releases-Ereignisse** und **Job-Ereignisse**. Weitere Informationen zu den von CodeBuild unterstützten Ereignistypen finden Sie unter[GitLab Webhook-Ereignisse](gitlab-webhook.md).
1. Wählen Sie **Webhook hinzufügen** aus.
# GitLab Webhook-Ereignisse
Sie können Webhook-Filtergruppen verwenden, um anzugeben, welche GitLab Webhook-Ereignisse einen Build auslösen. Sie können beispielsweise angeben, dass ein Build nur bei Änderungen an bestimmten Branches ausgelöst wird.
Sie können eine oder mehrere Webhook-Filtergruppen erstellen, um anzugeben, welche Webhook-Ereignisse einen Build auslösen. Ein Build wird ausgelöst, wenn eine Filtergruppe den Wert true ergibt. Dies ist der Fall, wenn alle Filter in der Gruppe den Wert true ergeben. Wenn Sie eine Filtergruppe erstellen, geben Sie Folgendes an:
**Ein Ereignis**
Für GitLab können Sie eines oder mehrere der folgenden Ereignisse auswählen:`PUSH`,`PULL_REQUEST_CREATED`,`PULL_REQUEST_UPDATED`,`PULL_REQUEST_MERGED`, `PULL_REQUEST_REOPENED``PULL_REQUEST_CLOSED`,`RELEASED`, und`WORKFLOW_JOB_QUEUED`.
Der Webhook-Ereignistyp befindet sich im Header des Feldes `X-GitLab-Event`. Aus der folgende Tabelle geht die Zuordnung der `X-GitLab-Event`-Header-Werte zu Ereignistypen hervor. Für das `Merge Request Hook` Webhook-Ereignis enthalten die Payloads zusätzliche Informationen zum Typ der Merge-Anfrage. `object_atttributes.action`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/gitlab-webhook.html)
Denn `PULL_REQUEST_MERGED` wenn ein Pull-Request mit der Squash-Strategie zusammengeführt wird und der Pull-Request-Branch geschlossen wird, ist der ursprüngliche Pull-Request-Commit nicht mehr vorhanden. In diesem Fall enthält die `CODEBUILD_WEBHOOK_MERGE_COMMIT` Umgebungsvariable den Bezeichner des gequetschten Merge-Commits.
**Ein oder mehrere optionale Filter**
Verwenden Sie einen regulären Ausdruck, um einen Filter anzugeben. Damit ein Ereignis einen Build auslöst, muss jeder Filter innerhalb der Gruppe, die diesem Ereignis zugeordnet ist, als wahr ausgewertet werden.
`ACTOR_ACCOUNT_ID`(`ACTOR_ID`in der Konsole)
Ein Webhook-Ereignis löst einen Build aus, wenn eine GitLab Konto-ID dem Muster eines regulären Ausdrucks entspricht. Dieser Wert wird in der Eigenschaft `account_id` des Objekts `actor` in der Webhook-Filternutzlast angezeigt.
`HEAD_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Hauptreferenz dem Muster für reguläre Ausdrücke entspricht (z. B. `refs/heads/branch-name` und`refs/tags/tag-name`). Ein `HEAD_REF`-Filter wertet den Git-Referenznamen für den Branch oder Tag aus. Die Branch- oder Tag-Name wird im Feld `name` des Objekts `new` im Objekt `push` der Webhook-Nutzlast angezeigt. Bei Pull-Anforderungsereignissen wird der Branch-Name im Feld `name` im Objekt `branch` des Objekts `source` in der Webhook-Nutzlast angezeigt.
`BASE_REF`
Ein Webhook-Ereignis löst einen Build aus, wenn die Basisreferenz mit dem Muster des regulären Ausdrucks übereinstimmt. Ein `BASE_REF`-Filter kann nur für Pull-Anfrageereignisse verwendet werden (z. B. `refs/heads/branch-name`). Ein `BASE_REF`-Filter wertet den Git-Referenznamen für die Verzweigung aus. Der Branch-Name wird im Feld `name` des Objekts `branch` im Objekt `destination` in der Webhook-Nutzlast angezeigt.
`FILE_PATH`
Ein Webhook löst einen Build aus, wenn der Pfad einer geänderten Datei dem Muster für reguläre Ausdrücke entspricht.
`COMMIT_MESSAGE`
Ein Webhook löst einen Build aus, wenn die Head-Commit-Nachricht dem Muster des regulären Ausdrucks entspricht.
`WORKFLOW_NAME`
Ein Webhook löst einen Build aus, wenn der Workflow-Name mit dem Muster des regulären Ausdrucks übereinstimmt.
**Anmerkung**
Sie finden die Webhook-Payload in den Webhook-Einstellungen Ihres Repositorys. GitLab
**Topics**
+ [GitLab Webhook-Ereignisse filtern (Konsole)](gitlab-webhook-events-console.md)
+ [GitLab Webhook-Ereignisse filtern (SDK)](gitlab-webhook-events-sdk.md)
+ [GitLab Webhook-Ereignisse filtern ()CloudFormation](gitlab-webhook-events-cfn.md)
# GitLab Webhook-Ereignisse filtern (Konsole)
Verwenden Sie die folgenden Anweisungen, um Webhook-Ereignisse AWS-Managementkonsole zu filtern. Weitere Informationen zu GitLab Webhook-Ereignissen finden Sie unter. [GitLab Webhook-Ereignisse](gitlab-webhook.md)
1. Wählen Sie beim Erstellen Ihres Projekts **Rebuild every time a code change is pushed to this repository (Erneut erstellen, wenn eine Codeänderung an dieses Repository übergeben wird)** aus.
1. Wählen Sie unter **Event type (Ereignistyp)** eines oder mehrere Ereignisse aus.
1. Wenn Sie Fälle filtern möchten, in denen ein Ereignis einen Build auslöst, fügen Sie unter **Start a build under these conditions (Unter diesen Bedingungen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wenn Sie Fälle filtern möchten, in denen kein Ereignis ausgelöst wird, fügen Sie unter **Don't start a build under these conditions (Unter diesen Bedingungen keinen Build starten)** einen oder mehrere optionale Filter hinzu.
1. Wählen Sie **Add filter group (Filtergruppe hinzufügen)** aus, um eine weitere Filtergruppe hinzuzufügen.
Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *AWS CodeBuild -API-Referenz*.
In diesem Beispiel löst eine Webhook-Filtergruppe nur für Pull-Anfragen einen Build aus:
![\[Eine Webhook-Filtergruppe, die einen Build nur für Pull-Requests auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-gitlab.png)
Bei Verwendung eines Beispiels mit zwei Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/branch1!` entsprechen, erstellt oder aktualisiert werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/branch1$` entsprechen.
![\[Ein Beispiel für zwei Filtergruppen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-gitlab.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für alle Anfragen mit Ausnahme von Tag-Ereignissen aus.
![\[Eine Webhook-Filtergruppe, die einen Build für alle Anfragen außer Tag-Ereignissen auslöst.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-gitlab.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur einen Build aus, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck `^buildspec.*` entsprechen.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn Dateien mit Namen angegeben sind, die dem regulären Ausdruck entsprechen.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex-gitlab.png)
In diesem Beispiel löst eine Webhook-Filtergruppe nur dann einen Build aus, wenn Dateien in Ordnern `src` oder `test` geändert werden.
![\[Eine Webhook-Filtergruppe, die einen Build nur auslöst, wenn Dateien in bestimmten Ordnern geändert werden.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex-gitlab.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build nur dann aus, wenn eine Änderung von einem GitLab Benutzer vorgenommen wird, der keine Konto-ID hat, die dem regulären Ausdruck entspricht. `actor-account-id`
**Anmerkung**
Informationen darüber, wie Sie Ihre GitLab Konto-ID finden https://api.github.com/users/*user-name*, finden Sie unter Wo *user-name* ist Ihr GitLab Benutzername.
![\[Eine Webhook-Filtergruppe, die nur dann einen Build auslöst, wenn eine Änderung von einem GitLab Benutzer vorgenommen wird, der keine Konto-ID hat.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-gitlab.png)
In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für ein Push-Ereignis aus, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
![\[Eine Webhook-Filtergruppe, die einen Build für ein Push-Ereignis auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck übereinstimmt.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message-gitlab.png)
# GitLab Webhook-Ereignisse filtern (SDK)
Um das AWS CodeBuild SDK zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie das `filterGroups` Feld in der Anforderungssyntax der `CreateWebhook` `UpdateWebhook` API-Methoden oder. Weitere Informationen finden Sie unter [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *CodeBuild -API-Referenz*.
Weitere Informationen zu GitLab Webhook-Ereignissen finden Sie unter. [GitLab Webhook-Ereignisse](gitlab-webhook.md)
Um einen Webhook-Filter zu erstellen, der nur für Pull-Anfragen einen Build auslöst, fügen Sie Folgendes in die Anfragesyntax ein:
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
}
]
]
```
Um einen Webhook-Filter zu erstellen, der nur für die angegebenen Verzweigungen einen Build auslöst, verwenden Sie den Parameter `pattern`, um einen regulären Ausdruck zum Filtern von Verzweigungsnamen anzugeben. Bei Verwendung eines Beispiels mit zwei Filtergruppen wird ein Build ausgelöst, wenn mindestens eine Gruppe als wahr ausgewertet wird:
+ Die erste Filtergruppe gibt Pull-Anfragen an, die in Verzweigungen mit Git-Referenznamen, die dem regulären Ausdruck `^refs/heads/main$` entsprechen, und mit Kopfreferenzen, die `^refs/heads/myBranch$` entsprechen, erstellt oder aktualisiert werden.
+ Die zweite Filtergruppe gibt Push-Anfragen in Verzweigungen mit Git-Referenznamen an, die dem regulären Ausdruck `^refs/heads/myBranch$` entsprechen.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
Sie können den Parameter `excludeMatchedPattern` verwenden, um anzugeben, welche Ereignisse keinen Build auslösen. In diesem Beispiel wird für alle Anfragen mit Ausnahme von Tag-Ereignissen ein Build ausgelöst.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
Sie können einen Filter erstellen, der nur dann einen Build auslöst, wenn eine Änderung von einem GitLab Benutzer mit Konto-ID `actor-account-id` vorgenommen wird.
**Anmerkung**
Informationen darüber, wie Sie Ihre GitLab Konto-ID finden https://api.github.com/users/*user-name*, finden Sie unter Wo *user-name* ist Ihr GitLab Benutzername.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
Sie können einen Filter erstellen, der nur einen Build auslöst, wenn Dateien geändert werden, deren Namen dem regulären Ausdruck in dem Argument `pattern` entsprechen. In diesem Beispiel gibt die Filtergruppe an, dass nur ein Build ausgelöst wird, wenn Dateien geändert werden, deren Name dem regulären Ausdruck `^buildspec.*` entspricht.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur ausgelöst wird, wenn Dateien in `src` `test` Ordnern geändert werden.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
Sie können einen Filter erstellen, der einen Build nur dann auslöst, wenn die Head-Commit-Nachricht mit dem regulären Ausdruck im Musterargument übereinstimmt. In diesem Beispiel gibt die Filtergruppe an, dass ein Build nur dann ausgelöst wird, wenn die Head-Commit-Nachricht des Push-Ereignisses mit dem regulären Ausdruck `\[CodeBuild\]` übereinstimmt.
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# GitLab Webhook-Ereignisse filtern ()CloudFormation
Um eine CloudFormation Vorlage zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie die Eigenschaft des AWS CodeBuild `FilterGroups` Projekts. Weitere Informationen zu GitLab Webhook-Ereignissen finden Sie unter. [GitLab Webhook-Ereignisse](gitlab-webhook.md)
Mit dem folgenden in YAML formatierten Teil einer CloudFormation -Vorlage werden zwei Filtergruppen erstellt. Diese lösen zusammen einen Build aus, wenn mindestens eine Gruppe als wahr ausgewertet wird.
+ Die erste Filtergruppe gibt an, dass Pull-Requests für Branches mit Git-Referenznamen, die dem regulären Ausdruck entsprechen, `^refs/heads/main$` von einem GitLab Benutzer, der keine Konto-ID hat, erstellt oder aktualisiert `12345` werden.
+ Die zweite Filtergruppe gibt an, dass Push-Anfragen in Verzweigungen mit Git-Referenznamen erstellt werden, die dem regulären Ausdruck `^refs/heads/.*` entsprechen.
+ Die dritte Filtergruppe gibt eine Push-Anforderung mit einer Head Commit-Nachricht an, die dem regulären Ausdruck `\[CodeBuild\]` entspricht.
+ Die vierte Filtergruppe spezifiziert eine Workflow-Auftragsanforderung für GitHub Aktionen mit einem Workflow-Namen, der dem regulären Ausdruck entspricht`\[CI-CodeBuild\]`.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# Manuelle Webhooks von Buildkite
Derzeit CodeBuild müssen alle Buildkite-Webhooks manuell erstellt werden. CodeBuildgibt als Teil des Aufrufs zur Erstellung des Webhooks eine Payload-URL zurück, die verwendet werden kann, um den Webhook in Buildkite manuell zu erstellen.
Verwenden Sie das folgende Verfahren, um einen manuellen Buildkite-Webhook zu erstellen.
**Um ein CodeBuild Projekt mit einem Webhook zu erstellen**
1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md).
1. **Wählen Sie in der **Projektkonfiguration** die Option Runner-Projekt aus.**
In **Runner**:
+ Wählen Sie für den **Runner-Anbieter** **Buildkite**.
+ Wählen Sie für **Buildkite Agent Token** die Option **Create a new agent token by use the create secret** aus. Sie werden aufgefordert, in AWS Secrets Manager ein neues Geheimnis mit einem geheimen Wert zu erstellen, der dem oben generierten Buildkite-Agent-Token entspricht.
+ (Optional) Wenn Sie CodeBuild verwaltete Anmeldeinformationen für Ihren Job verwenden möchten, wählen Sie den Quell-Repository-Anbieter Ihres Jobs unter **Buildkite-Quellanmeldedaten** aus und überprüfen Sie, ob die Anmeldeinformationen für Ihr Konto konfiguriert sind. **Stellen Sie außerdem sicher, dass Ihre Buildkite-Pipeline Checkout über HTTPS verwendet.**
1.
+ In **Environment** (Umgebung):
+ **Wählen Sie ein unterstütztes **Umgebungs-Image und Compute** aus.** Beachten Sie, dass Sie die Möglichkeit haben, die Image- und Instanzeinstellungen zu überschreiben, indem Sie ein Label in Ihrem GitHub Aktions-Workflow YAML verwenden. Weitere Informationen finden Sie unter [Schritt 2: Aktualisieren Sie Ihren GitHub Aktions-Workflow YAML](action-runner.md#sample-github-action-runners-update-yaml)
+ In **Buildspec (Build-Spezifikation)**:
+ Beachten Sie, dass Ihre Buildspec ignoriert wird, sofern sie nicht als Label hinzugefügt `buildspec-override:true` wird. Stattdessen CodeBuild wird es überschrieben, um Befehle zu verwenden, die den selbst gehosteten Runner einrichten.
1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**.
1. Speichern Sie die **Payload-URL** und die **geheimen** Werte aus dem Popup „**Webhook erstellen**“. Folgen Sie den Anweisungen im Popup, um einen neuen Buildkite-Organisations-Webhook zu erstellen.
# Genehmigung eines Pull-Request-Kommentars
CodeBuild unterstützt Richtlinien zum Erstellen von Pull-Requests, die zusätzliche Kontrolle über Builds bieten, die durch Pull-Requests ausgelöst werden. Möglicherweise möchten Sie Pull-Requests von unbekannten Benutzern erst dann automatisch erstellen, wenn deren Änderungen überprüft werden können. Mit dieser Funktion können Sie von einem Ihrer Teammitglieder verlangen, zuerst den Code zu überprüfen und dann die Pipeline auszuführen. Dies wird häufig als Sicherheitsmaßnahme bei der Erstellung eines Codes verwendet, der von unbekannten Mitwirkenden eingereicht wurde.
Mithilfe von Richtlinien zum Erstellen von Pull-Requests können Sie anhand der Berechtigungen und des Genehmigungsstatus des Mitwirkenden steuern, wann Builds für Pull-Requests CodeBuild ausgelöst werden. Dies ist besonders wichtig für öffentliche Repositorien oder Repositorien, die Beiträge von externen Mitarbeitern akzeptieren.
Wenn diese Funktion aktiviert ist, stellt sie sicher, dass Builds nur für Pull-Requests ausgelöst werden, wenn entweder:
+ Die Pull-Anfrage wird von einem vertrauenswürdigen Mitwirkenden erstellt.
+ Ein vertrauenswürdiger Mitwirkender genehmigt die Pull-Anfrage, indem er einen bestimmten Kommentar veröffentlicht.
## Funktionsweise
**Vertrauenswürdige Mitwirkende**
Ein vertrauenswürdiger Mitwirkender ist ein Benutzer, dessen aktuelle Rolle im Quellcodeverwaltungssystem in der auf Pull-Requests basierenden Richtlinie als Genehmiger festgelegt ist. Wenn ein vertrauenswürdiger Mitwirkender eine Pull-Anfrage erstellt, CodeBuild löst er den Build automatisch aus, wobei das aktuelle Verhalten beibehalten wird.
**Nicht vertrauenswürdige Mitwirkende**
Ein nicht vertrauenswürdiger Mitwirkender ist ein Benutzer, dessen Rolle nicht in der Liste der Genehmigerrollen aufgeführt ist. Wenn ein nicht vertrauenswürdiger Beitrag eine Pull-Anfrage erstellt:
1. CodeBuild markiert den Build-Status als „Fehlgeschlagen“ mit der Meldung „Für den Start eines Builds ist eine Genehmigung der Pull-Anfrage erforderlich“.
1. Ein vertrauenswürdiger Mitwirkender muss die Änderungen überprüfen und einen Kommentar posten, `/codebuild_run()` um den Build auszulösen. Beispiel, `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`.
1. CodeBuild validiert die Berechtigungen des Kommentators und löst den Build aus, wenn er genehmigt wird.
1. Die Build-Ergebnisse werden auf der Pull-Request-Seite gemeldet.
**Syntax zur Genehmigung von Kommentaren**
Vertrauenswürdige Mitwirkende können Builds mit den folgenden Kommentarformaten genehmigen:
+ `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`— Trigger bauen auf dem angegebenen Commit-SHA auf.
## Konfiguration
**Standardverhalten**
Die Build-Richtlinie für Pull-Requests ist standardmäßig für alle neu erstellten CodeBuild Projekte aktiviert.
**API-Parameter**
Die Richtlinie zum Erstellen von Pull-Requests wird mithilfe des `PullRequestBuildPolicy` Parameters in den folgenden Aktionen konfiguriert:
+ `CreateWebhook`
+ `UpdateWebhook`
**`PullRequestBuildPolicy`Struktur**
```
{
"requiresCommentApproval": "string",
"approverRoles": ["string", ...]
}
```
**`requiresCommentApproval`**
Gibt an, wann eine kommentarbasierte Genehmigung erforderlich ist, bevor ein Build auf Pull-Requests ausgelöst wird. Diese Einstellung bestimmt, ob Builds automatisch ausgeführt werden oder eine ausdrückliche Genehmigung durch Kommentare erfordern.
Typ: Zeichenfolge
Zulässige Werte:
+ `DISABLED`- Builds werden automatisch ausgelöst, ohne dass eine Genehmigung durch Kommentare erforderlich ist.
+ `FORK_PULL_REQUESTS`— Nur Pull-Requests von Fork-Repositorys erfordern die Genehmigung von Kommentaren (es sei denn, der Mitwirkende gehört zu den Genehmiger).
+ `ALL_PULL_REQUESTS`— Für alle Pull-Requests ist die Genehmigung von Kommentaren erforderlich, bevor Builds ausgeführt werden können (es sei denn, der Mitwirkende gehört zu den Genehmiger). Dies ist der Standardwert.
**`approverRoles`**
Liste der Repository-Rollen, die Genehmigungsrechte für Pull-Request-Builds haben, wenn eine Genehmigung von Kommentaren erforderlich ist. Nur Benutzer mit diesen Rollen können gültige Genehmigungen für Kommentare erteilen. Wenn ein Pull-Request-Mitwirkender eine dieser Rollen ist, werden seine Pull-Request-Builds automatisch ausgelöst.
Typ: Zeichenfolgen-Array
Gültige Werte für GitHub Projekte (die Werte sind den GitHub Rollen zugeordnet):
+ `GITHUB_ADMIN`- Repository-Administratoren
+ `GITHUB_MAINTAIN`- Repository-Betreuer
+ `GITHUB_WRITE`- Benutzer mit Schreibrechten
+ `GITHUB_TRIAGE`- Benutzer mit Triage-Rechten
+ `GITHUB_READ`- Benutzer mit Leseberechtigungen
+ Standard: `["GITHUB_ADMIN", "GITHUB_MAINTAINER", "GITHUB_WRITE"]`
Gültige Werte für GitLab Projekte (die Werte sind den GitLab Rollen zugeordnet):
+ `GITLAB_OWNER`- Besitzer des Repositorys
+ `GITLAB_MAINTAINER`- Betreuer des Repositorys
+ `GITLAB_DEVELOPER`- Benutzer mit Entwicklerberechtigungen
+ `GITLAB_REPORTER`- Benutzer mit Reporterberechtigungen
+ `GITLAB_PLANNER`- Benutzer mit Planerberechtigungen
+ `GITLAB_GUEST `- Benutzer mit Gastberechtigungen
+ Standard: `["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]`
Gültige Werte für Bitbucket-Projekte (die Werte sind den Bitbucket-Rollen zugeordnet):
+ `BITBUCKET_ADMIN `— Repository-Administrator
+ `BITBUCKET_WRITE`- Benutzer mit Schreibrechten
+ `BITBUCKET_READ `- Benutzer mit Leserechten
+ Standard: `["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]`
## Beispiele
**Aktiviert die Genehmigung von Kommentaren für alle Pull-Requests**
Um das AWS CodeBuild SDK zu verwenden, um die Pull-Request-Build-Richtlinie für einen Webhook zu aktivieren oder zu deaktivieren, verwenden Sie das `pullRequestBuildPolicy` Feld in der Anforderungssyntax der `CreateWebhook` oder `UpdateWebhook` API-Methoden. Weitere Informationen finden Sie unter [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *CodeBuild -API-Referenz*.
Benutzer mit den Github-Rollen Admin, Maintain und Write werden als vertrauenswürdige Mitwirkende behandelt.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "ALL_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
```
**Aktiviere die Genehmigung von Kommentaren nur für Repository-Administratoren und -Betreuer**
Benutzer mit den GitHub Rollen Admin und Maintain werden als vertrauenswürdige Mitwirkende behandelt.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "FORK_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAINER"]
}
```
**Deaktivieren Sie die Genehmigung von Kommentaren**
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "DISABLED"
}
```
## AWS CloudFormation
Um eine AWS CloudFormation Vorlage zu verwenden, um die Pull-Request-Build-Richtlinie für einen Webhook zu aktivieren oder zu deaktivieren, verwenden Sie die PullRequestBuildPolicy Eigenschaft. Der folgende Teil einer AWS CloudFormation Vorlage im YAML-Format erstellt ein Projekt mit einem Webhook, für den die Pull-Request-Build-Richtlinie für alle Pull-Requests aktiviert ist. Verwalte und verwalte die Rollen, wie sie als Genehmiger angegeben sind.
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
PullRequestBuildPolicy:
RequiresCommentApproval: ALL_PULL_REQUESTS
ApproverRoles:
- GITHUB_MAINTAIN
- GITHUB_ADMIN
```
## Konfiguration der Konsole
So verwenden Sie die AWS Management Console zum Filtern von Webhook-Ereignissen:
1. Wählen Sie für die **Genehmigung von Kommentaren** entweder deaktiviert oder aktiviert für alle Pull-Requests (`ALL_PULL_REQUEST`) oder nur für Pull-Anfragen von Forks (`FORK_PULL_REQUEST`) aus.
1. Wählen Sie für **Genehmigerrollen** Repository-Rollen aus, die Genehmigungsrechte für Pull-Request-Builds haben, wenn eine Genehmigung von Kommentaren erforderlich ist.
Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) in der *CodeBuild -API-Referenz*.
![\[Konsole für Webhook-Ereignisse aus der primären Quelle mit Genehmigung von Kommentaren.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/pull-request-comment-approval.png)