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 di webhook per specificare quali eventi webhook attivano una compilazione. Una build viene attivata se un gruppo di filtri restituisce true, il che si verifica quando tutti i filtri del gruppo restituiscono true. Al momento della creazione di un gruppo di filtri sarà necessario indicare: 

**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**  
Per specificare un filtro, utilizza un’espressione regolare. 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)