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.
GitHub-Webhook-Ereignissen
Sie können Webhook-Filtergruppen verwenden, um anzugeben, welche GitHub-Webhook-Ereignisse einen Build auslösen. Beispielsweise können Sie angeben, dass ein Build nur für Änderungen an bestimmten Verzweigungen ausgelöst werden soll.
Sie können eine oder mehrere Webhook-Filtergruppen erstellen, um anzugeben, welche Webhook-Ereignisse einen Build auslösen. Ein Build wird ausgelöst, wenn alle Filter in einer oder mehreren Filtergruppen als wahr ausgewertet werden. Beim Erstellen einer Filtergruppe geben Sie Folgendes an:
- Eine Veranstaltung
-
Für GitHub können Sie eines oder mehrere der folgenden Ereignisse auswählen:
PUSH
,PULL_REQUEST_CREATED
,PULL_REQUEST_UPDATED
,PULL_REQUEST_REOPENED
undPULL_REQUEST_MERGED
. Der Webhook-Ereignistyp ist imX-GitHub-Event
-Header in der Webhook-Nutzlast zu finden. ImX-GitHub-Event
-Header befindet sich möglicherweisepull_request
oderpush
. Bei einem Pull-Anforderungstyp befindet sich der Typ im Feldaction
der Webhook-Ereignisnutzlast. Aus der folgenden Tabelle geht die Zuordnung derX-GitHub-Event
-Header-Werte und der Werte im Feldaction
der Webhook-Pull-Anforderungsnutzlast zu den verfügbaren Ereignistypen hervor.X-GitHub-Event
-Header-Wertaction
-Wert der Webhook-EreignisnutzlastEreignistyp pull_request
opened
PULL_REQUEST_CREATED
pull_request
reopened
PULL_REQUEST_REOPENED
pull_request
synchronize
PULL_REQUEST_UPDATED
pull_request
closed
und dasmerged
-Feld sindtrue
PULL_REQUEST_MERGED
push
– PUSH
Anmerkung
Der Ereignistyp
PULL_REQUEST_REOPENED
kann nur mit GitHub und GitHub Enterprise Server verwendet werden. - Einen oder mehrere optionale Filter
-
Verwenden Sie einen regulären Ausdruck, um einen Filter anzugeben. Ein Ereignis löst nur einen Build aus, wenn alle ihm zugeordneten Filter als wahr ausgewertet werden.
ACTOR_ACCOUNT_ID
(ACTOR_ID
in der Konsole)-
Ein Webhook-Ereignis löst einen Build aus, wenn eine GitHub Enterprise Server-Konto-ID dem Muster für reguläre Ausdrücke entspricht. Dieser Wert befindet sich in der Eigenschaft
id
des Objektssender
in der Webhook-Nutzlast. HEAD_REF
-
Ein Webhook-Ereignis löst einen Build aus, wenn die Kopfreferenz dem Muster für reguläre Ausdrücke entspricht (z. B.
refs/heads/branch-name
oderrefs/tags/tag-name
) enthalten. Bei einem Push-Ereignis ist der Referenzname in der Eigenschaftref
in der Webhook-Nutzlast zu finden. Bei Pull-Anforderungsereignissen befindet sich der Branch-Name in der Eigenschaftref
des Objektshead
in der Webhook-Nutzlast. BASE_REF
-
Ein Webhook-Ereignis löst einen Build aus, wenn die Basisreferenz dem Muster für reguläre Ausdrücke entspricht (z. B.
refs/heads/branch-name
) enthalten. EinBASE_REF
-Filter kann nur für Pull-Anforderungsereignisse verwendet werden. Der Branch-Name befindet sich in der Eigenschaftref
des Objektsbase
in der Webhook-Nutzlast. 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. Ein
FILE_PATH
-Filter kann für GitHub-Push- und -Pull-Anforderungsereignisse und GitHub Enterprise Server-Push-Ereignisse verwendet werden. Er kann nicht für GitHub Enterprise Server-Pull-Anforderungsereignisse verwendet werden. COMMIT_MESSAGE
-
Ein Webhook löst einen Build aus, wenn die Head-Commit-Nachricht dem Muster für reguläre Ausdrücke entspricht. Ein
COMMIT_MESSAGE
-Filter kann für GitHub-Push- und -Pull-Anforderungsereignisse und GitHub Enterprise Server-Push-Ereignisse verwendet werden. Er kann nicht für GitHub Enterprise Server-Pull-Anforderungsereignisse verwendet werden.
Anmerkung
Sie finden die Webhook-Nutzlast in den Webhook-Einstellungen Ihres GitHub-Repositorys.
Themen
Filtern von GitHub-Webhook-Ereignissen (Konsole)
In :Webhook-Ereignissen für primäre QuellenWählen Sie Folgendes aus. Dieser Abschnitt ist nur verfügbar, wenn SieRepository in meinem GitHub-Kontofür das Quell-Repository.
-
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.
-
Wählen Sie unter Event type (Ereignistyp) eines oder mehrere Ereignisse aus.
-
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.
-
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.
-
Klicken Sie aufHinzufügen von Filtergruppeum bei Bedarf eine weitere Filtergruppe hinzuzufügen.
Weitere Informationen finden Sie unter Erstellen Sie ein Build-Projekt (Konsole) und WebhookFilter in der AWS CodeBuild-API-Referenz.
In diesem Beispiel löst eine Webhook-Filtergruppe nur für Pull-Anfragen einen Build aus:

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.

In diesem Beispiel löst eine Webhook-Filtergruppe einen Build für alle Anfragen mit Ausnahme von Tag-Ereignissen aus.

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.

In diesem Beispiel löst eine Webhook-Filtergruppe nur dann einen Build aus, wenn eine Änderung von einem angegebenen GitHub- oder GitHub Enterprise Server-Benutzer mit einer Konto-ID vorgenommen wird, die dem regulären Ausdruck actor-account-id
entspricht.
Anmerkung
Informationen dazu, wie Sie Ihre GitHub-Konto-ID herausfinden können, finden Sie unter https://api.github.com/users/Benutzername
, wobei Benutzername
Ihr GitHub-Benutzername ist.

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.

Filtern von GitHub-Webhook-Ereignissen (SDK)
Wenn Sie das AWS CodeBuild-SDK zum Filtern von Webhook-Ereignissen nutzen möchten, verwenden Sie das Feld filterGroups
in der Anfragesyntax der API-Methoden CreateWebhook
oder UpdateWebhook
. Weitere Informationen finden Sie unterWebhookFilterimCodeBuild-API-Referenzaus.
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" } ] ]
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" }, { "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.*" } ] ]
Sie können einen Filter erstellen, der nur einen Build auslöst, wenn ein angegebener GitHub- oder GitHub Enterprise Server-Benutzer mit der Konto-ID actor-account-id
eine Änderung vornimmt.
Anmerkung
Informationen dazu, wie Sie Ihre GitHub-Konto-ID herausfinden können, finden Sie unter https://api.github.com/users/Benutzername
, wobei Benutzername
Ihr GitHub-Benutzername ist.
"filterGroups": [ [ { "type": "EVENT", "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED" }, { "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\]" } ] ]
Filtern von GitHub-Webhook-Ereignissen (AWS CloudFormation)
Wenn Sie zum Filtern von Webhook-Ereignissen eine AWS CloudFormation-Vorlage verwenden möchten, verwenden Sie die Eigenschaft FilterGroups
des AWS CodeBuild-Projekts. Mit dem folgenden in YAML formatierten Teil einer AWS 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 GitHub-Benutzer ohne die Konto-ID12345
erstellt oder aktualisiert 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.
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:4.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\]