Filtra i trigger nelle richieste push o pull di codice

Puoi configurare i filtri per i trigger della pipeline per avviare le esecuzioni della pipeline per diversi eventi Git, come tag o branch push, modifiche a percorsi di file specifici, una richiesta pull aperta in un ramo specifico e così via. Puoi usare la AWS CodePipeline console o i update-pipeline comandi create-pipeline and in AWS CLI per configurare i filtri dei trigger.

È possibile specificare filtri per i seguenti tipi di trigger:

• Push

  Un push trigger avvia una pipeline quando una modifica viene inviata al repository di origine. L'esecuzione utilizzerà il commit dal ramo verso cui stai inviando il push (ovvero il ramo di destinazione). Puoi filtrare i trigger push su rami, percorsi di file o tag Git.

• Richiesta pull

  Un trigger di pull request avvia una pipeline quando una pull request viene aperta, aggiornata o chiusa nel repository di origine. L'esecuzione utilizzerà il commit dal ramo di origine da cui stai estraendo (ovvero il ramo di origine). Puoi filtrare i trigger delle pull request sui rami e sui percorsi dei file.

  Nota

  I tipi di eventi supportati per le richieste pull vengono aperti, aggiornati o chiusi (uniti). Tutti gli altri eventi di pull request vengono ignorati.

La definizione della pipeline consente di combinare diversi filtri all'interno della stessa configurazione push trigger. Per informazioni dettagliate sulla definizione della pipeline, vedere. Filtraggio dei trigger nella pipeline JSON (CLI) Le combinazioni valide sono:

• tags

• rami

• rami + percorsi di file

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.

• 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 il filtraggio, sono supportati i modelli di espressioni regolari in formato glob, come descritto in. Lavorare con i modelli a globo nella sintassi

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.

Argomenti

• Considerazioni sui filtri di attivazione
• Esempi di filtri trigger
• Filtraggio in base agli eventi push (console)
• Filtraggio in base alle richieste pull (console)
• Filtraggio dei trigger nella pipeline JSON (CLI)
• Attiva il filtraggio nei modelli AWS CloudFormation

Considerazioni sui filtri di attivazione

Le seguenti considerazioni si applicano all'utilizzo dei trigger.

• 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 dei trigger push (branch filter) e pull request (branch filter) si intersecano.

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.

Quando i clienti combinano filtri all'interno di un singolo oggetto di configurazione, questi filtri utilizzeranno un'operazione AND, il che significa che solo una corrispondenza completa avvierà la pipeline. L'esempio seguente mostra la configurazione Git:

{
  "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.

{
  "ref": "refs/heads/feature/triggers",
  ...
  "commits": [
    {
      ...
      "modified": [
        "common/app.js"
      ]
      ...
    }
  ]
}

Questo esempio mostra un evento 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"
      ]
      ...
    }
  ]
}

Allo stesso tempo, gli oggetti di configurazione trigger all'interno dell'array push utilizzano un'operazione OR. Ciò consente di configurare più trigger per avviare l'esecuzione per la stessa pipeline. Per un elenco delle definizioni dei campi nella struttura JSON, vedi. Filtraggio dei trigger nella pipeline JSON (CLI)