Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# GitLab eventi webhook
<a name="gitlab-webhook"></a>

È possibile utilizzare i gruppi di filtri webhook per specificare quali eventi GitLab webhook attivano una build. Ad esempio, è possibile specificare che una build venga attivata solo per le modifiche a rami specifici. 

È possibile creare uno o più gruppi di filtri webhook per specificare quali eventi webhook attivano una build. Una build viene attivata se un gruppo di filtri restituisce true, il che si verifica quando tutti i filtri del gruppo restituiscono true. Quando si crea un gruppo di filtri, si specifica: 

**Un evento**  
Infatti GitLab, puoi scegliere uno o più dei seguenti eventi:`PUSH`,`PULL_REQUEST_CREATED`,`PULL_REQUEST_UPDATED`,`PULL_REQUEST_MERGED`, `PULL_REQUEST_REOPENED``PULL_REQUEST_CLOSED`,`RELEASED`, e`WORKFLOW_JOB_QUEUED`.  
Il tipo di evento del webhook è nell'intestazione del campo `X-GitLab-Event`. La tabella seguente mostra il modo in cui i valori dell'intestazione `X-GitLab-Event` sono mappati ai tipi di eventi. Per l'evento `Merge Request Hook` webhook, il payload `object_atttributes.action` conterrà informazioni aggiuntive sul tipo di richiesta di unione.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/gitlab-webhook.html)
Infatti`PULL_REQUEST_MERGED`, se una pull request viene unita alla strategia squash e il ramo pull request viene chiuso, il commit di pull request originale non esiste più. In questo caso, la variabile di `CODEBUILD_WEBHOOK_MERGE_COMMIT` ambiente contiene l'identificatore dello squashed merge commit.

**Uno o più filtri opzionali**  
Usa un'espressione regolare per specificare un filtro. Affinché un evento attivi una build, ogni filtro all'interno del gruppo ad esso associato deve restituire true.    
`ACTOR_ACCOUNT_ID`(`ACTOR_ID`nella console)  
Un evento webhook attiva una build quando l'ID di un GitLab account corrisponde al modello di espressione regolare. Questo valore è presente nella proprietà `account_id` dell'oggetto `actor` nel payload del filtro webhook.  
`HEAD_REF`  
Un evento webhook attiva una build quando il riferimento alla testina corrisponde al modello di espressione regolare (ad esempio, and). `refs/heads/branch-name` `refs/tags/tag-name` Un filtro `HEAD_REF` valuta il nome di riferimento Git per il ramo o il tag. Il nome del ramo o del tag è presente nel campo `name` dell'oggetto `new` nell'oggetto `push` del payload del webhook. Per gli eventi di richiesta pull, il nome del ramo è presente nel campo `name` dell'oggetto `branch` dell'oggetto `source` nel payload del webhook.  
`BASE_REF`  
Un evento webhook attiva una build quando il riferimento di base corrisponde al modello di espressione regolare. Un filtro `BASE_REF` funziona solo con gli eventi di richiesta pull (ad esempio, `refs/heads/branch-name`). Un filtro `BASE_REF` valuta il nome di riferimento Git per il ramo. Il nome del ramo è presente nel campo `name` dell'oggetto `branch` nell'oggetto `destination` nel payload del webhook.  
`FILE_PATH`  
Un webhook attiva una build quando il percorso di un file modificato corrisponde al modello di espressione regolare.  
`COMMIT_MESSAGE`  
Un webhook attiva una build quando il messaggio di head commit corrisponde al modello di espressione regolare.  
`WORKFLOW_NAME`  
Un webhook attiva una build quando il nome del flusso di lavoro corrisponde al modello di espressione regolare.

**Nota**  
Puoi trovare il payload del webhook nelle impostazioni del webhook del tuo repository. GitLab 

**Topics**
+ [Filtra gli eventi GitLab webhook (console)](gitlab-webhook-events-console.md)
+ [Filtra gli eventi GitLab webhook (SDK)](gitlab-webhook-events-sdk.md)
+ [Filtra gli GitLab eventi webhook ()CloudFormation](gitlab-webhook-events-cfn.md)

# Filtra gli eventi GitLab webhook (console)
<a name="gitlab-webhook-events-console"></a>

