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 als wahr ausgewertet wird. Dies ist der Fall, wenn alle Filter in der Gruppe den Wert true ergeben. Beim Erstellen einer Filtergruppe geben Sie Folgendes an:

Ein Ereignis

Für GitLab können Sie eines oder mehrere der folgenden Ereignisse wählen:

• PUSH

• PULL_REQUEST_CREATED

• PULL_REQUEST_UPDATED

• PULL_REQUEST_MERGED

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.

Anmerkung

Sie müssen das merged Ereignis in Ihrer GitLab Webhook-Einstellung aktivieren, wenn Sie eine Webhook-Filtergruppe erstellen, die den PULL_REQUEST_MERGED Ereignistyp verwendet.

X-Event-Key-Header-Wert	Ereignistyp
repo:push	PUSH
pullrequest:created	PULL_REQUEST_CREATED
pullrequest:updated	PULL_REQUEST_UPDATED
pullrequest:fulfilled	PULL_REQUEST_MERGED

Denn PULL_REQUEST_MERGED wenn ein Pull-Request mit der Squash-Strategie zusammengeführt 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_IDin 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 undrefs/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.

Anmerkung

Sie finden die Webhook-Payload in den Webhook-Einstellungen Ihres Repositorys. GitLab

GitLab Webhook-Ereignisse filtern (Konsole)

Um Webhook-Ereignisse AWS Management Console 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.

2. Wählen Sie unter Event type (Ereignistyp) eines oder mehrere Ereignisse aus.

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

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

5. 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) und WebhookFilterin 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 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.

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 Dateien in test Ordnern src oder geändert werden.

In diesem Beispiel löst eine Webhook-Filtergruppe nur dann einen Build 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 dazu, wie Sie Ihre GitLab Konto-ID finden, finden Sie unter https://api.github.com/users/ benutzername, wobei benutzername Ihr GitLab 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.

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 WebhookFilterin 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"
    }
  ]
]

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 einen Build nur auslöst, wenn eine Änderung von einem GitLab Benutzer mit Konto-ID vorgenommen wirdactor-account-id.

Anmerkung

Informationen dazu, wie Sie Ihre GitLab Konto-ID finden, finden Sie unter https://api.github.com/users/ benutzername, wobei benutzername für Ihren GitLab Benutzernamen steht.

"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 Ordnern src oder test 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 ()AWS CloudFormation

Um eine AWS CloudFormation Vorlage zum Filtern von Webhook-Ereignissen zu verwenden, verwenden Sie die Eigenschaft des AWS CodeBuild FilterGroups 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-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.

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\]