As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Automatizar a inicialização de pipelines usando gatilhos e filtragem Os gatilhos permitem configurar o pipeline para iniciar em um determinado tipo de evento ou tipo de evento filtrado, como quando uma alteração em uma ramificação específica ou solicitação pull é detectada. Os acionadores são configuráveis para ações de origem com conexões que usam a `CodeStarSourceConnection` ação em CodePipeline GitHub, como Bitbucket e. GitLab Para ter mais informações sobre ações de origem que usam conexões, consulte [Adicionar provedores de origem de terceiros usando CodeConnections](pipelines-connections.md). As ações de origem, como CodeCommit e S3, usam a detecção automática de alterações para iniciar os pipelines quando uma alteração é feita. Para obter mais informações, consulte [CodeCommit ações de origem e EventBridge](triggering.md). Você especifica gatilhos usando o console ou a CLI. Você especifica os tipos de filtro da seguinte forma: + **Sem filtro** Esta configuração de gatilho inicia o pipeline em qualquer envio para a ramificação padrão especificada como parte da configuração da ação. + **Especificar filtro** Adicione um filtro que inicia o pipeline em um filtro específico, como em nomes de ramificações para um push de código, e busca a confirmação exata. Isso também configura o pipeline para não iniciar automaticamente em nenhuma alteração. + **Push** + As combinações de filtro válidas são: + **Tags do Git** Incluir ou excluir + **filiais** Incluir ou excluir + **ramificações \$1 caminhos de arquivo** Incluir ou excluir + **Solicitação pull** + As combinações de filtro válidas são: + **filiais** Incluir ou excluir + **ramificações \$1 caminhos de arquivo** Incluir ou excluir + **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 | Detectar alterações | | --- | --- | --- | --- | | Adicionar um gatilho: sem filtro | nenhuma | nenhuma | true | | Adicionar um gatilho: filtro no envio de código | evento push | Etiquetas Git, ramificações, caminhos de arquivo | false | | Adicionar um gatilho: filtro para solicitações pull | solicitações pull | ramificações, caminhos de arquivo | false | | Sem gatilho: não detectar | nenhuma | nenhuma | false | **nota** Este tipo de gatilho usa detecção automatizada de alterações (como o tipo de gatilho `Webhook`). 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 obter definições de campo e referência adicional para acionadores, consulte Para conferir uma lista de definições de campo na estrutura JSON, consulte [`triggers`](pipeline-requirements.md#pipeline.triggers). Para filtragem, padrões de expressão regular no formato glob são compatíveis conforme detalhado em [Trabalhar com padrões glob na sintaxe](syntax-glob.md). **nota** Em certos casos, para pipelines com gatilhos filtrados por caminhos de arquivos, o pipeline pode não iniciar quando uma ramificação com um filtro de caminho de arquivo é criada pela primeira vez. Para obter mais informações, consulte [Pipelines configurados com conexões que filtram gatilhos por caminhos de arquivos podem falhar ao iniciar durante a criação da ramificação.](troubleshooting.md#troubleshooting-file-paths-filtering). ## Considerações sobre filtros de gatilho As seguintes considerações se aplicam ao usar gatilhos. + Você não pode adicionar mais de um acionador por ação de origem. + Você pode adicionar vários tipos de filtro a um acionador. Para ver um exemplo, consulte [4: um acionador com dois tipos de filtro push com inclusões e exclusões conflitantes](#example-filter-multiple-push). + Em gatilhos com filtros de ramificação e caminhos de arquivos, ao enviar a ramificação pela primeira vez, o pipeline não será acionado devido à indisponibilidade da lista de arquivos alterados na nova ramificação. + A mesclagem de um pull request pode acionar duas execuções de pipeline, nos casos em que as configurações de acionador push (filtro de ramificações) e pull request (filtro de ramificações) se cruzam. + Para um filtro que acione o pipeline em eventos pull request, para o tipo de evento pull request Fechado, o provedor de repositório de terceiros da conexão pode ter um status à parte para um evento de mesclagem. Por exemplo, no Bitbucket, o evento Git de uma mesclagem não é um evento de encerramento pull request. No entanto, em GitHub, mesclar uma pull request é um evento de encerramento. Para obter mais informações, consulte [Eventos pull request para acionadores por provedor](#pipelines-filter-pullrequest-events). ## Eventos pull request para acionadores por provedor A tabela a seguir apresenta um resumo dos eventos do Git, como o encerramento de pull request, que resultem em tipos de evento pull request por provedor. **** | | Provedor de repositório para a conexão | Evento PR para acionador | Bitbucket | GitHub | GHES | GitLab | | --- | --- | --- | --- | --- | --- | --- | | Abrir: esta opção aciona o pipeline quando uma pull request é criada para o caminho de ramificação/arquivo. | A criação de um pull request resulta em um evento do Git Aberto. | A criação de um pull request resulta em um evento do Git Aberto. | A criação de um pull request resulta em um evento do Git Aberto. | A criação de um pull request resulta em um evento do Git Aberto. | | Atualizar: esta opção aciona o pipeline quando uma revisão pull request é publicada para o caminho de ramificação/arquivo. | A publicação de uma atualização resulta em um evento do Git Atualizado. | A publicação de uma atualização resulta em um evento do Git Atualizado. | A publicação de uma atualização resulta em um evento do Git Atualizado. | A publicação de uma atualização resulta em um evento do Git Atualizado. | | Fechado - Essa opção aciona o pipeline quando uma pull request é fechada para o branch/file caminho. | A mesclagem de uma pull request no Bitbucket resulta em um evento do Git Fechado. Importante: o fechamento manual de uma pull request no Bitbucket sem mesclar não resulta em um evento do Git Fechado. | A mesclagem ou o fechamento manual de uma pull request resulta em um evento do Git Fechado. | A mesclagem ou o fechamento manual de uma pull request resulta em um evento do Git Fechado. | A mesclagem ou o fechamento manual de uma pull request resulta em um evento do Git Fechado. | ## Exemplos de filtros de gatilho Para uma configuração do Git com filtros para os tipos de eventos push e solicitação pull, os filtros especificados podem entrar em conflito entre si. Veja a seguir exemplos de combinações de filtros válidas para eventos push e solicitação pull. Um acionador pode conter vários tipos de filtro, como dois tipos de filtro push na configuração do acionador, e os tipos de filtro push e pull request usarão uma operação OR entre eles, o que significa que qualquer correspondência iniciará o pipeline. Da mesma forma, cada tipo de filtro pode incluir vários filtros, como filePaths e ramificações; esses filtros usarão um operador AND, o que significa que somente uma correspondência completa iniciará o pipeline. Cada tipo de filtro pode conter inclusões e exclusões, onde as exclusões têm precedência sobre as inclusões. Se uma ramificação ou caminho de arquivo corresponder a um padrão de exclusão, ele não acionará o pipeline, mesmo que também corresponda a um padrão de inclusão. Quando um commit altera vários arquivos, cada arquivo é avaliado de forma independente em relação ao filtro; se algum arquivo alterado for aprovado (corresponder a uma inclusão e não corresponder a uma exclusão), o pipeline será iniciado. Os nomes dentro da inclusão/exclusão, como nomes de ramificação, usam uma operação OR. A lista a seguir resume as operações de cada parte do objeto de configuração do Git. Para obter uma lista de definições de campo na estrutura JSON e uma referência detalhada para inclusões e exclusões, consulte [`triggers`](pipeline-requirements.md#pipeline.triggers). **Example 1: um tipo de filtro com filtros para ramificações e caminhos de arquivo (operação AND)** Para um único tipo de filtro, como pull request, você pode combinar filtros e esses filtros usarão um operador AND, o que significa que somente uma correspondência completa iniciará o pipeline. O exemplo a seguir mostra uma configuração do Git para um tipo de evento push com dois filtros diferentes (`filePaths` e `branches`). No exemplo a seguir, `filePaths` será usado com o operador E e com `branches`: ``` { "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 o uso do operador E foi bem-sucedido. Em outras palavras, o caminho do arquivo `common/app.js` é incluído para o filtro, que inicia o pipeline como AND mesmo que a ramificação `refs/heads/feature/triggers ` especificada não tenha tido impacto. ``` { "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "common/app.js" ] ... } ] } ``` O exemplo a seguir mostra um evento de um acionador com a configuração acima que não iniciará a execução do pipeline porque a ramificação consegue filtrar, mas o caminho do arquivo não. ``` { "ref": "refs/heads/feature/triggers", ... "commits": [ { ... "modified": [ "src/Main.java" ] ... } ] } ``` **Example 2: As exclusões têm precedência sobre as inclusões** Em um único filtro, as exclusões têm precedência sobre as inclusões. O exemplo a seguir mostra uma configuração do Git com um único filtro (`branches`) dentro do objeto de configuração. Isso significa que se uma ramificação corresponder a um padrão de exclusão (`feature-branch`no exemplo), o pipeline não será acionado, mesmo que também corresponda a um padrão de inclusão. Se o padrão de inclusão corresponder e nenhum padrão de exclusão corresponder, como para a `main` ramificação, o pipeline será acionado. Para o seguinte JSON de exemplo: + O envio de uma confirmação para a ramificação `main` acionará o pipeline + O envio de uma confirmação para a ramificação `feature-branch` não acionará o pipeline. ``` { "branches": { "Includes": [ "main" ], "Excludes": [ "feature-branch" ] } ``` **Example 3: Um gatilho com tipos de filtro de solicitação push e pull (operação OR), filtros para caminhos e ramificações de arquivos (operação AND) e includes/excludes (as excluições têm precedência)** Os objetos de configuração do acionador, como um acionador que contém um tipo de evento push e um tipo de evento pull request, usam uma operação OR entre os dois tipos de evento. O exemplo a seguir mostra uma configuração de acionador com um tipo de evento push com a ramificação `main` incluída e um tipo de evento pull request com a mesma ramificação `main` excluída. Além disso, o tipo de evento push tem um caminho de arquivo `LICENSE.txt` excluído e um caminho de arquivo `README.MD` incluído. Para o segundo tipo de evento, uma pull request que está na ramificação `Closed` ou `Created` na `feature-branch` ramificação (incluída) inicia o pipeline, e o pipeline não inicia ao criar ou fechar uma pull request na ramificação `feature-branch-2` ou nas `main` ramificações (excluídas). Dentro de cada tipo de evento, as exclusões têm precedência sobre as inclusões. Por exemplo, para um evento de pull request na `feature-branch` ramificação (incluído na pull request), o tipo de evento push exclui a `feature-branch` ramificação, portanto, o push não acionará o pipeline. Para o exemplo a seguir, + O envio de uma confirmação para a ramificação `main` (incluída) do caminho do arquivo `README.MD` (incluído) acionará o pipeline. + Na ramificação `feature-branch` (excluída), o envio de uma confirmação não acionará o pipeline. + Na ramificação incluída, a edição do caminho do arquivo `README.MD` (incluído) aciona o pipeline. + Na ramificação incluída, editar somente o caminho do `LICENSE.TXT` arquivo (excluído) não aciona o pipeline. No entanto, se o mesmo commit também mudar `README.MD` (incluído), o pipeline será acionado porque cada arquivo é avaliado de forma independente. + Na `feature-branch` ramificação, fechar uma pull request acionará o pipeline porque `feature-branch` está incluído no tipo de evento do pull request e no tipo de evento CLOSED corresponde. A imagem a seguir mostra a configuração. ![\[Uma configuração do acionador de exemplo com um tipo de filtro push e um tipo de filtro pull request\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/example-trigger-filters-pushpluspullrequest.png) Este é o JSON exemplo da configuração. ``` "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: um acionador com dois tipos de filtro push com inclusões e exclusões conflitantes** A imagem a seguir mostra um tipo de filtro push especificando o filtro na tag `release-1` (incluída). Um segundo tipo de filtro por push é adicionado especificando a filtragem na ramificação `main` (incluída) e não iniciar um envio por push para as ramificações `feature*` (excluídas). Para o seguinte exemplo: + Pressionar uma liberação da etiqueta `release-1` (incluída para o primeiro filtro de pressão) na `feature-branch` ramificação (excluída do segundo filtro de pressão) acionará a tubulação porque os dois tipos de filtro de pressão usam uma operação OR entre eles e o primeiro filtro de pressão (etiqueta`release-1`) corresponde. `feature*` + O envio por push uma liberação da ramificação `main` (incluída para o segundo filtro Push) iniciará o pipeline. O exemplo a seguir da página Editar mostra os dois tipos de filtros push e as configurações para inclusões e exclusões. ![\[Uma configuração de acionador de exemplo com um tipo de filtro push que inclui a tag release-1 e um tipo de filtro push que inclui a ramificação principal* e exclui as ramificações feature*\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/example-trigger-filters-pushtags-pushbranches.png) Este é o JSON exemplo da configuração. ``` "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "tags": { "includes": [ "release-1" ] } }, { "branches": { "includes": [ "main*" ], "excludes": [ "feature*" ] } } ] } } ] }, ``` **Example 5: Acionador configurado enquanto a configuração de ação padrão BranchName é usada para uma inicialização manual** O campo `BranchName` padrão de configuração da ação define uma única ramificação que será usada quando o pipeline for iniciado manualmente, e os gatilhos com filtros podem ser usados para qualquer ramificação ou ramificações especificadas por você. Este é o JSON de exemplo para a configuração de ação que mostra o 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" } ], ``` A saída da ação de exemplo a seguir mostra que a ramificação principal padrão foi usada quando o pipeline foi iniciado manualmente. ![\[Uma página da saída de ação de exemplo para um pipeline iniciado manualmente\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/example-source-action-manual.png) A saída da ação de exemplo a seguir mostra a pull request e a ramificação que foi usada para o acionador quando filtrado por pull request. ![\[Uma página de saída da ação de exemplo para um pipeline iniciado com um tipo de filtro pull request acionador\]](http://docs.aws.amazon.com/pt_br/codepipeline/latest/userguide/images/example-source-action-pr.png) # Adicionar gatilho em code push sem filtro Os gatilhos permitem configurar o pipeline para iniciar em um determinado tipo de evento, como code push ou pull request. Os acionadores são configuráveis para ações de origem com conexões que usam a CodeStarSourceConnection ação em CodePipeline GitHub, como Bitbucket e. GitLab **Adição de um gatilho (console)** 1. Faça login no Console de gerenciamento da AWS e abra o CodePipeline console em [http://console.aws.amazon. com/codesuite/codepipeline/home](https://console.aws.amazon.com/codesuite/codepipeline/home). Os nomes e o status de todos os pipelines associados à sua AWS conta são exibidos. 1. Em **Nome**, selecione o nome do pipeline que você deseja editar. Caso contrário, use essas etapas no assistente de criação de pipeline. 1. Na página de detalhes do pipeline, selecione **Editar**. 1. Na página **Editar**, escolha a ação de origem que você deseja editar. Escolha **Editar gatilhos**. Opte por adicionar um acionador. 1. Em **Tipo de acionador**, escolha **Sem filtro**. # Adicionar gatilho com tipos de eventos code push ou pull request Você pode configurar filtros para gatilhos de pipeline para que as execuções de pipeline sejam iniciadas para diferentes eventos Git, como push de etiqueta ou ramificação, alterações em caminhos de arquivo específicos, uma solicitação pull 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 filtros de gatilho. **nota** O campo `BranchName` de configuração da ação define uma única ramificação, e os gatilhos com filtros podem ser usados para qualquer ramificação ou ramificações especificadas por você. Para um pipeline no qual os gatilhos sejam usados para filtrar ramificações por push ou pull request, o pipeline não usará a ramificação do campo `BranchName` padrão na configuração da ação. No entanto, a ramificação no campo `BranchName` na configuração da ação é o padrão quando o pipeline é iniciado manualmente. Para ver um exemplo, consulte [5: Acionador configurado enquanto a configuração de ação padrão BranchName é usada para uma inicialização manual](pipelines-triggers.md#example-filter-default-manual). Você pode especificar filtros para os seguintes tipos de gatilho: + **Push** Um gatilho push inicia um pipeline quando uma alteração é enviada ao repositório de origem. A execução usará a confirmação da ramificação *para* a qual você está enviando (ou seja, a ramificação de destino). Você pode filtrar gatilho push em ramificações, caminhos de arquivos ou etiquetas Git. + **Solicitação pull** Um gatilho de solicitação pull inicia um pipeline quando uma solicitação pull é aberta, atualizada ou fechada no repositório de origem. A execução usará a confirmação da ramificação de origem *da qual* você está extraindo (ou seja, a ramificação de origem). Você pode filtrar gatilhos de solicitação pull em ramificações e caminhos de arquivo. Os tipos de evento compatíveis para pull requests são os seguintes. Todos os outros eventos de solicitação pull são ignorados. + Aberto + Atualização + Fechado (mesclado) **nota** Determinados comportamentos do evento pull request podem mudar de acordo com o provedor. Para obter detalhes, consulte [Eventos pull request para acionadores por provedor](pipelines-triggers.md#pipelines-filter-pullrequest-events). A definição do pipeline permite combinar filtros diferentes na mesma configuração de push de gatilho. Para saber mais sobre a definição do pipeline, consulte [Adicionar filtros para tipos de evento push e pull request (CLI)](#pipelines-filter-cli). Para obter uma lista das definições de campo, consulte [gatilhos](pipeline-requirements.md#pipeline.triggers) na *referência de estrutura do Pipeline* neste guia. **Topics** + [Adicione filtros para tipos de evento push e pull request (console)](#pipelines-filter-console) + [Adicionar filtros para tipos de evento push e pull request (CLI)](#pipelines-filter-cli) + [Adicione filtros para tipos de eventos push e pull request (CloudFormation modelos)](#pipelines-filter-cfn) ## Adicione filtros para tipos de evento push e pull request (console) Você pode usar o console para adicionar filtros para eventos push e incluir ou excluir ramificações ou caminhos de arquivo. **Adicionar filtros (console)** 1. Faça login no Console de gerenciamento da AWS e abra o CodePipeline console em [http://console.aws.amazon. com/codesuite/codepipeline/home](https://console.aws.amazon.com/codesuite/codepipeline/home). Os nomes e o status de todos os pipelines associados à sua AWS conta são exibidos. 1. Em **Nome**, selecione o nome do pipeline que você deseja editar. Caso contrário, use essas etapas no assistente de criação de pipeline. 1. Na página de detalhes do pipeline, selecione **Editar**. 1. Na página **Editar**, escolha a ação de origem que você deseja editar. Escolha **Editar gatilhos**. Escolha **Especificar filtro**. 1. Em **Tipo de evento**, escolha **Push** entre as opções a seguir. + Escolha **Push** para iniciar o pipeline quando uma alteração for enviada para o repositório de origem. Essa escolha permite que os campos especifiquem filtros para ramificações e caminhos de arquivo ou etiquetas Git. + Escolha **Solicitação pull** para iniciar o pipeline quando uma solicitação pull for aberta, atualizada ou fechada no repositório de origem. Essa escolha permite que os campos especifiquem filtros para ramificações de destino e caminhos de arquivo. 1. Em **Push**, em **Tipo de filtro**, escolha uma das opções a seguir. + Escolha **Ramificação** para especificar as ramificações no repositório de origem que o gatilho monitora para saber quando iniciar a execução de um fluxo de trabalho. Em **Incluir**, insira padrões para nomes de ramificações no formato glob que você deseja especificar para a configuração do gatilho a fim de iniciar o pipeline em alterações nas ramificações especificadas. Em **Excluir**, insira os padrões de regex para nomes de ramificações no formato glob que você deseja especificar para a configuração do gatilho ignorar e não iniciar seu pipeline em alterações nas ramificações especificadas. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. **nota** Se a inclusão e a exclusão tiverem o mesmo padrão de etiqueta, o padrão será excluído. Você pode usar padrões glob para definir os nomes das ramificações. Por exemplo, use `main*` para combinar todas as ramificações que começam com `main`. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. Para um gatilho de push, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Para um gatilho de solicitação pull, especifique as ramificações de destino para as quais você está abrindo a solicitação pull. + (Opcional) Em **Caminhos de arquivo**, especifique caminhos de arquivo para o gatilho. Insira os nomes em **Incluir** e **Excluir**, conforme apropriado. Você pode usar padrões glob para definir os nomes de caminhos de arquivos. Por exemplo, use `prod*` para combinar todos os caminhos de arquivo que começam com `prod`. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. + Selecione **Etiquetas** a fim de configurar o gatilho do pipeline para começar com etiquetas Git. Em **Incluir**, insira padrões para nomes de etiquetas no formato glob que você deseja especificar para a configuração do gatilho a fim de iniciar o pipeline na liberação das etiquetas especificadas. Em **Excluir**, insira os padrões de regex para nomes de etiquetas no formato glob que você deseja especificar para a configuração do gatilho ignorar e não iniciar o pipeline na liberação das etiquetas especificadas. Se a inclusão e a exclusão tiverem o mesmo padrão de tag, o padrão será excluir o padrão de tag. 1. Em **Push**, em **Tipo de filtro**, escolha uma das opções a seguir. + Escolha **Ramificação** para especificar as ramificações no repositório de origem que o gatilho monitora para saber quando iniciar a execução de um fluxo de trabalho. Em **Incluir**, insira padrões para nomes de ramificações no formato glob que você deseja especificar para a configuração do gatilho a fim de iniciar o pipeline em alterações nas ramificações especificadas. Em **Excluir**, insira os padrões de regex para nomes de ramificações no formato glob que você deseja especificar para a configuração do gatilho ignorar e não iniciar seu pipeline em alterações nas ramificações especificadas. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. **nota** Se a inclusão e a exclusão tiverem o mesmo padrão de etiqueta, o padrão será excluído. Você pode usar padrões glob para definir os nomes das ramificações. Por exemplo, use `main*` para combinar todas as ramificações que começam com `main`. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. Para um gatilho de push, especifique as ramificações *para* as quais você está enviando, ou seja, as ramificações de *destino*. Para um gatilho de solicitação pull, especifique as ramificações de destino para as quais você está abrindo a solicitação pull. + (Opcional) Em **Caminhos de arquivo**, especifique caminhos de arquivo para o gatilho. Insira os nomes em **Incluir** e **Excluir**, conforme apropriado. Você pode usar padrões glob para definir os nomes de caminhos de arquivos. Por exemplo, use `prod*` para combinar todos os caminhos de arquivo que começam com `prod`. Consulte [Trabalhar com padrões glob na sintaxe](syntax-glob.md) para obter mais informações. + Escolha **Solicitação de pull** para definir a configuração de gatilho do pipeline para começar por eventos pull request especificados por você. ## Adicionar filtros para tipos de evento push e pull request (CLI) Você pode atualizar o JSON do pipeline para adicionar filtros para gatilhos. Para usar o AWS CLI para criar ou atualizar seu pipeline, use o `update-pipeline` comando `create-pipeline` or. O exemplo de estrutura JSON a seguir fornece uma referência para as definições de campo em `create-pipeline`. Para obter uma lista das definições de campo, consulte [gatilhos](pipeline-requirements.md#pipeline.triggers) na *referência de estrutura do Pipeline* neste guia. ``` { "pipeline": { "name": "MyServicePipeline", "triggers": [ { "provider": "Connection", "gitConfiguration": { "sourceActionName": "ApplicationSource", "push": [ { "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] }, "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "tags": { "includes": [ "release-v0", "release-v1" ], "excludes": [ "release-v2" ] } } ], "pullRequest": [ { "events": [ "CLOSED" ], "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] } } ] } } ], "stages": [ { "name": "Source", "actions": [ { "name": "ApplicationSource", "configuration": { "BranchName": "mainline", "ConnectionArn": "arn:aws:codestar-connections:eu-central-1:111122223333:connection/fe9ff2e8-ee25-40c9-829e-65f8EXAMPLE", "FullRepositoryId": "monorepo-example", "OutputArtifactFormat": "CODE_ZIP" } } ] } ] } } ``` ## Adicione filtros para tipos de eventos push e pull request (CloudFormation modelos) Você pode atualizar o recurso de pipeline CloudFormation para adicionar a filtragem de gatilho. O trecho de modelo de exemplo a seguir fornece uma referência YAML para definições de campos de gatilhos. Para obter uma lista das definições de campo, consulte [gatilhos](pipeline-requirements.md#pipeline.triggers) na *referência de estrutura do Pipeline* neste guia. Para ver um exemplo completo de modelo para uma configuração de fonte de conexão e filtro de gatilho, consulte [Pipeline com dois estágios e configuração de gatilho](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-pipeline.html#aws-resource-codepipeline-pipeline--examples--Pipeline_with_two_stages_and_trigger_configuration) no *Guia CloudFormation do usuário*. ``` pipeline: name: MyServicePipeline executionMode: PARALLEL triggers: - provider: CodeConnection gitConfiguration: sourceActionName: ApplicationSource push: - filePaths: includes: - projectA/** - common/**/*.js excludes: - '**/README.md' - '**/LICENSE' - '**/CONTRIBUTING.md' branches: includes: - feature/** - release/** excludes: - mainline - tags: includes: - release-v0 - release-v1 excludes: - release-v2 pullRequest: - events: - CLOSED branches: includes: - feature/** - release/** excludes: - mainline filePaths: includes: - projectA/** - common/**/*.js excludes: - '**/README.md' - '**/LICENSE' - '**/CONTRIBUTING.md' stages: - name: Source actions: - name: ApplicationSource configuration: BranchName: mainline ConnectionArn: arn:aws:codestar-connections:eu-central-1:111122223333:connection/fe9ff2e8-ee25-40c9-829e-65f85EXAMPLE FullRepositoryId: monorepo-example OutputArtifactFormat: CODE_ZIP ``` # Adicionar acionador para desativar a detecção de alterações Os gatilhos permitem configurar o pipeline para iniciar em um determinado tipo de evento, como code push ou pull request. Os gatilhos são configuráveis ​​para ações de origem com conexões que usam a ação `CodeStarSourceConnection` no CodePipeline, como GitHub, Bitbucket e GitLab. **Adição de um acionador para desativar a detecção de alterações (console)** 1. Faça login no Console de gerenciamento da AWS e abra o console do CodePipeline em [http://console.aws.amazon.com/codesuite/codepipeline/home](https://console.aws.amazon.com/codesuite/codepipeline/home). Os nomes e status de todos os pipelines associados à sua conta da AWS são exibidos. 1. Em **Nome**, selecione o nome do pipeline que você deseja editar. Caso contrário, use essas etapas no assistente de criação de pipeline. 1. Na página de detalhes do pipeline, selecione **Editar**. 1. Na página **Editar**, escolha a ação de origem que você deseja editar. Escolha **Editar gatilhos**. Opte por adicionar um acionador. 1. Em **Tipo de acionador**, escolha **Não detectar alterações**.