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à.
# Usa i webhook con AWS CodeBuild
AWS CodeBuild supporta l'integrazione dei webhook con GitHub GitHub Enterprise Server GitLab, GitLab Self Managed e Bitbucket.
**Topics**
+ [Le migliori pratiche per l'utilizzo dei webhook con AWS CodeBuild](#webhook-best-practices)
+ [Eventi webhook Bitbucket](bitbucket-webhook.md)
+ [GitHub webhook globali e organizzativi](github-global-organization-webhook.md)
+ [GitHub webhook manuali](github-manual-webhook.md)
+ [GitHub eventi webhook](github-webhook.md)
+ [GitLab webhook di gruppo](gitlab-group-webhook.md)
+ [GitLab webhook manuali](gitlab-manual-webhook.md)
+ [GitLab eventi webhook](gitlab-webhook.md)
+ [Webhook manuali Buildkite](buildkite-manual-webhook.md)
+ [Pull richiedi l'approvazione dei commenti](pull-request-build-policy.md)
## Le migliori pratiche per l'utilizzo dei webhook con AWS CodeBuild
Per i progetti che utilizzano archivi pubblici per configurare i webhook, consigliamo le seguenti opzioni:
Filtri di configurazione `ACTOR_ACCOUNT_ID`
Aggiungi `ACTOR_ACCOUNT_ID` filtri ai gruppi di filtri webhook del tuo progetto per specificare quali utenti possono attivare una build. Ogni evento webhook inviato a CodeBuild viene fornito con informazioni sul mittente che specificano l'identificatore dell'attore. CodeBuild filtrerà i webhook in base al modello di espressione regolare fornito nei filtri. Puoi specificare gli utenti specifici autorizzati ad attivare le build con questo filtro. Per ulteriori informazioni, consultare [GitHub eventi webhook](github-webhook.md) e [Eventi webhook Bitbucket](bitbucket-webhook.md).
Imposta `FILE_PATH` i filtri
Aggiungi `FILE_PATH` filtri ai gruppi di filtri webhook del tuo progetto per includere o escludere i file che possono attivare una build quando vengono modificati. Ad esempio, puoi negare le richieste di compilazione di modifiche al `buildspec.yml` file utilizzando un modello di espressione regolare come`^buildspec.yml$`, insieme alla `excludeMatchedPattern` proprietà. Per ulteriori informazioni, consultare [GitHub eventi webhook](github-webhook.md) e [Eventi webhook Bitbucket](bitbucket-webhook.md).
Definisci le autorizzazioni per il tuo ruolo di build IAM
Le build attivate da un webhook utilizzano il ruolo del servizio IAM specificato nel progetto. Ti consigliamo di impostare le autorizzazioni nel ruolo di servizio sul set minimo di autorizzazioni richieste per eseguire la build. Ad esempio, in uno scenario di test e distribuzione, crea un progetto per il test e un altro progetto per la distribuzione. Il progetto di test accetta build di webhook dal repository, ma non fornisce autorizzazioni di scrittura per le tue risorse. Il progetto di distribuzione fornisce autorizzazioni di scrittura per le risorse e il filtro webhook è configurato per consentire solo agli utenti attendibili di attivare le build.
Usa una specifica di build archiviata in linea o Amazon S3
Se definisci il tuo buildspec in linea all'interno del progetto stesso o memorizzi il file buildspec in un bucket Amazon S3, il file buildspec è visibile solo al proprietario del progetto. Ciò impedisce alle pull request di apportare modifiche al codice del file buildspec e di attivare build indesiderate. *Per ulteriori informazioni, consulta [ProjectSource.buildspec](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-buildspec) nell'API Reference. CodeBuild*
# Eventi webhook Bitbucket
È possibile utilizzare gruppi di filtri di webhook per specificare quali eventi webhook Bitbucket attivano una compilazione. Ad esempio, puoi 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**
Per Bitbucket, puoi scegliere uno o più dei seguenti eventi:
+ `PUSH`
+ `PULL_REQUEST_CREATED`
+ `PULL_REQUEST_UPDATED`
+ `PULL_REQUEST_MERGED`
+ `PULL_REQUEST_CLOSED`
Il tipo di evento del webhook è nell'intestazione del campo `X-Event-Key`. La tabella seguente mostra il modo in cui i valori dell'intestazione `X-Event-Key` sono mappati ai tipi di eventi.
È necessario abilitare l'evento `merged` evento nell'impostazione del webhook Bitbucket se viene creato un gruppo di filtri di webkhook che utilizza il tipo di evento `PULL_REQUEST_MERGED`. È inoltre necessario abilitare l'`declined`evento nelle impostazioni del webhook di Bitbucket se si crea un gruppo di filtri webhook che utilizza il tipo di evento. `PULL_REQUEST_CLOSED`
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/bitbucket-webhook.html)
Infatti`PULL_REQUEST_MERGED`, se una pull request viene unita alla strategia squash e il ramo pull request viene chiuso, il commit originale della pull request 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 account Bitbucket 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 Bitbucket.
**Topics**
+ [Filtro di eventi webhook Bitbucket (console)](bitbucket-webhook-events-console.md)
+ [Filtro di eventi webhook Bitbucket (SDK)](bitbucket-webhook-events-sdk.md)
+ [Filtro di eventi webhook Bitbucket (CloudFormation)](bitbucket-webhook-events-cfn.md)
# Filtro di eventi webhook Bitbucket (console)
Per utilizzare il per Console di gestione AWS filtrare gli eventi del webhook:
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-bitbucket.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-bitbucket.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-bitbucket.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.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.png)
In questo esempio, un gruppo di filtri webhook avvia una compilazione solo quando un utente Bitbucket che non dispone di un ID account corrispondente all'espressione regolare `actor-account-id` apporta una modifica.
**Nota**
Per informazioni su come trovare l'ID del tuo account Bitbucket, consulta https://api.bitbucket.org/2.0/users/*user-name*, *user-name* dov'è il tuo nome utente Bitbucket.
![\[Un gruppo di filtri webhook che attiva una build solo quando viene apportata una modifica da un utente Bitbucket che non dispone di un ID account.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-bitbucket.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.png)
# Filtro di eventi webhook Bitbucket (SDK)
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 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, PULL_REQUEST_CLOSED"
}
]
]
```
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, 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$"
}
]
]
```
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, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
È possibile creare un filtro che attivi una compilazione solo quando un utente Bitbucket che dispone di un ID account `actor-account-id` apporta una modifica.
**Nota**
Per informazioni su come trovare l'ID del tuo account Bitbucket, consulta https://api.bitbucket.org/2.0/users/*user-name*, *user-name* dov'è il tuo nome utente Bitbucket.
```
"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"
}
]
]
```
È 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 o nelle cartelle. `src` `test`
```
"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\]"
}
]
]
```
# Filtro di eventi webhook Bitbucket (CloudFormation)
Per utilizzare un CloudFormation modello per filtrare gli eventi webhook, utilizzate la proprietà del AWS CodeBuild progetto. `FilterGroups` 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 le richieste pull create o aggiornate su rami con nomi di riferimento Git che corrispondono all'espressione regolare `^refs/heads/main$` da un utente Bitbucket che non dispone di un ID account `12345`.
+ 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\]`.
```
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 webhook globali e organizzativi
È possibile utilizzare i webhook CodeBuild GitHub globali o organizzativi per avviare build su eventi webhook da qualsiasi repository all'interno di un'organizzazione o di un'azienda. GitHub I webhook globali e organizzativi funzionano con tutti i tipi di eventi GitHub webhook esistenti e possono essere configurati aggiungendo una configurazione di ambito durante la creazione di un webhook. CodeBuild Puoi anche utilizzare webhook globali e organizzativi per [configurare GitHub Action runner ospitati autonomamente al fine di ricevere `WORKFLOW_JOB_QUEUED` eventi da più repository CodeBuild all'interno](action-runner.md) di un singolo progetto.
**Topics**
+ [Configura un webhook globale o organizzativo GitHub](github-global-organization-webhook-setup.md)
+ [Filtra gli eventi webhook GitHub globali o organizzativi (console)](github-global-organization-webhook-events-console.md)
+ [Filtra gli eventi webhook GitHub dell'organizzazione ()CloudFormation](github-organization-webhook-events-cfn.md)
# Configura un webhook globale o organizzativo GitHub
I passaggi principali per configurare un GitHub webhook globale o organizzativo sono i seguenti. Per ulteriori informazioni sui GitHub webhook globali e organizzativi, vedere. [GitHub webhook globali e organizzativi](github-global-organization-webhook.md)
1. Imposta la posizione di origine del progetto su. `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`
1. Nella configurazione dell'ambito del webhook, imposta l'ambito su uno `GITHUB_ORGANIZATION` o in `GITHUB_GLOBAL` base al fatto che si tratti di un'organizzazione o di un [webhook globale](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks). Per ulteriori informazioni, consulta [Tipi di webhook.](https://docs.github.com/en/webhooks/types-of-webhooks)
1. Specificate un nome come parte della configurazione dell'ambito del webhook. Per i webhook dell'organizzazione, questo è il nome dell'organizzazione, mentre per i webhook globali è il nome dell'azienda.
**Nota**
Se il tipo di sorgente del progetto è`GITHUB_ENTERPRISE`, sarà inoltre necessario specificare un dominio come parte della configurazione dell'ambito del webhook.
1. (Facoltativo) Se desideri ricevere solo eventi webhook per repository specifici all'interno della tua organizzazione o azienda, puoi specificarli `REPOSITORY_NAME` come filtro durante la creazione del webhook.
1. Se state creando un webhook aziendale, assicuratevi di disporre delle autorizzazioni necessarie per creare webhook a livello di organizzazione all'interno. CodeBuild GitHub Puoi creare un token di accesso GitHub personale con le autorizzazioni dei webhook dell'organizzazione o utilizzarlo. CodeBuild OAuth Per ulteriori informazioni, consulta [GitHub e token di accesso a GitHub Enterprise Server](access-tokens-github.md).
Tieni presente che i webhook dell'organizzazione funzionano con tutti i tipi di eventi webhook esistenti GitHub .
1. Se stai creando un webhook globale, il webhook dovrà essere creato manualmente. Per ulteriori informazioni su come creare manualmente un webhook all'interno GitHub, consulta. [GitHub webhook manuali](github-manual-webhook.md)
Tieni presente che i webhook globali supportano solo il `WORKFLOW_JOB_QUEUED` tipo di evento. Per ulteriori informazioni, consulta [Tutorial: configura un GitHub Actions CodeBuild runner ospitato](action-runner.md).
# Filtra gli eventi webhook GitHub globali o organizzativi (console)
Quando crei un GitHub progetto tramite la console, seleziona le seguenti opzioni per creare un webhook GitHub globale o organizzativo all'interno del progetto. Per ulteriori informazioni sui GitHub webhook globali e organizzativi, consulta. [GitHub webhook globali e organizzativi](github-global-organization-webhook.md)
1. [Apri la AWS CodeBuild console su codebuild/homehttps://console.aws.amazon.com/codesuite/.](https://console.aws.amazon.com/codesuite/codebuild/home)
1. Creare un progetto di compilazione. Per informazioni, consulta [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [Esecuzione di una compilazione (console)](run-build-console.md).
+ In **Source (Origine)**:
+ **Come **fornitore di origine**, scegli **GitHub**Enterprise. GitHub**
+ Per **Repository**, scegli webhook **GitHubcon ambito.**
Il GitHub repository verrà impostato automaticamente su`CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`, che è la posizione di origine richiesta per i webhook globali e organizzativi.
**Nota**
Se utilizzi webhook a livello di organizzazione, assicurati che disponga delle autorizzazioni necessarie per creare webhook a CodeBuild livello di organizzazione all'interno. GitHub Se utilizzi una [ OAuthconnessione esistente](oauth-app-github.md), potrebbe essere necessario rigenerare la connessione per concedere questa autorizzazione. CodeBuild In alternativa, puoi creare il webhook manualmente utilizzando la funzione [webhook CodeBuild manuale](github-manual-webhook.md). Tieni presente che se disponi di un GitHub OAuth token esistente e desideri aggiungere ulteriori autorizzazioni all'organizzazione, puoi [revocare l'autorizzazione del OAuth token e ricollegare il token](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps) tramite la console. CodeBuild
![\[La configurazione del webhook con ambito. GitHub\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-organization-webhook-source.png)
+ Negli eventi del **webhook della fonte primaria**:
+ Per il **tipo di ambito**, scegli il **livello di organizzazione** se stai creando un webhook **aziendale o il livello Enterprise** se stai creando un webhook globale.
+ Per **Nome**, inserisci il nome dell'azienda o dell'organizzazione, a seconda che il webhook sia un webhook globale o dell'organizzazione.
Se il tipo di origine del progetto è`GITHUB_ENTERPRISE`, è inoltre necessario specificare un dominio come parte della configurazione dell'organizzazione del webhook. Ad esempio, se l'URL della tua organizzazione è**https://domain.com/orgs/org-name**, allora il dominio è**https://domain.com**.
**Nota**
Questo nome non può essere modificato dopo la creazione del webhook. Per modificare il nome, è possibile eliminare e ricreare il webhook. Se desideri rimuovere completamente il webhook, puoi anche aggiornare la posizione di origine del progetto in un repository. GitHub
![\[La configurazione dei webhook globali o organizzativi.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-organization-webhook-primary-events.png)
+ (Facoltativo) Nei **gruppi di filtri degli eventi Webhook**, puoi specificare quali [eventi desideri attivare una](github-webhook.md) nuova build. È inoltre possibile specificare `REPOSITORY_NAME` come filtro di attivare solo le build sugli eventi webhook provenienti da repository specifici.
![\[Un filtro che attiva solo gli eventi webhook provenienti da repository specifici.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
Puoi anche impostare il tipo di evento su per configurare gli Actions runner `WORKFLOW_JOB_QUEUED` ospitati autonomamente. GitHub Per ulteriori informazioni, consulta [Tutorial: configura un GitHub Actions CodeBuild runner ospitato](action-runner.md).
1. Continua con i valori predefiniti, quindi scegli **Crea progetto di compilazione**.
# Filtra gli eventi webhook GitHub dell'organizzazione ()CloudFormation
Per utilizzare un CloudFormation modello per filtrare gli eventi del webhook dell'organizzazione, utilizzate la proprietà del AWS CodeBuild `ScopeConfiguration` progetto. Per ulteriori informazioni sui GitHub webhook globali e organizzativi, consulta. [GitHub webhook globali e organizzativi](github-global-organization-webhook.md)
**Nota**
I webhook globali e i webhook GitHub Enterprise non sono supportati da. CloudFormation
La seguente parte di un modello in formato YAML crea quattro gruppi di filtri. CloudFormation Insieme, attivano una build quando uno o tutti restituiscono true:
+ 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 GitHub utente che non dispone di un ID `12345` account.
+ Il secondo gruppo di filtri specifica le richieste push create su file con nomi che corrispondono all'espressione regolare `READ_ME` in 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: 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 webhook manuali
È possibile configurare i GitHub webhook manuali per CodeBuild impedire il tentativo automatico di creare un webhook al loro interno. GitHub CodeBuild restituisce un URL di payload come parte della chiamata per creare il webhook e può essere utilizzato per creare manualmente il webhook al suo interno. GitHub Anche se la creazione di un webhook nel tuo GitHub account non CodeBuild è consentita, puoi comunque creare manualmente un webhook per il tuo progetto di build.
Usa la seguente procedura per creare un GitHub webhook manuale.
**Per creare un webhook GitHub manuale**
1. Apri la AWS CodeBuild console su [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Creare un progetto di compilazione. Per informazioni, consulta [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [Esecuzione di una compilazione (console)](run-build-console.md).
+ In **Source (Origine)**:
+ Per **Source provider**, scegli. **GitHub**
+ Per **Repository**, scegli **Repository nel mio GitHub account**.
+ Nel campo **Repository URL (URL repository)**, inserire **https://github.com/*user-name*/*repository-name***
+ Negli eventi **webhook di Primary Source:**
+ Per **Webhook: facoltativo**, scegli **Ricostruisci ogni volta che viene inviata una modifica al codice in questo repository.**
+ Scegli **Configurazione aggiuntiva** e per **Creazione manuale: facoltativo**, scegli **Crea manualmente un webhook per** questo repository nella console. GitHub .
1. Continua con i valori predefiniti, quindi scegli **Crea progetto di compilazione**. Prendi nota dei valori **Payload URL** e **Secret** poiché li utilizzerai in seguito.
![\[Payload URL e configurazione segreta per webhook manuali.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-manual-webhook-values.png)
1. **Apri la GitHub console all'indirizzo `https://github.com/user-name/repository-name/settings/hooks` e scegli Aggiungi webhook.**
+ Per **Payload URL**, inserisci il valore dell'URL di payload di cui hai preso nota in precedenza.
+ **Per **Tipo di contenuto**, scegli application/json.**
+ Per **Segreto**, inserisci il valore Segreto di cui hai preso nota in precedenza.
+ Configura i singoli eventi a cui verrà inviato un payload del webhook. CodeBuild Per **quali eventi desideri attivare questo** webhook? **, scegli **Consentimi di selezionare singoli eventi**, quindi scegli tra i seguenti eventi: **Push, **Pull request** e Releases**.** Se desideri avviare le build per `WORKFLOW_JOB_QUEUED` eventi, scegli **Workflow** jobs. Per ulteriori informazioni sui runner GitHub Actions, consulta. [Tutorial: configura un GitHub Actions CodeBuild runner ospitato](action-runner.md) Per ulteriori informazioni sui tipi di eventi supportati da CodeBuild, consulta[GitHub eventi webhook](github-webhook.md).
1. Scegli **Aggiungi webhook.**
# GitHub eventi webhook
È possibile utilizzare i gruppi di filtri webhook per specificare quali eventi GitHub 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 GitHub, puoi scegliere uno o più dei seguenti eventi:`PUSH`,`PULL_REQUEST_CREATED`,`PULL_REQUEST_UPDATED`,`PULL_REQUEST_REOPENED`,`PULL_REQUEST_MERGED`, `PULL_REQUEST_CLOSED``RELEASED`,`PRERELEASED`, e`WORKFLOW_JOB_QUEUED`. Il tipo di evento webhook si trova nell'intestazione `X-GitHub-Event` nel payload del webhook. Nell'intestazione `X-GitHub-Event` puoi vedere `pull_request` o `push`. Per un evento di richiesta pull, il tipo si trova nel campo `action` del payload del webhook. La tabella seguente mostra il modo in cui i valori dell'intestazione `X-GitHub-Event` e i valori del campo `action` del payload della richiesta pull del webhook sono mappati ai tipi di eventi disponibili.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/github-webhook.html)
Il tipo di `PULL_REQUEST_REOPENED` evento può essere utilizzato solo con GitHub Enterprise GitHub Server. Il tipo di `PRERELEASED` evento `RELEASED` and può essere utilizzato GitHub solo con. Per ulteriori informazioni su `WORKFLOW_JOB_QUEUED`, consulta [Tutorial: configura un GitHub Actions CodeBuild runner ospitato](action-runner.md).
**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 account GitHub o di GitHub Enterprise Server corrisponde al modello di espressione regolare. Questo valore si trova nella proprietà `id` dell'oggetto `sender` nel payload del webhook.
`HEAD_REF`
Un evento webhook attiva una build quando il riferimento alla testina corrisponde al modello di espressione regolare (ad esempio, o). `refs/heads/branch-name` `refs/tags/tag-name` Per un evento push, il nome di riferimento si trova nella proprietà `ref` nel payload del webhook. Per gli eventi di richieste pull, il nome del ramo si trova nella proprietà `ref` dell'oggetto `head` nel payload del webhook.
`BASE_REF`
Un evento webhook attiva una build quando il riferimento di base corrisponde al modello di espressione regolare (ad esempio,). `refs/heads/branch-name` Un filtro `BASE_REF` può essere utilizzato solo con gli eventi di richiesta pull. Il nome del ramo si trova nella proprietà `ref` dell'oggetto `base` nel payload del webhook.
`FILE_PATH`
Un webhook attiva una build quando il percorso di un file modificato corrisponde al modello delle espressioni regolari. È possibile utilizzare un `FILE_PATH` filtro con eventi di richiesta GitHub push e pull ed eventi push di GitHub Enterprise Server. Non può essere utilizzato con gli eventi di pull request di GitHub Enterprise Server.
`COMMIT_MESSAGE`
Un webhook attiva una build quando il messaggio head commit corrisponde al modello di espressione regolare. Un `COMMIT_MESSAGE` filtro può essere utilizzato con gli eventi di richiesta GitHub push e pull e gli eventi push di GitHub Enterprise Server. Non può essere utilizzato con gli eventi di pull request di GitHub Enterprise Server.
`TAG_NAME`
Un webhook attiva una build quando il nome del tag della release corrisponde al modello di espressione regolare. È possibile utilizzare un `TAG_NAME` filtro con eventi di richiesta GitHub rilasciati e non rilasciati in anteprima.
`RELEASE_NAME`
Un webhook attiva una build quando il nome della release corrisponde al modello di espressione regolare. È possibile utilizzare un `RELEASE_NAME` filtro con eventi di richiesta GitHub rilasciati e non rilasciati in anteprima.
`REPOSITORY_NAME`
Un webhook attiva una build quando il nome del repository corrisponde al modello di espressione regolare. Un `REPOSITORY_NAME` filtro può essere utilizzato solo con webhook GitHub globali o organizzativi.
`ORGANIZATION_NAME`
Un webhook attiva una build quando il nome dell'organizzazione corrisponde al modello di espressione regolare. Un `ORGANIZATION_NAME` filtro può essere utilizzato solo con webhook GitHub globali.
`WORKFLOW_NAME`
Un webhook attiva una build quando il nome del flusso di lavoro corrisponde al modello di espressione regolare. È possibile utilizzare un `WORKFLOW_NAME` filtro con gli eventi di richiesta di lavoro in coda del flusso di lavoro di GitHub Actions.
**Nota**
Puoi trovare il payload del webhook nelle impostazioni del webhook del tuo repository. GitHub
**Topics**
+ [Filtra gli eventi GitHub webhook (console)](github-webhook-events-console.md)
+ [Filtra gli eventi GitHub webhook (SDK)](github-webhook-events-sdk.md)
+ [Filtra gli eventi GitHub webhook ()CloudFormation](github-webhook-events-cfn.md)
# Filtra gli eventi GitHub webhook (console)
Utilizza le seguenti istruzioni per filtrare gli eventi GitHub webhook utilizzando. Console di gestione AWS Per ulteriori informazioni sugli eventi GitHub webhook, vedere. [GitHub eventi webhook](github-webhook.md)
In **Primary source webhook events**, seleziona quanto segue. Questa sezione è disponibile solo se hai scelto **Repository nel mio GitHub account come repository** di origine.
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. Scegli **Aggiungi gruppo di filtri** per aggiungere un altro gruppo di filtri, se necessario.
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.png)
In un esempio con due gruppi di filtri di webhook, una compilazione si attiva quando uno o entrambi risultano soddisfatti:
+ Il primo gruppo di filtri specifica le richieste pull create, aggiornate o riaperte su ramificazioni 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.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.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.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.png)
In questo esempio, un gruppo di filtri webhook attiva una build solo quando una modifica viene apportata da un utente specificato GitHub o da un utente di GitHub Enterprise Server con un ID account che corrisponde all'espressione regolare. `actor-account-id`
**Nota**
Per informazioni su come trovare l'ID GitHub dell'account https://api.github.com/users/*user-name*, vedi *user-name* Dov'è il tuo nome GitHub utente.
![\[Un gruppo di filtri webhook che attiva una build solo quando viene apportata una modifica da un GitHub utente specificato con un ID account che corrisponde all'espressione regolare.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-webhook-filter-actor.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 generazione 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.png)
In questo esempio, un gruppo di filtri webhook attiva solo una build for GitHub Actions Workflow Job Events.
**Nota**
CodeBuild elaborerà i lavori del flusso di lavoro GitHub Actions solo se un webhook ha gruppi di filtri contenenti il filtro di eventi **WORKFLOW\$1JOB\$1QUEUED**.
![\[Un gruppo di filtri webhook attiva una build solo per gli eventi di lavoro del flusso di lavoro Actions. GitHub\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-actions-workflow-job-queued-no-highlight.png)
In questo esempio, un gruppo di filtri webhook attiva una build per un nome di workflow che corrisponde all'espressione regolare. `CI-CodeBuild`
![\[Un gruppo di filtri webhook attiva una build per un nome di workflow che corrisponde all'espressione regolare.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-actions-workflow-job-specific.png)
# Filtra gli eventi GitHub webhook (SDK)
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 GitHub webhook, consulta. [GitHub eventi webhook](github-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_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
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, aggiornate o riaperte su ramificazioni 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, 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$"
}
]
]
```
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_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
È 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 o nelle `src` cartelle. `test`
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
È possibile creare un filtro che attiva una compilazione solo quando una modifica viene apportata da un utente specificato GitHub o da un utente di GitHub Enterprise Server con ID account. `actor-account-id`
**Nota**
Per informazioni su come trovare l'ID GitHub dell'account https://api.github.com/users/*user-name*, vedi *user-name* Dov'è il tuo nome GitHub utente.
```
"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"
}
]
]
```
È 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\]"
}
]
]
```
Per creare un filtro webhook che attivi solo i job del flusso di lavoro Build for GitHub Actions, inserisci quanto segue nella sintassi della richiesta:
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "WORKFLOW_JOB_QUEUED"
}
]
]
```
# Filtra gli eventi GitHub webhook ()CloudFormation
Per utilizzare un CloudFormation modello per filtrare gli eventi del webhook, utilizzate la proprietà del AWS CodeBuild `FilterGroups` progetto.
Per ulteriori informazioni sugli eventi GitHub webhook, vedere. [GitHub eventi webhook](github-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 GitHub utente che non dispone di un ID `12345` account.
+ Il secondo gruppo di filtri specifica le richieste push create su file con nomi che corrispondono all'espressione regolare `READ_ME` in 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: 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 webhook di gruppo
È possibile utilizzare i webhook di CodeBuild GitLab gruppo per avviare build su eventi webhook da qualsiasi repository all'interno di un gruppo. GitLab I webhook di gruppo funzionano con tutti i tipi di eventi GitLab webhook esistenti e possono essere configurati aggiungendo una configurazione di ambito durante la creazione di un webhook. CodeBuild Puoi anche utilizzare i webhook di gruppo per [configurare GitLab runner ospitati autonomamente al fine di ricevere `WORKFLOW_JOB_QUEUED` eventi da più repository CodeBuild all'interno](gitlab-runner.md) di un singolo progetto.
**Topics**
+ [Configura un webhook di gruppo GitLab](gitlab-group-webhook-setup.md)
+ [Filtra gli eventi webhook GitLab di gruppo (console)](gitlab-group-webhook-events-console.md)
+ [Filtra gli eventi webhook di GitLab gruppo ()CloudFormation](gitlab-group-webhook-events-cfn.md)
# Configura un webhook di gruppo GitLab
I passaggi principali per configurare un GitLab webhook di gruppo sono i seguenti. Per ulteriori informazioni sui GitLab webhook di gruppo, vedere. [GitLab webhook di gruppo](gitlab-group-webhook.md)
1. Imposta la posizione di origine del progetto su. `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`
1. Nella configurazione dell'ambito del webhook, imposta l'ambito su. `GITLAB_GROUP`
1. Specificate un nome come parte della configurazione dell'ambito del webhook. Per i webhook di gruppo, questo è il nome del gruppo.
**Nota**
Se il tipo di sorgente del progetto è`GITLAB_SELF_MANAGED`, dovrai anche specificare un dominio come parte della configurazione dell'ambito del webhook.
1. (Facoltativo) Se desideri ricevere solo eventi webhook per repository specifici all'interno della tua organizzazione o azienda, puoi specificarli `REPOSITORY_NAME` come filtro durante la creazione del webhook.
1. Quando create un webhook di gruppo, assicuratevi di disporre delle autorizzazioni necessarie per creare webhook a livello di gruppo all'interno. CodeBuild GitLab Per farlo, puoi usare però. CodeBuild OAuth CodeConnections Per ulteriori informazioni, consulta [GitLab accesso in CodeBuild](access-tokens-gitlab-overview.md).
Tieni presente che i webhook di gruppo funzionano con qualsiasi tipo di evento GitLab webhook esistente.
# Filtra gli eventi webhook GitLab di gruppo (console)
Quando crei un GitLab progetto tramite la console, seleziona le seguenti opzioni per creare un webhook di GitLab gruppo all'interno del progetto. Per ulteriori informazioni sui GitLab webhook di gruppo, consulta. [GitLab webhook di gruppo](gitlab-group-webhook.md)
1. [Apri la AWS CodeBuild console su codebuild/homehttps://console.aws.amazon.com/codesuite/.](https://console.aws.amazon.com/codesuite/codebuild/home)
1. Creare un progetto di compilazione. Per informazioni, consulta [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [Esecuzione di una compilazione (console)](run-build-console.md).
+ In **Source (Origine)**:
+ **Come **fornitore di origine**, scegli Self Managed **GitLab**. GitLab**
+ Per **Repository**, scegli un webhook **GitLabcon ambito.**
Il GitLab repository verrà impostato automaticamente su`CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION`, che è la posizione di origine richiesta per i webhook di gruppo.
**Nota**
Quando utilizzi webhook di gruppo, assicurati di disporre delle autorizzazioni necessarie per creare webhook a CodeBuild livello di gruppo all'interno. GitLab Se utilizzi una [ OAuthconnessione esistente](access-tokens-gitlab-overview.md#connections-gitlab), potrebbe essere necessario rigenerare la connessione per concedere questa autorizzazione. CodeBuild
![\[La configurazione del webhook con GitLab scoped.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/gitlab-group-source.png)
+ Negli eventi **webhook della fonte primaria**:
+ Per **Nome gruppo**, inserisci il nome del gruppo.
Se il tipo di sorgente del progetto è`GITLAB_SELF_MANAGED`, devi anche specificare un dominio come parte della configurazione del gruppo webhook. Ad esempio, se l'URL del gruppo è**https://domain.com/group/group-name**, allora il dominio è**https://domain.com**.
**Nota**
Questo nome non può essere modificato dopo la creazione del webhook. Per modificare il nome, puoi eliminare e ricreare il webhook. Se desideri rimuovere completamente il webhook, puoi anche aggiornare la posizione di origine del progetto in un repository. GitLab
![\[La configurazione dei webhook di gruppo.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/gitlab-group-webhook-primary-events.png)
+ (Facoltativo) Nei **gruppi di filtri degli eventi Webhook**, puoi specificare quali [eventi desideri attivare una](gitlab-webhook.md) nuova build. Puoi anche specificare `REPOSITORY_NAME` come filtro di attivare solo le build sugli eventi webhook provenienti da repository specifici.
![\[Un filtro che attiva solo gli eventi webhook provenienti da repository specifici.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
Puoi anche impostare il tipo di evento su per configurare i corridori ospitati `WORKFLOW_JOB_QUEUED` autonomamente. GitLab Per ulteriori informazioni, consulta [Runner GitLab autogestiti in AWS CodeBuild](gitlab-runner.md).
1. Continua con i valori predefiniti, quindi scegli **Crea progetto di compilazione**.
# Filtra gli eventi webhook di GitLab gruppo ()CloudFormation
Per utilizzare un CloudFormation modello per filtrare gli eventi webhook di gruppo, utilizzate la proprietà del AWS CodeBuild `ScopeConfiguration` progetto. Per ulteriori informazioni sui GitLab webhook di gruppo, vedere. [GitLab webhook di gruppo](gitlab-group-webhook.md)
La seguente parte di un modello in formato YAML crea quattro gruppi di CloudFormation filtri. Insieme, attivano una build quando uno o tutti restituiscono true:
+ 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 file con nomi che corrispondono all'espressione regolare `READ_ME` in 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 un nome di GitLab CI/CD pipeline job request with a CI/CD pipeline 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
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 webhook manuali
È possibile configurare i GitLab webhook manuali per CodeBuild impedire il tentativo automatico di creare un webhook al loro interno. GitLab CodeBuild restituisce un URL di payload come parte della chiamata per creare il webhook e può essere utilizzato per creare manualmente il webhook al suo interno. GitLab Anche se la creazione di un webhook nel tuo GitLab account non CodeBuild è consentita, puoi comunque creare manualmente un webhook per il tuo progetto di build.
Usa la seguente procedura per creare un GitLab webhook manuale.
**Per creare un webhook GitLab manuale**
1. Apri la AWS CodeBuild console su [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Creare un progetto di compilazione. Per informazioni, consulta [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [Esecuzione di una compilazione (console)](run-build-console.md).
+ In **Source (Origine)**:
+ Per **Source provider**, scegli. **GitLab**
+ Per **Repository**, scegli **Repository nel mio GitLab account**.
+ Nel campo **Repository URL (URL repository)**, inserire **https://gitlab.com/*user-name*/*repository-name***
+ Negli eventi **webhook di Primary Source:**
+ Per **Webhook: facoltativo**, scegli **Ricostruisci ogni volta che viene inviata una modifica al codice in questo repository.**
+ Scegli **Configurazione aggiuntiva** e per **Creazione manuale: facoltativo**, scegli **Crea manualmente un webhook per** questo repository nella console. GitLab .
1. Continua con i valori predefiniti, quindi scegli **Crea progetto di compilazione**. Prendi nota dei valori **Payload URL** e **Secret** poiché li utilizzerai in seguito.
1. Apri la GitLab console all'indirizzo `https://gitlab.com/user-name/repository-name/-/hooks` e scegli **Aggiungi nuovo webhook**.
+ Per **URL**, inserisci il valore dell'URL di payload che hai preso nota in precedenza.
+ Per **Secret token**, inserisci il valore Secret di cui hai preso nota in precedenza.
+ Configura i singoli eventi a cui verrà inviato un payload del webhook. CodeBuild Per **Trigger**, scegli tra i seguenti eventi: **eventi Push, eventi** **Merge request, eventi** **Releases ed eventi** **Job**. Per ulteriori informazioni sui tipi di eventi supportati da CodeBuild, consulta[GitLab eventi webhook](gitlab-webhook.md).
1. Scegli **Aggiungi webhook.**
# GitLab eventi webhook
È 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)
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)
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
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\]
```
# Webhook manuali Buildkite
Attualmente, CodeBuild richiede che tutti i webhook Buildkite vengano creati manualmente. CodeBuildrestituisce un URL di payload come parte della chiamata per creare il webhook, che può essere utilizzato per creare manualmente il webhook all'interno di Buildkite.
Usa la seguente procedura per creare un webhook manuale Buildkite.
**Per creare un CodeBuild progetto con un webhook**
1. Apri la AWS CodeBuild console su [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home).
1. Creare un progetto di compilazione. Per informazioni, consulta [Creare un progetto di compilazione (console)](create-project.md#create-project-console) e [Esecuzione di una compilazione (console)](run-build-console.md).
1. **Nella **configurazione del progetto**, scegli Runner project.**
In **Runner**:
+ **Per il **provider Runner**, scegli Buildkite.**
+ Per il **token dell'agente Buildkite, scegli Crea un nuovo token** **agente utilizzando** la pagina di creazione segreta. Ti verrà richiesto di creare un nuovo segreto in AWS Secrets Manager con un valore segreto uguale al token dell'agente Buildkite che hai generato sopra.
+ (Facoltativo) Se desideri utilizzare credenziali CodeBuild gestite per il tuo lavoro, seleziona il provider del repository di origine del tuo lavoro nelle **opzioni delle credenziali di origine di Buildkite e verifica che le credenziali** siano configurate per il tuo account. **Inoltre, verifica che la tua pipeline Buildkite utilizzi Checkout utilizzando HTTPS.**
1.
+ In **Environment (Ambiente)**:
+ **Scegli un'immagine **Environment** supportata e Calcola.** Tieni presente che hai la possibilità di sovrascrivere le impostazioni dell'immagine e dell'istanza utilizzando un'etichetta nel flusso di lavoro GitHub Actions (YAML). Per ulteriori informazioni, consulta [Passaggio 2: aggiorna il flusso di lavoro di GitHub Actions (YAML)](action-runner.md#sample-github-action-runners-update-yaml)
+ In **Buildspec**:
+ Nota che il tuo buildspec verrà ignorato a meno che non venga aggiunto come etichetta. `buildspec-override:true` Invece, lo CodeBuild sovrascriverà per utilizzare i comandi che configureranno il runner self-hosted.
1. Continua con i valori predefiniti, quindi scegli **Crea** progetto di compilazione.
1. Salva l'**URL del payload** e i valori **segreti** dal popup **Create Webhook**. Segui le istruzioni nel popup per creare un nuovo webhook dell'organizzazione Buildkite.
# Pull richiedi l'approvazione dei commenti
CodeBuild supporta le politiche di compilazione delle pull request che forniscono un controllo aggiuntivo sulle build attivate dalle richieste pull. Potresti non voler creare automaticamente richieste pull da utenti sconosciuti fino a quando le loro modifiche non saranno riviste. Questa funzionalità ti consente di richiedere a uno dei membri del tuo team di rivedere prima il codice e poi eseguire la pipeline. Questa è comunemente usata come misura di sicurezza quando si crea un codice inviato da collaboratori sconosciuti.
Le politiche di compilazione delle pull request consentono di controllare quando vengono generati i CodeBuild trigger per le richieste pull in base alle autorizzazioni e allo stato di approvazione del contributore. Ciò è particolarmente importante per gli archivi pubblici o gli archivi che accettano contributi da collaboratori esterni.
Se abilitata, questa funzionalità assicura che le build vengano attivate solo per le richieste pull quando:
+ La pull request viene creata da un collaboratore affidabile.
+ Un collaboratore affidabile approva la pull request pubblicando un commento specifico.
## Come funziona
**Collaboratori fidati**
Un collaboratore affidabile è un utente il cui ruolo attuale nel sistema di controllo del codice sorgente è impostato nella politica basata sulle pull request come ruoli di approvatore. Quando un collaboratore affidabile crea una pull request, CodeBuild attiva automaticamente la build, mantenendo il comportamento corrente.
**Collaboratori non attendibili**
Un collaboratore non attendibile è un utente il cui ruolo non è impostato nell'elenco dei ruoli di approvatore. Quando un contributo non attendibile crea una pull request:
1. CodeBuild contrassegna lo stato di compilazione come «Failed» con il messaggio «Pull request approval required for start a build».
1. Un collaboratore affidabile deve esaminare le modifiche e pubblicare un commento `/codebuild_run()` per attivare la build. Ad esempio, `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`.
1. CodeBuild convalida le autorizzazioni del commentatore e attiva la build se approvata.
1. I risultati della build vengono riportati nella pagina di pull request.
**Sintassi di approvazione dei commenti**
I collaboratori attendibili possono approvare le build utilizzando i seguenti formati di commento:
+ `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`- I trigger si basano sul commit SHA specificato.
## Configurazione
**Comportamento predefinito**
La politica di compilazione delle pull request è abilitata per impostazione predefinita per tutti i progetti appena creati CodeBuild .
**Parametri dell'API**
La politica di compilazione della pull request è configurata utilizzando il `PullRequestBuildPolicy` parametro nelle seguenti azioni:
+ `CreateWebhook`
+ `UpdateWebhook`
**`PullRequestBuildPolicy`struttura**
```
{
"requiresCommentApproval": "string",
"approverRoles": ["string", ...]
}
```
**`requiresCommentApproval`**
Speciifica quando è richiesta l'approvazione basata sui commenti prima di attivare una build on pull request. Questa impostazione determina se le build vengono eseguite automaticamente o richiedono l'approvazione esplicita tramite commenti.
Tipo: String
Valori validi:
+ `DISABLED`- Le build si attivano automaticamente senza richiedere l'approvazione dei commenti.
+ `FORK_PULL_REQUESTS`- Solo le richieste pull provenienti da repository biforcati richiedono l'approvazione dei commenti (a meno che il collaboratore non sia uno dei ruoli di approvazione).
+ `ALL_PULL_REQUESTS`- Tutte le richieste pull richiedono l'approvazione dei commenti prima dell'esecuzione delle build (a meno che il collaboratore non sia uno dei ruoli di approvazione). Si tratta del valore di default.
**`approverRoles`**
Elenco dei ruoli del repository che dispongono dei privilegi di approvazione per le build di pull request quando è richiesta l'approvazione dei commenti. Solo gli utenti con questi ruoli possono fornire approvazioni di commenti valide. Se un collaboratore di pull request è uno di questi ruoli, le relative build di pull request verranno attivate automaticamente.
Tipo: array di stringhe
Valori validi per i GitHub progetti (i valori sono mappati ai ruoli): GitHub
+ `GITHUB_ADMIN`- Amministratori del repository
+ `GITHUB_MAINTAIN`- Manutentori del repository
+ `GITHUB_WRITE`- Utente con autorizzazioni di scrittura
+ `GITHUB_TRIAGE`- Utente con autorizzazioni di triage
+ `GITHUB_READ`- Utente con autorizzazioni di lettura
+ Impostazione predefinita: `["GITHUB_ADMIN", "GITHUB_MAINTAINER", "GITHUB_WRITE"]`
Valori validi per i GitLab progetti (i valori sono mappati ai GitLab ruoli):
+ `GITLAB_OWNER`- Proprietario del repository
+ `GITLAB_MAINTAINER`- Gestore del repository
+ `GITLAB_DEVELOPER`- Utente con autorizzazioni di sviluppatore
+ `GITLAB_REPORTER`- Utente con autorizzazioni di reporter
+ `GITLAB_PLANNER`- Utente con autorizzazioni di pianificazione
+ `GITLAB_GUEST `- Utente con autorizzazioni da ospite
+ Impostazione predefinita: `["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]`
Valori validi per i progetti Bitbucket (i valori sono mappati ai ruoli di Bitbucket):
+ `BITBUCKET_ADMIN `- Amministratore del repository
+ `BITBUCKET_WRITE`- Utente con autorizzazioni di scrittura
+ `BITBUCKET_READ `- Utente con autorizzazioni di lettura
+ Impostazione predefinita: `["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]`
## Esempi
**Abilita l'approvazione dei commenti per tutte le richieste pull**
Per utilizzare l' AWS CodeBuild SDK per abilitare o disabilitare la politica Pull Request Build per un webhook, utilizza il `pullRequestBuildPolicy` campo nella sintassi della richiesta dei metodi `CreateWebhook` o `UpdateWebhook` API. Per ulteriori informazioni, consulta [WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html) nella *documentazione di riferimento dell’API CodeBuild *.
Gli utenti con ruoli Github Admin, Maintain e Write verranno trattati come collaboratori affidabili.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "ALL_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
```
**Abilita l'approvazione dei commenti solo per gli amministratori e i manutentori del repository**
Gli utenti con GitHub i ruoli Admin, Maintain verranno trattati come collaboratori affidabili.
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "FORK_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAINER"]
}
```
**Disabilita l'approvazione dei commenti**
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "DISABLED"
}
```
## AWS CloudFormation
Per utilizzare un AWS CloudFormation modello per abilitare o disabilitare la politica Pull Request Build per un webhook, utilizzate la PullRequestBuildPolicy proprietà. La seguente parte di un AWS CloudFormation modello in formato YAML crea un progetto con un webhook che ha la Pull Request Build Policy abilitata per tutte le richieste pull. Mantieni e amministra i ruoli specificati come approvatori.
```
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
```
## Configurazione della console
Per utilizzare la console di AWS gestione per filtrare gli eventi dei webhook:
1. Per **l'approvazione dei commenti**, seleziona disabilitato o abilitato per tutte le richieste pull (`ALL_PULL_REQUEST`) o solo per le richieste pull da forks (`FORK_PULL_REQUEST`).
1. Per i ruoli di **approvatore, seleziona i ruoli** del repository che dispongono dei privilegi di approvazione per le build di pull request quando è richiesta l'approvazione dei commenti.
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 CodeBuild *.
![\[Console per eventi webhook di origine principale con approvazione dei commenti.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/pull-request-comment-approval.png)