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à. # Automatizza l'avvio delle pipeline utilizzando trigger e filtri I trigger consentono di configurare la pipeline in modo che inizi in base a un particolare tipo di evento o a un tipo di evento filtrato, ad esempio quando viene rilevata una modifica su un particolare ramo o richiesta pull. I trigger sono configurabili per le azioni di origine con connessioni che utilizzano l'`CodeStarSourceConnection`azione in CodePipeline, ad esempio Bitbucket e GitHub. GitLab Per ulteriori informazioni sulle azioni di origine che utilizzano connessioni, consulta. [Aggiungi fornitori di sorgenti di terze parti alle pipeline utilizzando CodeConnections](pipelines-connections.md) Le azioni di origine, come CodeCommit e S3, utilizzano il rilevamento automatico delle modifiche per avviare le pipeline quando viene apportata una modifica. Per ulteriori informazioni, consulta [CodeCommit azioni di origine e EventBridge](triggering.md). I trigger vengono specificati utilizzando la console o la CLI. I tipi di filtro vengono specificati come segue: + **Nessun filtro** Questa configurazione di trigger avvia la pipeline su qualsiasi push al ramo predefinito specificato come parte della configurazione dell'azione. + **Specificare il filtro** Aggiungi un filtro che avvia la pipeline su un filtro specifico, ad esempio sui nomi delle filiali per un push di codice, e recupera il commit esatto. Ciò configura anche la pipeline in modo che non si avvii automaticamente in caso di modifica. + **Push** + Le combinazioni di filtri valide sono: + **Tag Git** Includi o escludi + **filiali** Includi o escludi + **rami \+ percorsi di file** Includi o escludi + **Richiesta pull** + Le combinazioni di filtri valide sono: + **filiali** Includi o escludi + **rami \+ percorsi di file** Includi o escludi + **Non rileva le modifiche** Ciò non aggiunge un trigger e la pipeline non si avvia automaticamente in caso di modifica. La tabella seguente fornisce opzioni di filtro valide per ogni tipo di evento. La tabella mostra anche quali configurazioni di attivazione sono predefinite su true o false per il rilevamento automatico delle modifiche nella configurazione dell'azione. **** | Configurazione dei trigger | Tipo di evento | Opzioni di filtro | Rileva le modifiche | | --- | --- | --- | --- | | Aggiungi un trigger, nessun filtro | nessuno | nessuno | true | | Aggiungi un trigger: filtra in base al codice push | evento push | Tag Git, rami, percorsi di file | false | | Aggiungi un trigger: filtro per le richieste pull | richieste pull | rami, percorsi di file | false | | Nessun trigger: non rileva | nessuno | nessuno | false | **Nota** Questo tipo di trigger utilizza il rilevamento automatico delle modifiche (come tipo di `Webhook` trigger). I source action provider che utilizzano questo tipo di trigger sono connessioni configurate per code push (Bitbucket Cloud, GitHub Enterprise Server GitHub, GitLab .com e GitLab autogestite). Per le definizioni dei campi e ulteriori riferimenti per i trigger, vedi Per un elenco delle definizioni dei campi nella struttura JSON, vedi. [`triggers`](pipeline-requirements.md#pipeline.triggers) Per il filtraggio, i modelli di espressioni regolari in formato glob sono supportati come descritto in. [Lavorare con i modelli a globo nella sintassi](syntax-glob.md) **Nota** In alcuni casi, per le pipeline con trigger filtrati sui percorsi dei file, la pipeline potrebbe non avviarsi quando viene creato per la prima volta un ramo con un filtro per il percorso dei file. Per ulteriori informazioni, consulta [Le pipeline con connessioni che utilizzano il filtraggio dei trigger in base ai percorsi dei file potrebbero non iniziare alla creazione del ramo](troubleshooting.md#troubleshooting-file-paths-filtering). ## Considerazioni sui filtri di attivazione Le seguenti considerazioni si applicano all'utilizzo dei trigger. + Non è possibile aggiungere più di un trigger per azione sorgente. + È possibile aggiungere più tipi di filtro a un trigger. Per vedere un esempio, consulta [4: Un trigger con due tipi di filtri push con inclusione ed esclusione in conflitto](#example-filter-multiple-push). + Per un trigger con filtri per rami e percorsi di file, quando si preme il ramo per la prima volta, la pipeline non verrà eseguita poiché non è possibile accedere all'elenco dei file modificati per il ramo appena creato. + L'unione di una richiesta pull potrebbe innescare due esecuzioni di pipeline nei casi in cui le configurazioni push (filtro branch) e pull request (filtro branch) attivino l'intersezione. + Per un filtro che attiva la pipeline in base agli eventi di pull request, per il tipo di evento Closed pull request, il provider di repository di terze parti per la connessione potrebbe avere uno stato diverso per un evento di unione. Ad esempio, in Bitbucket, l'evento Git per un'unione non è un evento di chiusura di una richiesta pull. Tuttavia, in GitHub, l'unione di una pull request è un evento di chiusura. Per ulteriori informazioni, consulta [Eventi di pull request per i trigger per provider](#pipelines-filter-pullrequest-events). + Quando più azioni di origine in una pipeline fanno riferimento a rami diversi dello stesso repository tramite una connessione, solo un ramo attiva in modo affidabile la pipeline. L'abbonamento webhook della connessione è registrato per la combinazione di pipeline e repository, non per ramo. Come soluzione alternativa, utilizza una pipeline separata per ogni ramo. ## Eventi di pull request per i trigger per provider La tabella seguente fornisce un riepilogo degli eventi Git, ad esempio per la chiusura delle richieste pull, che generano tipi di eventi di pull request per provider. ****
Provider di repository per la tua connessione
Evento PR per il triggerBitbucketGitHubGHESGitLab
Apri: questa opzione attiva la pipeline quando viene creata una richiesta pull per il percorso del ramo/file.La creazione di una pull request genera un evento Opened Git.La creazione di una pull request genera un evento Opened Git.La creazione di una pull request genera un evento Opened Git.La creazione di una pull request genera un evento Opened Git.
Aggiornamento: questa opzione attiva la pipeline quando viene pubblicata una revisione della pull request per il percorso del ramo/file.La pubblicazione di un aggiornamento genera un evento Git aggiornato.La pubblicazione di un aggiornamento genera un evento Git aggiornato.La pubblicazione di un aggiornamento genera un evento Git aggiornato.La pubblicazione di un aggiornamento genera un evento Git aggiornato.
Chiuso: questa opzione attiva la pipeline quando viene chiusa una richiesta pull per il branch/file percorso.L'unione di una pull request in Bitbucket genera un evento Closed Git. Importante: la chiusura manuale di una pull request in Bitbucket senza unirla non genera un evento Closed Git.L'unione o la chiusura manuale di una richiesta pull generano un evento Closed Git.L'unione o la chiusura manuale di una richiesta pull generano un evento Closed Git.L'unione o la chiusura manuale di una richiesta pull generano un evento Closed Git.
## Esempi di filtri trigger Per una configurazione Git con filtri per i tipi di eventi push e pull request, i filtri specificati potrebbero entrare in conflitto tra loro. I seguenti sono esempi di combinazioni di filtri valide per gli eventi di richieste push e pull. Un trigger può contenere più tipi di filtri, ad esempio due tipi di filtri push nella configurazione trigger, e i tipi di filtro di richiesta push e pull utilizzeranno un'operazione OR tra di loro, il che significa che qualsiasi corrispondenza avvierà la pipeline. Allo stesso modo, ogni tipo di filtro può includere più filtri come FilePaths e branch; questi filtri utilizzeranno un'operazione AND, il che significa che solo una corrispondenza completa avvierà la pipeline. Ogni tipo di filtro può contenere inclusioni ed esclusioni, dove le esclusioni hanno la precedenza sulle inclusioni. Se un ramo o un percorso di file corrisponde a un pattern di esclusione, non attiverà la pipeline, anche se corrisponde anche a un pattern di inclusione. Quando un commit modifica più file, ogni file viene valutato indipendentemente rispetto al filtro; se un file modificato passa (corrisponde a un'inclusione e non corrisponde a un'esclusione), la pipeline si avvia. I nomi all'interno dell'opzione di inclusione/esclusione, ad esempio i nomi dei rami, utilizzano un'operazione OR. L'elenco seguente riassume le operazioni per ogni parte dell'oggetto di configurazione Git. Per un elenco delle definizioni dei campi nella struttura JSON e un riferimento dettagliato per le inclusioni e le esclusioni, consulta. [`triggers`](pipeline-requirements.md#pipeline.triggers) **Example 1: Un tipo di filtro con filtri per rami e percorsi di file (operazione AND)** Per un singolo tipo di filtro, ad esempio pull request, è possibile combinare filtri e questi filtri utilizzeranno un'operazione AND, il che significa che solo una corrispondenza completa avvierà la pipeline. L'esempio seguente mostra una configurazione Git per un tipo di evento push con due filtri diversi (`filePaths`e`branches`). Nell'esempio seguente, `filePaths` verrà inserito in E con: `branches` ``` { "filePaths": { "includes": ["common/**/*.js"] }, "branches": { "includes": ["feature/**"] } } ``` Con la configurazione Git precedente, questo esempio mostra un evento che avvierà l'esecuzione della pipeline perché l'operazione AND ha esito positivo. In altre parole, il percorso del file `common/app.js` è incluso per il filtro, che avvia la pipeline come AND anche se il ramo `refs/heads/feature/triggers ` specificato non ha avuto alcun impatto. ``` { "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "common/app.js" ] ... } ] } ``` L'esempio seguente mostra un evento relativo a un trigger con la configurazione precedente che non avvia l'esecuzione della pipeline perché il ramo è in grado di filtrare, ma il percorso del file no. ``` { "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "src/Main.java" ] ... } ] } ``` **Example 2: Le esclusioni hanno la precedenza sulle inclusioni** All'interno di un singolo filtro, le esclusioni hanno la precedenza sulle inclusioni. L'esempio seguente mostra una configurazione Git con un singolo filtro (`branches`) all'interno dell'oggetto di configurazione. Ciò significa che se un ramo corrisponde a un pattern di esclusione (`feature-branch`nell'esempio), la pipeline non verrà attivata, anche se corrisponde anche a un pattern di inclusione. Se il pattern di inclusione corrisponde e nessun pattern di esclusione corrisponde, ad esempio per il `main` ramo, verrà attivata la pipeline. Per il seguente esempio JSON: + L'invio di un commit al `main` ramo attiverà la pipeline + L'invio di un commit al `feature-branch` ramo non attiverà la pipeline. ``` { "branches": { "Includes": [ "main" ], "Excludes": [ "feature-branch" ] } ``` **Example 3: Un trigger con tipi di filtri di richiesta push e pull (operazione OR), filtri per percorsi e rami di file (operazione AND) e (le esclusioni hanno la precedenza) includes/excludes** Gli oggetti di configurazione Trigger, ad esempio un trigger che contiene un tipo di evento push e un tipo di evento pull request, utilizzano un'operazione OR tra i due tipi di evento. L'esempio seguente mostra una configurazione trigger con un tipo di evento push con il `main` branch incluso e un tipo di evento pull request con lo stesso ramo `main` escluso. Inoltre, il tipo di evento push ha un percorso di file `LICENSE.txt` escluso e un percorso di file `README.MD` incluso. Per il secondo tipo di evento, una richiesta pull che si trova `Created` su uno `Closed` o sul `feature-branch` ramo (inclusa) avvia la pipeline e la pipeline non si avvia quando si crea o si chiude una richiesta pull sui `main` rami `feature-branch-2` o (esclusi). All'interno di ogni tipo di evento, le esclusioni hanno la precedenza sulle inclusioni. Ad esempio, per un evento pull request sul `feature-branch` branch (incluso nella pull request), il tipo di evento push esclude il `feature-branch` branch, quindi il push non attiverà la pipeline. Per l'esempio seguente, + L'invio di un commit al `main` ramo (incluso) relativo al percorso del `README.MD` file (incluso) attiverà la pipeline. + Sul `feature-branch` ramo (escluso), l'invio di un commit non attiverà la pipeline. + Sul ramo incluso, la modifica del percorso del `README.MD` file (incluso) attiva la pipeline. + Nel ramo incluso, la modifica del solo percorso del `LICENSE.TXT` file (escluso) non attiva la pipeline. Tuttavia, se cambia anche lo stesso commit `README.MD` (incluso), la pipeline si attiverà perché ogni file viene valutato in modo indipendente. + Sul `feature-branch` branch, la chiusura di una richiesta pull attiverà la pipeline perché `feature-branch` è inclusa per il tipo di evento pull request e per il tipo di evento CLOSED match. L'immagine seguente mostra la configurazione. ![Un esempio di configurazione di trigger con un tipo di filtro push e un tipo di filtro pull request](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/example-trigger-filters-pushpluspullrequest.png) Di seguito è riportato l'esempio JSON per la configurazione. ``` "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "branches": { "includes": [ "main" ], "excludes": [ "feature-branch", "feature-branch-2" ] }, "filePaths": { "includes": [ "README.md" ], "excludes": [ "LICENSE.txt" ] } } ], "pullRequest": [ { "events": [ "CLOSED", "OPEN" ], "branches": { "includes": [ "feature-branch" ], "excludes": [ "feature-branch-2", "main" ] } } ] } } ] }, ``` **Example 4: Un trigger con due tipi di filtri push con inclusione ed esclusione in conflitto** L'immagine seguente mostra un tipo di filtro push che specifica di filtrare in base al tag `release-1` (incluso). Viene aggiunto un secondo tipo di filtro push specificando di filtrare in base al ramo `main` (incluso) e di non avviare un push ai `feature*` rami (escluso). Per l'esempio seguente: + Inserendo una release dal tag `release-1` (incluso per il primo filtro push) sul `feature-branch` ramo (escluso come `feature*` per il secondo filtro push) si attiverà la pipeline perché i due tipi di filtro push utilizzano un'operazione OR tra di loro e il primo filtro push (tag`release-1`) corrisponde. + Premendo una release dal `main` ramo (inclusa nel secondo filtro Push) si avvierà la pipeline. L'esempio seguente della pagina Modifica mostra i due tipi di filtro Push e la loro configurazione per le inclusioni e le esclusioni. ![Un esempio di configurazione di trigger con un tipo di filtro push che include il tag release-1 e un tipo di filtro push che include il ramo main* ed esclude i rami feature*](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/example-trigger-filters-pushtags-pushbranches.png) Di seguito è riportato l'esempio JSON per la configurazione. ``` "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "tags": { "includes": [ "release-1" ] } }, { "branches": { "includes": [ "main*" ], "excludes": [ "feature*" ] } } ] } } ] }, ``` **Example 5: Trigger configurato mentre la configurazione di azione predefinita BranchName viene utilizzata per l'avvio manuale** Il `BranchName` campo predefinito di configurazione dell'azione definisce un singolo ramo che verrà utilizzato quando la pipeline viene avviata manualmente, mentre i trigger con filtri possono essere utilizzati per qualsiasi ramo o ramo specificato dall'utente. Di seguito è riportato l'esempio JSON per la configurazione dell'azione che mostra il campo. `BranchName` ``` { "name": "Source", "actions": [ { "name": "Source", "actionTypeId": { "category": "Source", "owner": "AWS", "provider": "CodeStarSourceConnection", "version": "1" }, "runOrder": 1, "configuration": { "BranchName": "main", "ConnectionArn": "ARN", "DetectChanges": "false", "FullRepositoryId": "{{owner-name}}/my-bitbucket-repo", "OutputArtifactFormat": "CODE_ZIP" }, "outputArtifacts": [ { "name": "SourceArtifact" } ], "inputArtifacts": [], "region": "us-west-2", "namespace": "SourceVariables" } ], ``` L'output di azione di esempio seguente mostra che il ramo principale predefinito è stato utilizzato quando la pipeline è stata avviata manualmente. ![Un esempio di pagina di output di azione per una pipeline avviata manualmente](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/example-source-action-manual.png) L'output di azione di esempio seguente mostra la pull request e il branch utilizzati per il trigger quando filtrati tramite pull request. ![Un esempio di pagina di output di azione per una pipeline iniziata con un tipo di filtro Trigger Pull Request](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/example-source-action-pr.png)