Utilizza le seguenti istruzioni per utilizzare per Console di gestione AWS filtrare gli eventi webhook. Per ulteriori informazioni sugli eventi GitLab webhook, vedere. [GitLab eventi webhook](gitlab-webhook.md)

1.  Al momento della creazione di un progetto, selezionare **Rebuild every time a code change is pushed to this repository (Ricompila ogni volta che viene inviata una modifica del codice a questo repository)**. 

1.  Da **Event type (Tipo di evento)**, selezionare uno o più eventi. 

1.  Per applicare un filtro che stabilisce quando un evento avvia una compilazione, in **Start a build under these conditions (Avvia una compilazione in queste condizioni)** aggiungere uno o più filtri facoltativi. 

1.  Per applicare un filtro che stabilisce quando un evento non avvia una compilazione, in **Don't start a build under these conditions (Non avviare una compilazione in queste condizioni)** aggiungere uno o più filtri facoltativi. 

1.  Per aggiungere un altro gruppo di filtri, scegliere **Add filter group (Aggiungi gruppo di filtri)**. 

 Per ulteriori informazioni, consulta le pagine [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) nella *Documentazione di riferimento dell'API AWS CodeBuild *. 

In questo esempio, un gruppo di filtri webhook avvia una compilazione solo per le richieste pull:

