Filtrar gatilhos em solicitações push ou pull de código

Você pode configurar filtros para acionadores de pipeline para que as execuções de pipeline sejam iniciadas para diferentes eventos do Git, como push de tag ou branch, alterações em caminhos de arquivo específicos, uma pull request aberta em uma ramificação específica e assim por diante. Você pode usar o AWS CodePipeline console ou os update-pipeline comandos create-pipeline e no AWS CLI para configurar os filtros dos acionadores.

Você pode especificar filtros para os seguintes tipos de gatilho:

• Push

  Um gatilho push inicia um pipeline quando uma alteração é enviada para seu repositório de origem. A execução usará o commit da ramificação para a qual você está enviando (ou seja, a ramificação de destino). Você pode filtrar acionadores push em ramificações, caminhos de arquivo ou tags Git.

• Solicitação de pull

  Um gatilho de pull request inicia um pipeline quando uma pull request é aberta, atualizada ou fechada no seu repositório de origem. A execução usará o commit da ramificação de origem da qual você está extraindo (ou seja, a ramificação de origem). Você pode filtrar acionadores de pull request em ramificações e caminhos de arquivo.

  nota

  Os tipos de eventos compatíveis com pull requests são abertos, atualizados ou fechados (mesclados). Todos os outros eventos de pull request são ignorados.

A definição do pipeline permite combinar filtros diferentes na mesma configuração de push trigger. Para obter detalhes sobre a definição do pipeline, consulteAcione a filtragem no pipeline JSON (CLI). As combinações válidas são:

• tags

• ramos

• ramificações + caminhos de arquivo

Você especifica os tipos de filtro da seguinte forma:

• Sem filtro

  Essa configuração de gatilho inicia seu pipeline em qualquer envio para a ramificação padrão especificada como parte da configuração da ação.

• Especificar filtro

  Você adiciona um filtro que inicia seu pipeline em um filtro específico, como em nomes de ramificações para um envio de código, e busca a confirmação exata. Isso também configura o pipeline para não iniciar automaticamente em nenhuma alteração.

• Não detecte alterações

  Isso não adiciona um gatilho e o pipeline não inicia automaticamente em nenhuma alteração.

A tabela a seguir fornece opções de filtro válidas para cada tipo de evento. A tabela também mostra quais configurações de gatilho são padronizadas como verdadeiras ou falsas para detecção automática de alterações na configuração da ação.

Configurações do gatilho	Tipo de evento	Opções de filtro	Detecte alterações
Adicione um gatilho — sem filtro	nenhuma	nenhuma	verdadeiro
Adicione um gatilho — filtre no envio de código	evento push	Tags, ramificações, caminhos de arquivo do Git	false
Adicionar um gatilho — filtro para pull requests	pull requests	ramificações, caminhos de arquivo	false
Sem gatilho — não detecte	nenhuma	nenhuma	false

nota

Esse tipo de gatilho usa a detecção automática de alterações (como o tipo de Webhook gatilho). Os provedores de ação de origem que usam esse tipo de gatilho são conexões configuradas para envio de código (Bitbucket Cloud GitHub, GitHub Enterprise Server, GitLab .com e GitLab autogerenciadas).

Para filtragem, padrões de expressão regular no formato glob são suportados conforme detalhado em. Trabalhar com padrões glob na sintaxe

nota

Em certos casos, para pipelines com acionadores filtrados em caminhos de arquivo, o pipeline pode não iniciar quando uma ramificação com um filtro de caminho de arquivo é criada pela primeira vez. Para ter mais informações, consulte Pipelines com conexões que usam filtragem de gatilho por caminhos de arquivo podem não começar na criação da ramificação.

Tópicos

• Considerações sobre filtros de gatilho
• Exemplos de filtros de gatilho
• Filtragem de eventos push (console)
• Filtragem em pull requests (console)
• Acione a filtragem no pipeline JSON (CLI)
• Acione a filtragem em modelos AWS CloudFormation

Considerações sobre filtros de gatilho

As considerações a seguir se aplicam ao usar gatilhos.

• Para um gatilho com filtros de ramificação e caminho de arquivo, ao pressionar a ramificação pela primeira vez, o pipeline não será executado, pois não há acesso à lista de arquivos alterados para a ramificação recém-criada.

• A mesclagem de uma pull request pode acionar duas execuções de pipeline, nos casos em que as configurações de gatilhos push (filtro de ramificações) e pull request (filtro de ramificações) se cruzam.

Exemplos de filtros de gatilho

Para uma configuração do Git com filtros para os tipos de eventos push e pull request, os filtros especificados podem entrar em conflito entre si. Veja a seguir exemplos de combinações de filtros válidas para eventos push e pull request.

Quando os clientes combinam filtros em um único objeto de configuração, esses filtros usam uma operação AND, o que significa que somente uma combinação completa iniciará o pipeline. O exemplo a seguir mostra a configuração do Git:

{
  "filePaths": {
    "includes": ["common/**/*.js"]
  },
  "branches": {
    "includes": ["feature/**"]
  }
}

Com a configuração do Git acima, este exemplo mostra um evento que iniciará a execução do pipeline porque a operação AND foi bem-sucedida.

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

Este exemplo mostra um evento que não iniciará a execução do pipeline porque a ramificação é capaz de filtrar, mas o caminho do arquivo não.

{
   "ref": "refs/heads/feature/triggers",
  ...
  "commits": [
    {
      ...
      "modified": [
        "src/Main.java"
      ]
      ...
    }
  ]
}

Ao mesmo tempo, objetos de configuração de gatilho dentro da matriz push usam uma operação OR. Isso permite que você configure vários gatilhos para iniciar a execução no mesmo pipeline. Para obter uma lista de definições de campo na estrutura JSON, consulteAcione a filtragem no pipeline JSON (CLI).