{"meta":{"title":"Acionando um fluxo de trabalho","intro":"Como disparar GitHub Actions fluxos de trabalho automaticamente","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/actions","title":"GitHub Actions"},{"href":"/pt/actions/how-tos","title":"Instruções"},{"href":"/pt/actions/how-tos/write-workflows","title":"Escrever fluxos de trabalho"},{"href":"/pt/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Escolher quando os fluxos de trabalho são executados"},{"href":"/pt/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"Acionar um fluxo de trabalho"}],"documentType":"article"},"body":"# Acionando um fluxo de trabalho\n\nComo disparar GitHub Actions fluxos de trabalho automaticamente\n\n## Pré-requisitos\n\nPara saber mais sobre fluxos de trabalho e o disparo de fluxos de trabalho, confira [Fluxos de trabalho](/pt/actions/concepts/workflows-and-actions/workflows).\n\n## Acionando um fluxo de trabalho a partir de um fluxo de trabalho\n\nQuando você usa o `GITHUB_TOKEN` do repositório para executar tarefas, os eventos acionados pelo `GITHUB_TOKEN` não criarão uma nova execução de fluxo de trabalho, com as seguintes exceções:\n\n* ```\n            Eventos `workflow_dispatch` e `repository_dispatch` sempre criam execuções do fluxo de trabalho.\n  ```\n* ```\n            Eventos `pull_request` com os tipos de atividade `opened`, `synchronize` ou `reopened`: quando um fluxo de trabalho que usa `GITHUB_TOKEN` cria ou atualiza uma pull request, o evento `pull_request` resultante cria execuções do fluxo de trabalho em um estado **aprovação-obrigatória**. O pull request exibe um banner na caixa de merge, e um usuário com acesso de escrita ao repositório pode iniciar as execuções selecionando **Aprovar fluxos de trabalho para execução**. Outros `pull_request` tipos de atividade (como `labeled`, `edited`ou `closed`) não criam execuções de fluxo de trabalho. Isso impede que o fluxo de trabalho recursivo seja executado enquanto ainda permite que os fluxos de trabalho de CI sejam executados em solicitações de pull criadas pela automação. Para obter mais informações sobre como aprovar execuções de fluxo de trabalho, consulte [AUTOTITLE](/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).\n  ```\n\nPara todos os outros eventos, esse comportamento impede que você crie acidentalmente execuções de fluxo de trabalho recursivo. Por exemplo, se uma execução de fluxo de trabalho efetuar push do código usando o `GITHUB_TOKEN` do repositório, um novo fluxo de trabalho não será executado mesmo quando o repositório contiver um fluxo de trabalho configurado para ser executado quando os eventos do `push` ocorrerem. Para obter mais informações, consulte [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/tutorials/authenticate-with-github_token).\n\nSe você quiser disparar um fluxo de trabalho de dentro de uma execução de fluxo de trabalho, poderá usar um GitHub App token de acesso de instalação ou um personal access token em vez de `GITHUB_TOKEN` para disparar eventos que exigem um token. Usar uma dessas alternativas também permite que os fluxos de trabalho sejam executados `pull_request` automaticamente (sem o prompt de aprovação descrito acima) quando a solicitação de pull é criada ou atualizada pela automação.\n\nSe você usar um GitHub App, precisará criar um GitHub App e armazenar o ID do aplicativo e a chave privada como segredos. Para saber mais, confira [Fazer solicitações de API autenticadas com um aplicativo GitHub em um fluxo de trabalho GitHub Actions](/pt/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). Se você usar um personal access token, precisará criar um personal access token e armazená-lo como um segredo. Para obter mais informações sobre como criar um personal access token, consulte [Gerenciar seus tokens de acesso pessoal](/pt/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Para saber mais sobre como armazenar segredos, confira [Usar segredos em ações do GitHub](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nPara minimizar os GitHub Actions custos de uso, verifique se você não cria execuções de fluxo de trabalho recursivas ou não intencionais.\n\nPor exemplo, o fluxo de trabalho a seguir usa um personal access token (armazenado como um segredo chamado `MY_TOKEN`) para adicionar um rótulo a um problema por meio de GitHub CLI. Todos os fluxos de trabalho que forem executados quando uma etiqueta é adicionada, serão executados assim que esta etapa for executada.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\nPor outro lado, o fluxo de trabalho a seguir usa `GITHUB_TOKEN` para adicionar um rótulo a um problema. Ele não acionará nenhum fluxo de trabalho executado quando uma etiqueta é adicionada.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## Usando eventos para acionar fluxos de trabalho\n\nUse a chave `on` para especificar os eventos que disparam o fluxo de trabalho. Para obter mais informações sobre os eventos que podem ser usados, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Usando um evento único\n\nPor exemplo, um fluxo de trabalho com o seguinte valor `on` será executado quando um push for feito em qualquer branch no repositório do fluxo de trabalho:\n\n```yaml\non: push\n```\n\n### Usando eventos múltiplos\n\nÉ possível especificar um único evento ou vários eventos. Por exemplo, um fluxo de trabalho com o valor `on` a seguir será executado quando um push for feito em qualquer branch no repositório ou quando alguém criar um fork do repositório:\n\n```yaml\non: [push, fork]\n```\n\nSe você especificar vários eventos, apenas um desses eventos deverá ocorrer para acionar seu fluxo de trabalho. Se vários eventos de acionamento para o seu fluxo de trabalho ocorrerem ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas.\n\n### Usando tipos de atividade e filtros com vários eventos\n\nÉ possível usar tipos de atividade e filtros para controlar ainda mais quando o fluxo de trabalho será executado. Para obter mais informações, confira [Como usar tipos de atividade de evento](#using-event-activity-types) e [Como usar filtros](#using-filters). Se você especificar tipos de atividade ou filtros para um evento e seu fluxo de trabalho for acionado em vários eventos, você deverá configurar cada evento separadamente. Você deve acrescentar dois-pontos (`:`) a todos os eventos, incluindo eventos sem configuração.\n\nPor exemplo, um fluxo de trabalho com o seguinte valor `on` será executado quando:\n\n* Uma etiqueta foi criada\n* Um push for feito para o branch `main` no repositório\n* Um push é feito para um branch habilitado para GitHub Pages\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## Usando tipos de atividade do evento\n\nAlguns eventos têm tipos de atividade que oferecem mais controle sobre quando o fluxo de trabalho deve ser executado. Use `on.<event_name>.types` para definir o tipo de atividade de evento que vai disparar uma execução de fluxo de trabalho.\n\nPor exemplo, o evento `issue_comment` tem os tipos de atividades `created`, `edited` e `deleted`. Se o seu fluxo de trabalho for acionado pelo evento `label`, ele será executado sempre que uma etiqueta for criada, editada ou excluída. Se você especificar o tipo de atividade `created` para o evento `label`, o fluxo de trabalho será executado quando um rótulo for criado, mas não quando um rótulo for editado ou excluído.\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\nSe você especificar vários tipos de atividades, apenas um desses tipos de atividade deverá ocorrer para acionar o fluxo de trabalho. Se vários tipos de atividade do evento de acionamento ocorrer em seu fluxo de trabalho ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas. Por exemplo, o fluxo de trabalho a seguir é acionado quando um problema é aberto ou rotulado. Se um problema com duas etiquetas for aberta, serão iniciadas três execuções de fluxos de trabalho: uma para o problema aberto e duas para os dois problemas etiquetados.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\nPara obter mais informações sobre cada evento e os respectivos tipos de atividade, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Usando filtros\n\nAlguns eventos têm filtros que dão mais controle sobre quando seu fluxo de trabalho deve ser executado.\n\nPor exemplo, o evento `push` tem um filtro `branches` que faz com que seu fluxo de trabalho seja executado somente quando ocorrer um push para um branch que corresponde ao filtro `branches`, em vez de quando ocorrer qualquer push.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### Usando filtros para focar em branches específicos para eventos de pull request\n\nAo usar os eventos `pull_request` e `pull_request_target`, você pode configurar um fluxo de trabalho para ser executado somente para solicitações de pull direcionadas a branches específicos.\n\nUse o filtro `branches` quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro `branches-ignore` quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros `branches` e `branches-ignore` para o mesmo evento em um fluxo de trabalho.\n\nSe você definir `branches`/`branches-ignore` e [`paths`/`paths-ignore`](/pt/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.\n\nAs palavras-chave `branches` e `branches-ignore` aceitam padrões glob que usam caracteres como `*`, `**`, `+`, `?`, `!` e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com `\\`. Para saber mais sobre padrões glob, confira o [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Exemplo: Incluindo ramificações\n\nOs padrões definidos em `branches` são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento `pull_request` para uma solicitação de pull direcionada a:\n\n* Uma ramificação chamada `main` (`refs/heads/main`)\n* Uma ramificação chamada `mona/octocat` (`refs/heads/mona/octocat`)\n* Um branch cujo nome começa com `releases/`, como `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nSe um fluxo de trabalho for ignorado devido à filtragem de ramificação, à [filtragem de caminho](/pt/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) ou a uma [mensagem de confirmação](/pt/actions/how-tos/manage-workflow-runs/skip-workflow-runs), as verificações associadas a esse fluxo de trabalho permanecerão no estado \"Pendente\". Uma solicitação de pull que exige que essas verificações sejam bem-sucedidas não poderá ser mesclada.\n\n#### Exemplo: Excluir branches\n\nQuando um padrão corresponder ao padrão `branches-ignore`, o fluxo de trabalho não será executado. Os padrões definidos em `branches-ignore` são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento `pull_request`, a menos que a solicitação de pull seja direcionada a:\n\n* Um branch chamado `mona/octocat` (`refs/heads/mona/octocat`)\n* Um branch cujo nome corresponde a `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n#### Exemplo: Incluindo e excluindo branches\n\nNão é possível usar `branches` e `branches-ignore` para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro `branches` com o caractere `!` para indicar os branches que devem ser excluídos.\n\nSe você definir um branch com o caractere `!`, também precisará definir, pelo menos, um branch sem o caractere `!`. Caso deseje apenas excluir os branches, use `branches-ignore`.\n\nA ordem na qual você define os padrões é importante.\n\n* Um padrão de correspondência negativa (precedido por `!`) após uma correspondência positiva excluirá a referência do Git.\n* Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.\n\nO fluxo de trabalho a seguir será executado em eventos `pull_request` para solicitações de pull direcionadas a `releases/10` ou `releases/beta/mona`, mas não para solicitações de pull direcionadas a `releases/10-alpha` ou `releases/beta/3-alpha`, porque o padrão `!releases/**-alpha` negativo segue o padrão positivo. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Usando filtros para destinar eventos de push a branches ou tags específicas\n\nAo usar o evento `push`, você pode configurar um fluxo de trabalho para ser executado em marcas ou em branches específicos.\n\nUse o filtro `branches` quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro `branches-ignore` quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros `branches` e `branches-ignore` para o mesmo evento em um fluxo de trabalho.\n\nUse o filtro `tags` quando quiser incluir padrões de nomes de marcas ou quando quiser incluir e excluir padrões de nomes de marcas. Use o filtro `tags-ignore` quando quiser excluir apenas padrões de nomes de marcas. Não é possível usar os filtros `tags` e `tags-ignore` para o mesmo evento em um fluxo de trabalho.\n\nSe você definir apenas `tags`/`tags-ignore` or apenas `branches`/`branches-ignore`, o fluxo de trabalho não será executado para eventos que afetam o Git ref indefinido. Se você não definir `tags`/`tags-ignore` nem `branches`/`branches-ignore`, o fluxo de trabalho será executado para eventos que afetam seus branches ou rótulos. Se você definir `branches`/`branches-ignore` e [`paths`/`paths-ignore`](/pt/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.\n\nAs palavras-chave `branches`, `branches-ignore`, `tags` e `tags-ignore` aceitam padrões glob que usam caracteres como `*`, `**`, `+`, `?`, `!` e outros para corresponder a mais de um nome de marca ou de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, *faça escape* de cada um desses caracteres especiais com `\\`. Para obter mais informações sobre padrões glob, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Exemplo: Incluindo ramificações e etiquetas\n\nOs padrões definidos em `branches` e `tags` são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento `push` para:\n\n* Um branch chamado `main` (`refs/heads/main`)\n* Um branch chamado `mona/octocat` (`refs/heads/mona/octocat`)\n* Um branch cujo nome começa com `releases/`, como `releases/10` (`refs/heads/releases/10`)\n* Uma marca chamada `v2` (`refs/tags/v2`)\n* Uma marca cujo nome começa com `v1.`, como `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n#### Exemplo: Excluindo branches e tags\n\nQuando um padrão corresponder ao padrão `branches-ignore` ou `tags-ignore`, o fluxo de trabalho não será executado. Os padrões definidos em `branches` e `tags` são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento `push`, a menos que o evento `push` seja para:\n\n* Um branch chamado `mona/octocat` (`refs/heads/mona/octocat`)\n* Um branch cujo nome corresponde a `releases/**-alpha`, como `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* Uma marca chamada `v2` (`refs/tags/v2`)\n* Uma marca cujo nome começa com `v1.`, como `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n#### Exemplo: Incluindo e excluindo branches e tags\n\nNão é possível usar `branches` e `branches-ignore` para filtrar o mesmo evento em um fluxo de trabalho individual. Da mesma forma, não é possível usar `tags` e `tags-ignore` para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de branch para um evento individual, use o filtro `branches` ou `tags` com o caractere `!` para indicar as marcas ou os branches que devem ser excluídos.\n\nSe você definir um branch com o caractere `!`, também precisará definir, pelo menos, um branch sem o caractere `!`. Caso deseje apenas excluir os branches, use `branches-ignore`. Da mesma forma, se você definir uma marca com o caractere `!`, também precisará definir, pelo menos, uma marca sem o caractere `!`. Caso deseje apenas excluir as marcas, use `tags-ignore`.\n\nA ordem na qual você define os padrões é importante.\n\n* Um padrão de correspondência negativa (precedido por `!`) após uma correspondência positiva excluirá a referência do Git.\n* Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.\n\nO fluxo de trabalho a seguir será executado em pushes para `releases/10` ou `releases/beta/mona`, mas não em `releases/10-alpha` ou `releases/beta/3-alpha` porque o padrão `!releases/**-alpha` negativo vem após o padrão positivo. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Usando filtros para especificar caminhos específicos para eventos de pull request ou de push\n\nAo usar os eventos `push` e `pull_request`, você pode configurar um fluxo de trabalho para ser executado com base nos caminhos de arquivo alterados. Os filtros de caminho não são avaliados em envios de tags.\n\nUse o filtro `paths` quando quiser incluir padrões de caminho de arquivo ou quando quiser incluir e excluir padrões de caminho de arquivo. Use o filtro `paths-ignore` quando quiser apenas excluir padrões de caminho de arquivo. Não é possível usar os filtros `paths` e `paths-ignore` para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro `paths` prefixado o caractere `!` para indicar os caminhos que devem ser excluídos.\n\n> \\[!NOTE]\n> A ordem de definição dos padrões `paths` é importante:\n>\n> * Um padrão negativo correspondente (prefixado com `!`) após uma correspondência positiva excluirá o caminho.\n> * Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.\n\nSe você definir `branches`/`branches-ignore` e `paths`/`paths-ignore`, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.\n\nAs palavras-chave `paths` e `paths-ignore` aceitam padrões glob que usam os caracteres curinga `*` e `**` para fazer a correspondência com mais de um nome de caminho. Para obter mais informações, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Exemplo: Incluindo caminhos\n\nSe, pelo menos, um caminho corresponder a um padrão no filtro `paths`, o fluxo de trabalho será executado. Por exemplo, o fluxo de trabalho a seguir será executado sempre que você efetuar push de um arquivo JavaScript (`.js`).\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nSe um fluxo de trabalho for ignorado devido à filtragem de caminho, [à filtragem de ramificação](/pt/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ou a uma [mensagem de confirmação](/pt/actions/how-tos/manage-workflow-runs/skip-workflow-runs), as verificações associadas a esse fluxo de trabalho permanecerão no estado \"Pendente\". Uma solicitação de pull que exige que essas verificações sejam bem-sucedidas não poderá ser mesclada.\n\n#### Exemplo: Excluindo caminhos\n\nQuando todos os nomes de caminho corresponderem aos padrões de `paths-ignore`, o fluxo de trabalho não será executado. Se qualquer nome de caminho não corresponder aos padrões de `paths-ignore`, mesmo que alguns nomes de caminho correspondam aos padrões, o fluxo de trabalho será executado.\n\nUm fluxo de trabalho com o filtro de caminho a seguir só será executado em eventos `push` que incluem, pelo menos, um arquivo fora do diretório `docs` na raiz do repositório.\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n#### Exemplo: Incluindo e excluindo caminhos\n\nNão é possível usar `paths` e `paths-ignore` para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro `paths` prefixado o caractere `!` para indicar os caminhos que devem ser excluídos.\n\nSe você definir um caminho com o caractere `!`, também precisará definir, pelo menos, um caminho sem o caractere `!`. Caso você deseje apenas excluir os caminhos, use `paths-ignore`.\n\nA ordem de definição dos padrões `paths` é importante:\n\n* Um padrão de correspondência negativa (precedido por `!`) após uma correspondência positiva excluirá o caminho do Git.\n* Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.\n\nEste exemplo é executado sempre que o evento `push` inclui um arquivo no diretório `sub-project` ou nos respectivos subdiretórios, a menos que o arquivo esteja no diretório `sub-project/docs`. Por exemplo, um push que alterar `sub-project/index.js` ou `sub-project/src/index.js` vai disparar uma execução de fluxo de trabalho, mas um push que só altera `sub-project/docs/readme.md` não.\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n#### Comparações de Git diff\n\nO filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e executando-os na lista `paths-ignore` ou `paths`. Se não houver arquivos alterados, o fluxo de trabalho não será executado.\n\nGitHub gera a lista de arquivos alterados usando diferenças de dois pontos para pushes e diferenças de três pontos para pull requests:\n\n* **Pull requests:** as comparações de três pontos são uma comparação entre a versão mais recente da ramificação do tópico e a confirmação em que a ramificação do tópico foi sincronizado pela última vez com a ramificação base.\n* **Pushes ramificações existentes:** uma comparação de dois pontos compara os SHAs principal e base diretamente um com o outro.\n* **Pushes para novas ramificações:** uma comparação de dois pontos com o pai do ancestral da confirmação mais profunda enviada por push.\n\nEm algumas situações, GitHub Actions aplica limites que alteram a forma como os fluxos de trabalho filtrados são executados:\n\n* Se um push contiver mais de 1.000 confirmações, o fluxo de trabalho **sempre** será executado.\n* Se a geração da diferença atingir o tempo limite, o fluxo de trabalho **sempre** será executado.\n* Se o diff gerado contiver mais de 3.000 arquivos e os arquivos aos quais o filtro do fluxo de trabalho corresponde não estiverem entre os primeiros 3.000 retornados pelo filtro, o fluxo de trabalho **não** será executado.\n\nSe você observar esses comportamentos, talvez seja necessário tornar seus filtros mais específicos ou mudar a forma como você trabalha com pushes e pull requests para gerar diffs mais simples.\n\nPara saber mais, confira [Branches](/pt/pull-requests/reference/branches).\n\n### Usando filtros para direcionar branches específicos para eventos de execução de fluxo de trabalho\n\nAo usar o evento `workflow_run`, você pode especificar em quais ramificações o fluxo de trabalho acionador deve ser executado para acionar seu fluxo de trabalho.\n\nOs filtros `branches` e `branches-ignore` aceitam padrões glob que usam caracteres como `*`, `**`, `+`, `?`, `!` e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, *faça escape* de cada um desses caracteres especiais com `\\`. Para saber mais sobre padrões glob, confira o [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\nPor exemplo, um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado `Build` for executado em um branch cujo nome começa com `releases/`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\nUm fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado `Build` for executado em um branch que não seja chamado `canary`:\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\nNão é possível usar os filtros `branches` e `branches-ignore` para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro `branches` com o caractere `!` para indicar os branches que devem ser excluídos.\n\nA ordem na qual você define os padrões é importante.\n\n* Um padrão negativo correspondente (prefixado com `!`), após uma correspondência positiva, excluirá a ramificação.\n* Um padrão positivo correspondente após uma correspondência negativa incluirá o branch novamente.\n\nPor exemplo, um fluxo de trabalho com o gatilho a seguir será executado quando o fluxo de trabalho chamado `Build` for executado em uma ramificação chamada `releases/10` ou `releases/beta/mona`, mas não `releases/10-alpha`, `releases/beta/3-alpha` ou `main`. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## Definindo entradas para fluxos de trabalho acionados manualmente\n\nAo usar o evento `workflow_dispatch`, opcionalmente, você pode especificar as entradas que são transmitidas para o fluxo de trabalho.\n\nEsse gatilho só recebe eventos quando o arquivo de fluxo de trabalho está na ramificação padrão.\nO fluxo de trabalho disparado recebe os dados de entrada no contexto `inputs`. Para obter mais informações, confira [Contextos](/pt/actions/reference/workflows-and-actions/contexts#inputs-context).\n\n> \\[!NOTE]\n>\n> * O fluxo de trabalho também receberá as entradas no contexto de `github.event.inputs`. As informações no contexto `inputs` e no contexto `github.event.inputs` são idênticas, exceto que o contexto `inputs` preserva valores boolianos como boolianos em vez de convertê-los em cadeias de caracteres. O tipo `choice` é resolvido para uma cadeia de caracteres e é uma única opção selecionável.\n> * O número máximo de propriedades de nível superior é `inputs` 25 .\n> * O conteúdo máximo para `inputs` é de 65.535 caracteres.\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## Definindo entradas, saídas e segredos para fluxos de trabalho reutilizáveis\n\nÉ possível definir entradas e segredos que um fluxo de trabalho reutilizável deve receber de um fluxo de trabalho chamado. Também é possível especificar saídas que um fluxo de trabalho reutilizável disponibilizará para um fluxo de trabalho chamado. Para saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n\n## Usando informações do evento\n\nAs informações sobre o evento que disparou uma execução de fluxo de trabalho estão disponíveis no contexto `github.event`. As propriedades no contexto `github.event` dependem do tipo de evento que disparou o fluxo de trabalho. Por exemplo, um fluxo de trabalho acionado quando um problema está etiquetado teria informações sobre o problema e a etiqueta.\n\n### Visualizando todas as propriedades de um evento\n\nConsulte a documentação sobre eventos de webhook para propriedades comuns e exemplos de cargas. Para saber mais, confira [Eventos e cargas de webhook](/pt/webhooks/webhook-events-and-payloads).\n\nImprima também o contexto `github.event` inteiro para ver quais propriedades estão disponíveis para o evento que disparou seu fluxo de trabalho:\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### Acessando e usando as propriedades do evento\n\nUse o contexto `github.event` no fluxo de trabalho. Por exemplo, o fluxo de trabalho a seguir é executado quando uma solicitação de pull que altera `package*.json`, `.github/CODEOWNERS` ou `.github/workflows/**` é aberta. Se o autor do pull request (`github.event.pull_request.user.login`) não for `octobot` nem `dependabot[bot]`, o fluxo de trabalho usará o GitHub CLI para rotular e comentar no pull request (`github.event.pull_request.number`).\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'\n```\n\nPara obter mais informações sobre contextos, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts). Para obter mais informações sobre payloads de eventos, confira [Eventos e cargas de webhook](/pt/webhooks/webhook-events-and-payloads).\n\n## Controlando ainda mais como seu fluxo de trabalho será executado\n\nSe você quiser um controle mais granular do que o fornecido por eventos, tipos de atividade do evento ou filtros de evento, use condicionais e ambientes para controlar se trabalhos ou etapas individuais serão executados no fluxo de trabalho.\n\n### Usando condicionais\n\nVocê pode usar condicionais para controlar ainda mais se os trabalhos ou etapas no seu fluxo de trabalho serão executados.\n\n#### Exemplo de uso de um valor na carga do evento\n\nPor exemplo, caso você deseje que o fluxo de trabalho seja executado quando um rótulo específico for adicionado a um problema, dispare o tipo de atividade do evento `issues labeled` e use um condicional para verificar qual rótulo disparou o fluxo de trabalho. O fluxo de trabalho a seguir será executado quando qualquer rótulo for adicionado a um problema no repositório do fluxo de trabalho, mas o trabalho `run_if_label_matches` só será executado se o rótulo for chamado `bug`.\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### Exemplo de uso do tipo de evento\n\nPor exemplo, se você deseja executar diferentes tarefas ou etapas, dependendo de qual evento acionou o fluxo de trabalho, você poderá usar uma condicional para verificar se um tipo de evento específico existe no contexto do evento. O fluxo de trabalho seguinte será executado sempre que um problema ou pull request for fechado. Se o fluxo de trabalho tiver sido executado porque um problema foi fechado, o contexto `github.event` conterá um valor para `issue`, mas não para `pull_request`. Portanto, a etapa `if_issue` será executada, mas a etapa `if_pr` não. Por outro lado, se o fluxo de trabalho for executado porque uma solicitação de pull foi fechada, a etapa `if_pr` será executada, mas a etapa `if_issue` não será executada.\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\nPara obter mais informações sobre as informações que estão disponíveis no contexto do evento, confira [Como usar as informações do evento](#using-event-information). Para obter mais informações sobre como usar condicionais, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\n### Usando ambientes para acionar trabalhos de fluxo de trabalho manualmente\n\nSe você quiser acionar manualmente uma tarefa específica em um fluxo de trabalho, você pode usar um ambiente que exige a aprovação de uma equipe ou usuário específico. Primeiro, configure um ambiente com os revisores necessários. Para saber mais, confira [Gerenciar ambientes para implantação](/pt/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Em seguida, referencie o nome do ambiente em um trabalho no fluxo de trabalho usando a chave `environment:`. Qualquer trabalho que faz referência ao ambiente não será executado até que pelo menos um revisor aprove o trabalho.\n\nPor exemplo, o seguinte fluxo de trabalho será executado sempre que houver um push para o principal. O trabalho `build` sempre será executado. O trabalho `publish` só será executado depois que o trabalho `build` for concluído com sucesso (devido a `needs: [build]`) e depois de todas as regras (incluindo os revisores obrigatórios) para o ambiente chamado `production` forem aprovadas (devido a `environment: production`).\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> Ambientes, segredos de ambiente e regras de proteção para implantações estão disponíveis em repositórios públicos para todos os planos atuais GitHub . Eles não estão disponíveis em planos antigos, como Bronze, Prata ou Ouro. Para acesso a ambientes, segredos de ambiente e ramificações de implantação em repositórios privados ou internos, você deve usar GitHub Pro, GitHub Team, ou GitHub Enterprise.\n> Se você estiver em um GitHub Free, GitHub Proou GitHub Team plano, outras regras de proteção de implantação, como um temporizador de espera ou revisores necessários, só estarão disponíveis para repositórios públicos.\n\n## Eventos disponíveis\n\nPara obter uma lista completa de eventos disponíveis, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows)."}