![\[Un gruppo di filtri webhook che attiva una build solo per le richieste pull.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-gitlab.png)


In un esempio con due gruppi di filtri, una compilazione si attiva quando uno o entrambi risultano soddisfatti:
+ Il primo gruppo di filtri specifica le richieste pull create o aggiornate su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/main$` e riferimenti head che corrispondono a `^refs/heads/branch1!`. 
+ Il secondo gruppo di filtri specifica le richieste push su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/branch1$`. 

![\[Un esempio di due gruppi di filtri.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-gitlab.png)


In questo esempio, un gruppo di filtri webhook avvia una compilazione per tutte le richieste pull, tranne gli eventi tag: 

![\[Un gruppo di filtri webhook che attiva una build per tutte le richieste tranne gli eventi di tag.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-gitlab.png)


In questo esempio, un gruppo di filtri di webhook attiva una compilazione solo in caso di modifica dei file con nomi che corrispondono all'espressione regolare `^buildspec.*`. 

![\[Un gruppo di filtri webhook che attiva una build solo quando vengono specificati file con nomi che corrispondono all'espressione regolare.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex-gitlab.png)


In questo esempio, un gruppo di filtri webhook attiva una build solo quando i file vengono modificati nelle cartelle o nelle cartelle. `src` `test`

![\[Un gruppo di filtri webhook che attiva una build solo quando i file vengono modificati in cartelle specificate.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex-gitlab.png)


In questo esempio, un gruppo di filtri webhook attiva una build solo quando viene apportata una modifica da un GitLab utente che non dispone di un ID account corrispondente all'espressione regolare. `actor-account-id` 

**Nota**  
 Per informazioni su come trovare l'ID GitLab del tuo account https://api.github.com/users/*user-name*, vedi *user-name* Dov'è il tuo nome GitLab utente. 

![\[Un gruppo di filtri webhook che attiva una build solo quando viene apportata una modifica da un GitLab utente che non dispone di un ID account.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-gitlab.png)


In questo esempio, un gruppo di filtri di webhook attiva una compilazione per un evento push quando il messaggio di commit HEAD corrisponde all'espressione regolare `\[CodeBuild\]`. 

![\[Un gruppo di filtri webhook che attiva una build per un evento push quando il messaggio di head commit corrisponde all'espressione regolare.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message-gitlab.png)


# Filtra gli eventi GitLab webhook (SDK)
<a name="gitlab-webhook-events-sdk"></a>

 Per utilizzare l' AWS CodeBuild SDK per filtrare gli eventi webhook, utilizza il `filterGroups` campo nella sintassi di richiesta dei metodi o API. `CreateWebhook` `UpdateWebhook` Per ulteriori informazioni, consulta [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) nella *documentazione di riferimento dell’API CodeBuild *. 

Per ulteriori informazioni sugli eventi GitLab webhook, consulta. [GitLab eventi webhook](gitlab-webhook.md)

 Per creare un filtro di webhook che attivi una compilazione solo per le richieste pull, inserire nella sintassi di richiesta quanto segue: 

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    }
  ]
]
```

 Per creare un filtro di webhook che attivi una compilazione solo per determinati rami, utilizzare il parametro `pattern` per specificare un'espressione regolare che filtri i nomi dei rami. In un esempio con due gruppi di filtri, una compilazione si attiva quando uno o entrambi risultano soddisfatti:
+ Il primo gruppo di filtri specifica le richieste pull create o aggiornate su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/main$` e riferimenti head che corrispondono a `^refs/heads/myBranch$`. 
+ Il secondo gruppo di filtri specifica le richieste push su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/myBranch$`. 

```
"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$"
    }
  ]
]
```

 Il parametro `excludeMatchedPattern` consente di indicare quali eventi non attivano una compilazione. In questo esempio, viene attivata una compilazione per tutte le richieste, tranne gli eventi tag. 

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    },
    {
      "type": "HEAD_REF",
      "pattern": "^refs/tags/.*",
      "excludeMatchedPattern": true
    }
  ]
]
```

Puoi creare un filtro che attiva una build solo quando una modifica viene apportata da un GitLab utente con ID account. `actor-account-id` 

**Nota**  
 Per informazioni su come trovare l'ID GitLab del tuo account https://api.github.com/users/*user-name*, vedi *user-name* Dov'è il tuo nome GitLab utente. 

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
    },
    {
      "type": "ACTOR_ACCOUNT_ID",
      "pattern": "actor-account-id"
    }
  ]
]
```

È possibile creare un filtro che attivi una compilazione solo in caso di modifica dei file con nomi che corrispondono all'espressione regolare nell'argomento `pattern`. In questo esempio, il gruppo di filtri indica che una compilazione si attiva solo in caso di modifica dei file con nomi che corrispondono all'espressione regolare `^buildspec.*`. 

```
"filterGroups": [
  [
    {
      "type": "EVENT",
      "pattern": "PUSH"
    },
    {
      "type": "FILE_PATH",
      "pattern": "^buildspec.*"
    }
  ]
]
```

In questo esempio, il gruppo di filtri specifica che una build viene attivata solo quando i file vengono modificati nelle cartelle `src` o `test` nelle cartelle.

```
"filterGroups": [
    [
        {
            "type": "EVENT", 
            "pattern": "PUSH"
        },
        {
            "type": "FILE_PATH", 
            "pattern": "^src/.+|^test/.+"
        }
    ]
]
```

È possibile creare un filtro che attiva una compilazione solo quando il messaggio di commit HEAD corrisponde all'espressione regolare nell'argomento del modello. In questo esempio, il gruppo di filtri specifica che viene attivata una compilazione solo quando il messaggio di commit HEAD dell'evento push corrisponde all'espressione regolare `\[CodeBuild\]`. 

```
  "filterGroups": [
    [
      {
        "type": "EVENT",
        "pattern": "PUSH"
      },
      {
        "type": "COMMIT_MESSAGE",
        "pattern": "\[CodeBuild\]"
      }
    ]
  ]
```

# Filtra gli GitLab eventi webhook ()CloudFormation
<a name="gitlab-webhook-events-cfn"></a>

 Per utilizzare un CloudFormation modello per filtrare gli eventi del webhook, utilizzate la proprietà del AWS CodeBuild `FilterGroups` progetto. Per ulteriori informazioni sugli eventi GitLab webhook, vedere. [GitLab eventi webhook](gitlab-webhook.md)

La parte di un modello CloudFormation in formato YAML riportata di seguito crea due gruppi di filtri. Insieme, questi attivano una compilazione quando uno o entrambi risultano soddisfatti: 
+  Il primo gruppo di filtri specifica che le richieste pull vengono create o aggiornate sui rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/main$` da un GitLab utente che non dispone di un ID `12345` account. 
+  Il secondo gruppo di filtri specifica le richieste push create su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/.*`. 
+ Il terzo gruppo di filtri specifica una richiesta push con un messaggio di commit HEAD corrispondente all'espressione regolare `\[CodeBuild\]`.
+ Il quarto gruppo di filtri specifica una richiesta di lavoro del flusso di lavoro GitHub Actions con un nome di flusso di lavoro corrispondente all'espressione regolare. `\[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\]
```