{"meta":{"title":"Sintaxe de fluxo de trabalho para o GitHub Actions","intro":"Um fluxo de trabalho é um processo automatizado configurável constituído de um ou mais trabalhos. Você deve criar um arquivo YAML para definir a configuração do seu fluxo de trabalho.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/actions","title":"GitHub Actions"},{"href":"/pt/actions/reference","title":"Referência"},{"href":"/pt/actions/reference/workflows-and-actions","title":"Fluxos de trabalho e ações"},{"href":"/pt/actions/reference/workflows-and-actions/workflow-syntax","title":"Sintaxe de fluxo de trabalho"}],"documentType":"article"},"body":"# Sintaxe de fluxo de trabalho para o GitHub Actions\n\nUm fluxo de trabalho é um processo automatizado configurável constituído de um ou mais trabalhos. Você deve criar um arquivo YAML para definir a configuração do seu fluxo de trabalho.\n\n## Sobre sintaxe YAML para fluxos de trabalho\n\nOs arquivos de fluxo de trabalho usam a sintaxe YAML e precisam ter uma extensão de arquivo `.yml` ou `.yaml`. Se você não estiver familiarizado com o YAML e quiser saber mais, confira [Aprenda a usar o YAML em Y minutos](https://learnxinyminutes.com/docs/yaml/).\n\nVocê precisa armazenar os arquivos de fluxo de trabalho no diretório `.github/workflows` do repositório.\n\n> \\[!TIP]\n> Ao contrário dos fluxos de trabalho tradicionais GitHub Actions que exigem que você crie script de todas as decisões como etapas de trabalho yaml, GitHub Agentic Workflows use o frontmatter yaml para gatilhos e configuração, mas permita descrever o que você deseja no Markdown em linguagem natural, para que você não precise prever e codificar todos os cenários com antecedência. Para saber mais, confira [Criando fluxos de trabalho agênticos do GitHub](/pt/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows).\n\n## `name`\n\nNome do fluxo de trabalho. O GitHub exibe os nomes dos fluxos de trabalho na guia \"Ações\" do repositório. Se você omitir `name`, o GitHub exibirá o caminho do arquivo de fluxo de trabalho em relação à raiz do repositório.\n\n## `run-name`\n\nO nome das execuções de fluxo de trabalho geradas pelo fluxo de trabalho.\nGitHub exibe o nome da execução do fluxo de trabalho na lista de execuções de fluxo de trabalho na guia \"Ações\" do repositório. Se `run-name` for omitido ou for apenas espaço em branco, o nome da execução será definido como informações específicas do evento para a execução do fluxo de trabalho. Por exemplo, para um fluxo de trabalho disparado por um evento `push` ou `pull_request`, ele é definido como a mensagem do commit ou o título da pull request.\n\nEsse valor pode incluir expressões e referenciar os contextos [`github`](/pt/actions/reference/workflows-and-actions/contexts#github-context) e [`inputs`](/pt/actions/reference/workflows-and-actions/contexts#inputs-context).\n\n### Exemplo de `run-name`\n\n```yaml\nrun-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}\n```\n\n## `on`\n\nPara disparar automaticamente um fluxo de trabalho, use `on` para definir os eventos que podem fazer com que o fluxo de trabalho seja executado. Para obter uma lista de eventos disponíveis, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\nVocê pode definir um ou vários eventos que possam disparar um fluxo de trabalho ou definir um cronograma. Também é possível restringir a execução de um fluxo de trabalho para que ocorra apenas para arquivos, tags ou alterações em branches específicos. Essas opções são descritas nas seções a seguir.\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\n\nAlguns eventos têm tipos de atividade que oferecem mais controle sobre quando o fluxo de trabalho deve ser executado. Use `on..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 tipos de atividade e filtros com vários eventos\n\nSe 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## `on..types`\n\nUse `on..types` para definir o tipo de atividade que vai disparar uma execução de fluxo de trabalho. A maioria dos eventos GitHub são acionados por mais de um tipo de atividade. Por exemplo, o `label` é disparado quando um rótulo é `created`, `edited` ou `deleted`. A palavra-chave `types` permite restringir a atividade que faz com que o fluxo de trabalho seja executado. Quando apenas um tipo de atividade dispara um evento de webhook, a palavra-chave `types` é desnecessária.\n\nVocê pode usar uma matriz de eventos `types`. Para obter mais informações sobre cada evento e seus tipos de atividade, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n```yaml\non:\n label:\n types: [created, edited]\n```\n\n## `on..`\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 branches\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`) \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. \n\n```yaml\non:\n pull_request:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.push.`\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 branches e tags\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`) \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. \n\n```yaml\non:\n push:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on..`\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 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## `on.schedule`\n\nUse `on.schedule` para definir um agendamento de tempo para seus fluxos de trabalho.\n\nUse a [sintaxe cron POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) para agendar fluxos de trabalho para serem executados em horários específicos.\nPor padrão, fluxos de trabalho agendados são executados em UTC. Opcionalmente, você pode especificar um fuso horário usando uma cadeia de [caracteres de fuso horário IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) para agendamento. Fluxos de trabalho agendados são executados sobre o último commit no branch padrão. O intervalo mais curto que você pode executar fluxos de trabalho agendados é a cada 5 minutos.\n\n> \\[!NOTE]\n> Para agendamentos que definem `timezone` em um fuso horário que observa o horário de verão, durante as transições de adiantamento do horário de verão, fluxos de trabalho agendados durante as horas não contabilizadas avançam para o próximo horário válido. Por exemplo, um horário agendado para as 2h30 avança para as 3h00.\n\nA sintaxe cron tem cinco campos separados por um espaço, e cada campo representa uma unidade de tempo.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nVocê pode usar estes operadores em qualquer um dos cinco campos:\n\n| Operador | Descrição | Exemplo |\n| -------------------------------------------------------------------------------------------------- | ----------------------------- | ------- |\n| \\* | Qualquer valor | |\n| `15 * * * *` é executado no minuto 15 de cada hora todos os dias. | | |\n| , | Separador de valores em lista | |\n| `2,10 4,5 * * *` é executado nos minutos 2 e 10 da quarta e da quinta hora todos os dias. | | |\n| - | Intervalo de valores | |\n| `30 4-6 * * *` é executado no minuto 30 da 4ª, 5ª e 6ª hora. | | |\n| / | Valores de etapa | |\n| `20/15 * * * *` é executado a cada 15 minutos, começando do minuto 20 ao 59 (minutos 20, 35 e 50). | | |\n\nEste exemplo inicia o fluxo de trabalho para ser executado às 5h30, no fuso horário América/New\\_York, de segunda a sexta-feira.\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1-5'\n timezone: \"America/New_York\"\n```\n\nUm fluxo de trabalho individual pode ser disparado por vários eventos `schedule`. Acesse o evento `schedule` que disparou o fluxo de trabalho por meio do contexto `github.event.schedule`. Este exemplo dispara o fluxo de trabalho para ser executado às 5:30 UTC toda segunda-feira a quinta-feira e às 17:30 UTC às terças e quintas-feiras, mas ignora a etapa `Not on Monday or Wednesday` na segunda-feira e na quarta-feira.\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1,3'\n - cron: '30 5,17 * * 2,4'\n\njobs:\n test_schedule:\n runs-on: ubuntu-latest\n steps:\n - name: Not on Monday or Wednesday\n if: github.event.schedule != '30 5 * * 1,3'\n run: echo \"This step will be skipped on Monday and Wednesday\"\n - name: Every time\n run: echo \"This step will always run\"\n```\n\nPara saber mais sobre eventos `schedule`, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## `on.workflow_call`\n\nUse `on.workflow_call` para definir as entradas e as saídas de um fluxo de trabalho reutilizável. Você também pode mapear os segredos disponíveis para o fluxo de trabalho chamado. Para obter mais informações sobre os fluxos de trabalho reutilizáveis, consulte [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.inputs`\n\nAo usar a palavra-chave `workflow_call`, você poderá, opcionalmente, especificar as entradas que são transmitidas para o fluxo de trabalho chamado do fluxo de trabalho de chamada. Para obter mais informações sobre a palavra-chave `workflow_call`, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call).\n\nAlém dos parâmetros de entrada padrão disponíveis, `on.workflow_call.inputs` exige um parâmetro `type`. Para obter mais informações, consulte [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype).\n\nSe um parâmetro `default` não estiver definido, o valor padrão da entrada será `false` para um booliano, `0` para um número e `\"\"` para uma cadeia de caracteres.\n\nNo fluxo de trabalho chamado, você pode usar o contexto `inputs` para se referir a uma entrada. Para saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts#inputs-context).\n\nSe um fluxo de trabalho de chamada passar uma entrada que não é especificada no fluxo de trabalho de chamada, isso irá gerar um erro.\n\n### Exemplo de `on.workflow_call.inputs`\n\n```yaml\non:\n workflow_call:\n inputs:\n username:\n description: 'A username passed from the caller workflow'\n default: 'john-doe'\n required: false\n type: string\n\njobs:\n print-username:\n runs-on: ubuntu-latest\n\n steps:\n - name: Print the input name to STDOUT\n run: echo The username is ${{ inputs.username }}\n```\n\nPara saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.inputs..type`\n\nObrigatório se a entrada for definida para a palavra-chave `on.workflow_call`. O valor deste parâmetro é uma string que especifica o tipo de dados da entrada. Precisa ser `boolean`, `number` ou `string`.\n\n## `on.workflow_call.outputs`\n\nUm mapa de saídas para um fluxo de trabalho chamado. As saídas de fluxo de trabalho chamadas estão disponíveis para todas as tarefas a jusante no fluxo de trabalho de chamadas. Cada saída tem um identificador, uma `description,` opcional e um `value.`. O `value` precisa ser definido como o valor de uma saída de um trabalho no fluxo de trabalho chamado.\n\nNo exemplo abaixo, duas saídas são definidas para esse fluxo de trabalho reutilizável: `workflow_output1` e `workflow_output2`. Elas são mapeadas para as saídas chamadas `job_output1` e `job_output2`, ambas de um trabalho chamado `my_job`.\n\n### Exemplo de `on.workflow_call.outputs`\n\n```yaml\non:\n workflow_call:\n # Map the workflow outputs to job outputs\n outputs:\n workflow_output1:\n description: \"The first job output\"\n value: ${{ jobs.my_job.outputs.job_output1 }}\n workflow_output2:\n description: \"The second job output\"\n value: ${{ jobs.my_job.outputs.job_output2 }}\n```\n\nPara obter informações sobre como referenciar uma saída de trabalho, consulte [`jobs..outputs`](#jobsjob_idoutputs). Para saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `on.workflow_call.secrets`\n\nUm mapa dos segredos que pode ser usado no fluxo de trabalho de chamada.\n\nNo fluxo de trabalho chamado, você pode usar o contexto `secrets` para se referir a um segredo.\n\n> \\[!NOTE]\n> Nota: se você estiver passando o segredo para um fluxo de trabalho aninhado reutilizável, deverá usar [`jobs..secrets`](#jobsjob_idsecrets) novamente para passar o segredo. Para saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows#passing-secrets-to-nested-workflows).\n\nSe um fluxo de trabalho de chamada passar um segredo que não é especificado no fluxo de trabalho chamado, isso irá gerar um erro.\n\n### Exemplo de `on.workflow_call.secrets`\n\n```yaml\non:\n workflow_call:\n secrets:\n access-token:\n description: 'A token passed from the caller workflow'\n required: false\n\njobs:\n\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n # passing the secret to an action\n - name: Pass the received secret to an action\n uses: ./.github/actions/my-action\n with:\n token: ${{ secrets.access-token }}\n\n # passing the secret to a nested reusable workflow\n pass-secret-to-workflow:\n uses: ./.github/workflows/my-workflow\n secrets:\n token: ${{ secrets.access-token }}\n```\n\n## `on.workflow_call.secrets.`\n\nUm identificador de string para associar ao segredo.\n\n## `on.workflow_call.secrets..required`\n\nUm booleano que especifica se o segredo deve ser fornecido.\n\n## `on.workflow_run.`\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`. \n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.workflow_dispatch`\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.\n\n## `on.workflow_dispatch.inputs`\n\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### Exemplo de `on.workflow_dispatch.inputs`\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## `on.workflow_dispatch.inputs..required`\n\nUm booliano que especifica se a entrada precisa ser fornecida.\n\n## `on.workflow_dispatch.inputs..type`\n\nO valor deste parâmetro é uma string que especifica o tipo de dados da entrada. Precisa ser `boolean`, `choice`, `number`, `environment` ou `string`.\n\n## `permissions`\n\nUse `permissions` para modificar as permissões padrão concedidas ao `GITHUB_TOKEN`, adicionando ou removendo o acesso conforme necessário, de modo que você só permita o acesso mínimo necessário. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).\n\nUse `permissions` como uma chave de nível superior a ser aplicada a todos os trabalhos no fluxo de trabalho ou em trabalhos específicos. Quando você adiciona a chave `permissions` a um trabalho específico, todas as ações e os comandos de execução nesse trabalho que usam o `GITHUB_TOKEN` obtêm os direitos de acesso especificados. Para obter mais informações, consulte [`jobs..permissions`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions).\n\nOs proprietários de uma organização podem restringir o acesso de escrita para o `GITHUB_TOKEN` no nível do repositório. Para obter mais informações, consulte [Desabilitando ou limitando GitHub Actions para sua organização](/pt/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization).\n\nQuando um fluxo de trabalho é disparado pelo evento [`pull_request_target`](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target), recebe permissão `GITHUB_TOKEN` de repositório de leitura/gravação, mesmo quando é disparado de uma bifurcação pública. Para saber mais, confira [Eventos que disparam fluxos de trabalho](/pt/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target).\n\nPara cada uma das permissões disponíveis mostradas na tabela abaixo, você pode atribuir um dos níveis de acesso: `read` (se aplicável), `write` ou `none`.\n`write` inclui `read`. Se você especificar o acesso para qualquer uma dessas permissões, todas aquelas que não forem especificadas serão definidas como `none`.\n\nPermissões disponíveis e detalhes do que cada uma permite que uma ação faça:\n\n| Permissão | Permite uma ação que usa `GITHUB_TOKEN` para |\n| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Trabalhar com GitHub Actions. Por exemplo, `actions: write` permite que uma ação cancele uma execução de fluxo de trabalho. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). |\n| | |\n| `artifact-metadata` | Trabalhe com metadados de artefatos. Por exemplo, `artifact-metadata: write` permite que uma ação crie registros de armazenamento em nome de um artefato de build. Para obter mais informações, confira [Pontos de extremidade de API REST para metadados de artefato](/pt/rest/orgs/artifact-metadata?apiVersion=2022-11-28). |\n| | |\n| | |\n| `attestations` | Trabalhar com atestados de artefatos. Por exemplo, `attestations: write` permite que uma ação gere um atestado de artefato para uma criação. Para obter mais informações, confira [Usar atestados de artefatos para estabelecer a procedência de compilações](/pt/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) |\n| | |\n| `checks` | Trabalhar com verificação de execuções e verificação de conjuntos. Por exemplo, `checks: write` permite que uma ação crie uma verificação de execução. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). |\n| | |\n| `code-quality` | Trabalhe com qualidade de código. Por exemplo, `code-quality: write` permite que uma ação carregue relatórios de cobertura de código. Para obter mais informações, confira [Qualidade do Código do GitHub](/pt/code-security/concepts/code-quality/code-quality). |\n| | |\n| `contents` | Trabalhar com o conteúdo do repositório. Por exemplo, `contents: read` permite que uma ação liste os commits e `contents: write` permite que a ação crie uma versão. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). |\n| `deployments` | Trabalhar com implantações. Por exemplo, `deployments: write` permite que uma ação crie uma implantação. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). |\n| `discussions` | Trabalhar com discussões do GitHub. Por exemplo, `discussions: write` permite que uma ação feche ou exclua uma discussão. Para obter mais informações, confira [Usar a API do GraphQL para discussões](/pt/graphql/guides/using-the-graphql-api-for-discussions). |\n| | |\n| `id-token` | Recuperar um token OpenID Connect (OIDC). Isso exige usar `id-token: write`. Para obter mais informações, confira [OpenID Connect](/pt/actions/concepts/security/openid-connect#updating-your-workflows-for-oidc) |\n| | |\n| `issues` | Trabalhar com problemas. Por exemplo, `issues: write` permite que uma ação adicione um comentário a um problema. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). |\n| `packages` | Trabalhar com GitHub Packages. Por exemplo, `packages: write` permite que uma ação carregue e publique pacotes no GitHub Packages. Para obter mais informações, confira [Sobre permissões para o GitHub Packages](/pt/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). |\n| `pages` | Trabalhar com páginas do GitHub. Por exemplo, `pages: write` permite que uma ação solicite um build de GitHub Pages. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). |\n| `pull-requests` | Trabalhar com solicitações de pull. Por exemplo, `pull-requests: write` permite que uma ação adicione um rótulo a uma PR. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). |\n| `security-events` | Trabalhar com alertas de verificação de código do GitHub. Por exemplo, `security-events: read` permite que uma ação liste os alertas da digitalização de código para o repositório e `security-events: write` permite que uma ação atualize o status de um alerta de digitalização de código. Para obter mais informações, consulte [as permissões do Repositório para \"Alertas de verificação de código\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts).

|\n| Para alertas do Dependabot, use a permissão `vulnerability-alerts`. Os alertas de verificação secreta não podem ser lidos com essa permissão e exigem um aplicativo GitHub ou um personal access token. Para obter mais informações, consulte [Permissões de Repositório para \"Alertas de verificação de segredos\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) em \"Permissões necessárias para aplicativos GitHub\". | |\n| `statuses` | Trabalhar com status de commits. Por exemplo, `statuses:read` permite que uma ação liste os status de commit de uma determinada referência. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). |\n| | |\n| `vulnerability-alerts` | Leia os alertas do Dependabot. Por exemplo, `vulnerability-alerts: read` permite que uma ação liste os alertas do Dependabot para o repositório. Somente `read` e `none` há suporte; `write` não é válido. Quando `write-all` ou `read-all` é usado, `vulnerability-alerts` é incluído automaticamente como `read`. Para obter mais informações, consulte [as permissões do Repositório para \"Alertas do Dependabot\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts). |\n| | |\n\n### Definindo o acesso para os escopos do `GITHUB_TOKEN`\n\nVocê pode definir o acesso que o `GITHUB_TOKEN` permitirá especificando `read`, `write` ou `none` como o valor das permissões disponíveis na chave `permissions`.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n code-quality: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nSe você especificar o acesso para uma dessas permissões, todas aquelas que não forem especificadas serão definidas como `none`.\n\nVocê pode usar a sintaxe a seguir para definir o acesso de `read-all` ou `write-all` para todas as permissões disponíveis:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nVocê pode usar a seguinte sintaxe para desabilitar as permissões para todas as permissões disponíveis:\n\n```yaml\npermissions: {}\n```\n\n#### Alterar as permissões em um repositório bifurcado\n\nVocê pode usar a tecla `permissions` para adicionar e remover permissões de leitura de repositórios derivados (forks), mas normalmente não pode conceder acesso de gravação. A exceção a esse comportamento ocorre quando um usuário administrador seleciona a opção **Enviar tokens de gravação para fluxos de trabalho a partir de pull requests** nas GitHub Actions configurações. Para saber mais, confira [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n### Como as permissões são calculadas para um trabalho de fluxo de trabalho\n\nInicialmente, as permissões para o `GITHUB_TOKEN` são definidas como a configuração padrão para a empresa, a organização ou o repositório. Se o padrão for definido como permissões restritas em qualquer um desses níveis, isso irá aplicar-se aos repositórios relevantes. Por exemplo, Se você escolher o padrão restrito no nível da organização, todos os repositórios nessa organização usarão as permissões restritas como padrão. As permissões serão, então, ajustadas com base em qualquer configuração dentro do arquivo de fluxo de trabalho, primeiro no nível de fluxo de trabalho e, em seguida, no nível de trabalho. Por fim, se o fluxo de trabalho foi disparado por um evento de solicitação pull que não seja `pull_request_target` de um repositório com fork e a configuração **Enviar tokens de gravação para fluxos de trabalho por meio de solicitações pull** não está selecionada, as permissões são ajustadas para alterar as permissões de gravação para somente leitura.\n\n### Definir as permissões do `GITHUB_TOKEN` para todos os trabalhos em um fluxo de trabalho\n\nVocê pode especificar `permissions` no nível superior de um fluxo de trabalho para que a configuração se aplique a todos os trabalhos no fluxo de trabalho.\n\n#### Exemplo: definir as permissões do `GITHUB_TOKEN` para um fluxo de trabalho inteiro\n\nEste exemplo mostra as permissões que estão sendo definidas para o `GITHUB_TOKEN` que se aplicará a todos os trabalhos no fluxo de trabalho. É concedido acesso de leitura a todas as permissões.\n\n```yaml\nname: \"My workflow\"\n\non: [ push ]\n\npermissions: read-all\n\njobs:\n ...\n```\n\n### Como usar a chave `permissions` para repositórios bifurcados\n\nAlém disso, você pode usar a chave `permissions` para adicionar e remover permissões de `read` para repositórios com fork, mas normalmente não pode permitir acesso de `write`. A exceção a esse comportamento é quando um usuário administrador selecionou a opção **Enviar tokens de gravação para fluxos de trabalho de solicitações pull** nas configurações do GitHub Actions. Para saber mais, confira [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n### Permissões para execuções de fluxo de trabalho disparadas por Dependabot\n\nAs execuções de fluxo de trabalho disparadas por solicitações de pull Dependabot são executadas como se fossem de um repositório bifurcado e, portanto, usam `GITHUB_TOKEN` somente leitura. Estas execuções de fluxo de trabalho não podem acessar nenhum segredo. Para obter mais informações sobre as estratégias para manter esses fluxos de trabalho seguros, confira [Referência de uso seguro](/pt/actions/reference/security/secure-use).\n\n## `env`\n\nUm `map` das variáveis que estão disponíveis para as etapas de todos os trabalhos do fluxo de trabalho. Também é possível definir variáveis que estão disponíveis apenas para as etapas de um trabalho ou para uma só etapa. Para obter mais informações, consulte [`jobs..env`](#jobsjob_idenv) e [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nAs variáveis no mapa `env` não podem ser definidas em termos de outras variáveis no mapa.\n\nQuando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá as variáveis de ambiente do trabalho e do fluxo de trabalho que tenham o mesmo nome enquanto a etapa é executada. Uma variável de ambiente definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome enquanto o trabalho é executado.\n\n### Exemplo de `env`\n\n```yaml\nenv:\n SERVER: production\n```\n\n## `defaults`\n\nUse `defaults` para criar um `map` com as configurações padrão que se aplicarão a todas as tarefas do fluxo de trabalho. Você também pode definir configurações padrão que estão disponíveis apenas para uma tarefa. Para obter mais informações, confira [`jobs..defaults`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaults).\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `defaults.run`\n\nVocê pode usar `defaults.run` para fornecer as opções `shell` e `working-directory` padrão para todas as etapas do [`run`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) em um fluxo de trabalho. Você também pode definir configurações padrão para `run` as quais só estão disponíveis para um trabalho. Para obter mais informações, confira [`jobs..defaults.run`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun). Você não pode usar contextos ou expressões nesta palavra-chave.\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n### Exemplo: Defina o shell padrão e o diretório de trabalho\n\n```yaml\ndefaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `defaults.run.shell`\n\nUse `shell` para definir o `shell` para uma etapa. Essa palavra-chave pode fazer referência a vários contextos. Para obter mais informações, confira [Contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\n| Plataforma compatível | Parâmetro `shell` | Descrição | Comando executado internamente |\n| --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | não especificado | O shell padrão em plataformas não Windows. Isso executa um comando diferente para quando `bash` é especificado explicitamente. Se `bash` não for encontrado no caminho, isso será tratado como `sh`. | `bash -e {0}` |\n| Tudo | `bash` | O shell padrão em plataformas não Windows com um fallback para `sh`. Ao especificar um shell bash no Windows, é utilizado o shell bash incluído no Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tudo | `pwsh` | Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `pwsh -command \". '{0}'\"` |\n| Tudo | `python` | Executa o comando python. | `python {0}` |\n| Linux / macOS | `sh` | O comportamento de fallback para plataformas não Windows se nenhum shell for fornecido e o `bash` não for encontrado no caminho. | `sh -e {0}` |\n| Windows | `cmd` | O GitHub acrescenta a extensão `.cmd` ao nome do script e a substitui por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Essa é a shell padrão usada no Windows. Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. Se o executor auto-hospedado do Windows não tiver o *PowerShell Core* instalado, o *PowerShell Desktop* será usado. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | O PowerShell Desktop. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `powershell -command \". '{0}'\"`. |\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `defaults.run.working-directory`\n\nUse `working-directory` para definir o diretório de trabalho do `shell` de uma etapa. Essa palavra-chave pode fazer referência a vários contextos. Para obter mais informações, confira [Contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Verifique se o `working-directory` existe no executor antes de executar seu shell nele.\n> Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `concurrency`\n\nUse `concurrency` para garantir que apenas um trabalho ou um fluxo de trabalho que usa o mesmo grupo de simultaneidade seja executado por vez. Um grupo de concorrência pode ser qualquer string ou expressão. A expressão só pode usar os contextos [`github`](/pt/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/pt/actions/reference/workflows-and-actions/contexts#inputs-context) e [`vars`](/pt/actions/reference/workflows-and-actions/contexts#vars-context). Para obter mais informações sobre expressões, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\nVocê também pode especificar `concurrency` no nível do trabalho. Para obter mais informações, confira [`jobs..concurrency`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency).\n\nIsso significa que pode haver no máximo um trabalho ou fluxo de trabalho em execução em um grupo de concorrência a qualquer momento. Quando um trabalho ou um fluxo de trabalho simultâneo é colocado na fila, se outro trabalho ou fluxo de trabalho que usa o mesmo grupo de simultaneidade no repositório estiver em andamento, o trabalho ou o fluxo de trabalho na fila ficará `pending`. Por padrão, qualquer trabalho ou fluxo de trabalho existente `pending` no mesmo grupo de simultaneidade será cancelado e o novo trabalho ou fluxo de trabalho em fila tomará seu lugar.\n\nPara também cancelar qualquer trabalho ou fluxo de trabalho em execução no mesmo grupo de concorrência, especifique `cancel-in-progress: true`. Para cancelar condicionalmente trabalhos ou fluxos de trabalho em execução no mesmo grupo de simultaneidade, é possível especificar `cancel-in-progress` como uma expressão com qualquer um dos contextos de expressão permitidos.\n\nPara permitir que mais de uma tarefa ou execução de fluxo de trabalho aguardem no mesmo grupo de simultaneidade, use a propriedade opcional `queue`. A `queue` propriedade aceita os seguintes valores:\n\n* `single` (padrão): no máximo uma execução de tarefa ou de fluxo de trabalho pode ser `pending` no grupo de simultaneidade. Quando uma nova execução de trabalho ou fluxo de trabalho é enfileirada, qualquer execução existente de trabalho ou fluxo de trabalho `pending` no mesmo grupo é cancelada e substituída.\n* `max`: até 100 trabalhos ou execuções de fluxo de trabalho podem ser incluídos no grupo de simultaneidade. Quando a fila estiver cheia, quaisquer trabalhos adicionais ou execuções de fluxo de trabalho serão cancelados.\n\nA combinação de `queue: max` e `cancel-in-progress: true` não é permitida e resultará em um erro de validação de fluxo de trabalho.\n\n> \\[!NOTE]\n>\n> * O nome do grupo de simultaneidade não diferencia maiúsculas de minúsculas. Por exemplo, `prod` e `Prod` serão tratados como o mesmo grupo de simultaneidade.\n> * Trabalhos ou execuções de fluxo de trabalho no mesmo grupo de simultaneidade são processados na ordem de primeiro a entrar em primeiro lugar (FIFO), de acordo com o momento em que cada um começou a esperar no grupo de simultaneidade, não o tempo em que cada fluxo de trabalho foi expedido. Como o horário de início efetivo de um trabalho ou execução pode variar, a ordenação não é garantida.\n\n### Exemplos: Usar a simultaneidade e o comportamento padrão\n\nO comportamento GitHub Actions padrão é permitir que vários trabalhos ou execuções de fluxo de trabalho sejam executados simultaneamente. A palavra-chave `concurrency` permite controlar a simultaneidade de execuções de fluxo de trabalho.\n\nPor exemplo, você pode usar a palavra-chave `concurrency` imediatamente após a definição das condições de disparo para limitar a simultaneidade de execuções de fluxo de trabalho inteiro para uma ramificação específica:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nVocê também pode limitar a simultaneidade de trabalhos em um fluxo de trabalho usando a palavra-chave `concurrency` no nível do trabalho:\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Exemplo: grupos de concorrência\n\nOs grupos de simultaneidade fornecem uma maneira de gerenciar e limitar a execução de fluxos de trabalho ou tarefas que compartilham a mesma chave de simultaneidade.\n\nA chave `concurrency` é usada para agrupar fluxos de trabalho ou trabalhos em um grupo de simultaneidade. Quando você define uma `concurrency` chave, GitHub Actions garante que apenas um fluxo de trabalho ou trabalho com essa chave seja executado a qualquer momento. Se uma nova execução de fluxo de trabalho ou trabalho começar com a mesma `concurrency` chave, GitHub Actions cancelará qualquer fluxo de trabalho ou trabalho já em execução com essa chave. A chave `concurrency` pode ser uma cadeia de caracteres codificada ou pode ser uma expressão dinâmica que inclui variáveis de contexto.\n\nÉ possível definir condições de concorrência no seu workflow para que o workflow ou tarefa faça parte de um grupo de concorrência.\n\nIsso significa que, quando um fluxo de trabalho for executado ou iniciado, o GitHub cancelará todas as execuções de fluxo de trabalho ou trabalhos que já estejam em andamento no mesmo grupo de simultaneidade. Isso é útil em cenários em que você deseja impedir execuções paralelas para um determinado conjunto de fluxos de trabalho ou trabalhos, como os usados para implantações em um ambiente de preparo, a fim de evitar ações que possam causar conflitos ou consumir mais recursos do que o necessário.\n\nNeste exemplo, `job-1` faz parte de um grupo de simultaneidade chamado `staging_environment`. Isso significa que, se uma nova execução de `job-1` for acionada, todas as execuções do mesmo trabalho no grupo de simultaneidade `staging_environment` que já estiverem em andamento serão canceladas.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nComo alternativa, usar uma expressão dinâmica, como `concurrency: ci-${{ github.ref }}` em seu fluxo de trabalho, significa que o fluxo de trabalho ou trabalho faria parte de um grupo de concorrência chamado `ci-`, seguido pela referência da ramificação ou tag que acionou o fluxo de trabalho. Neste exemplo, se uma nova confirmação for enviada para a ramificação principal enquanto uma execução anterior ainda estiver em andamento, a execução anterior será cancelada e a nova será iniciada:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemplo: Enfileirando várias tarefas pendentes\n\nPor padrão, apenas uma execução de tarefa ou de fluxo de trabalho pode estar `pending` em um grupo de simultaneidade por vez. Para permitir várias execuções na fila em vez de serem canceladas, defina `queue: max`. Com `queue: max`, até 100 trabalhos ou execuções de fluxo de trabalho podem aguardar no grupo de simultaneidade; depois que a fila estiver cheia, quaisquer execuções adicionais são canceladas.\n\nPor exemplo, o fluxo de trabalho a seguir enfileira implantações no ambiente `production`, processando-as uma de cada vez em ordem com base no momento em que cada execução começou a aguardar no grupo de concorrência.\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nObserve que `queue: max` não pode ser combinado com `cancel-in-progress: true`, porque as duas opções descrevem comportamentos conflitantes para lidar com execuções em andamento.\n\n### Exemplo: Usar a concorrência para cancelar qualquer trabalho em andamento ou em execução\n\nPara usar a simultaneidade para cancelar qualquer trabalho em andamento GitHub Actions ou execução, você pode usar a tecla `concurrency` com a opção `cancel-in-progress` definida como `true`:\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nObserve que, neste exemplo, sem definir um grupo de simultaneidade específico, GitHub Actions cancelará a execução de qualquer trabalho ou fluxo de trabalho em andamento.\n\n### Exemplo: Usando um valor para segunda opção\n\nSe você construir o nome do grupo com uma propriedade que só é definida para eventos específicos, você pode usar um valor de segunda opção. Por exemplo, `github.head_ref` só é definido em eventos `pull_request`. Se o fluxo de trabalho responder a outros eventos além de eventos `pull_request`, você precisará fornecer um fallback para evitar um erro de sintaxe. O grupo de simultaneidade a seguir cancela os trabalhos em andamento ou é executado somente em eventos `pull_request`. Se `github.head_ref` for indefinido, o grupo de simultaneidade fará fallback para a ID de execução, que tem a garantia de ser exclusiva e definida para a execução.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Exemplo: Cancele somente tarefas em andamento ou execuções no fluxo de trabalho atual\n\nSe você tiver vários fluxos de trabalho no mesmo repositório, os nomes dos grupos de execução concorrente devem ser únicos em todos os fluxos de trabalho para evitar o cancelamento de tarefas ou execuções em andamento de outros fluxos de trabalho. Caso contrário, qualquer trabalho em andamento ou pendente será cancelado, independentemente do fluxo de trabalho.\n\nPara cancelar apenas as execuções em andamento do mesmo fluxo de trabalho, use a propriedade `github.workflow` para criar o grupo de simultaneidade:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemplo: cancelar apenas trabalhos em andamento em ramificações específicas\n\nSe você quiser cancelar trabalhos em andamento em determinadas ramificações, mas não em outras, poderá usar expressões condicionais com `cancel-in-progress`. Por exemplo, é possível fazer isso se quiser cancelar trabalhos em andamento em branches de desenvolvimento, mas não em branches de lançamento.\n\nPara cancelar apenas execuções em andamento do mesmo fluxo de trabalho quando não estiverem em execução em um branch de lançamento, é possível definir `cancel-in-progress` para uma expressão semelhante à seguinte:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nNeste exemplo, vários envios por push para um branch `release/1.2.3` não cancelariam execuções em andamento. Envios por push para outro branch, como `main`, cancelariam execuções em andamento.\n\n## `jobs`\n\nUma execução de fluxo de trabalho é composta por um ou mais `jobs`, que são executados em paralelo por padrão. Para executar trabalhos sequencialmente, você pode definir dependências em outros trabalhos usando a palavra-chave `jobs..needs`.\n\nCada trabalho é executado em um ambiente do executor especificado por `runs-on`.\n\nVocê pode executar quantos trabalhos desejar, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte [Cobrança e uso](/pt/actions/concepts/billing-and-usage) sobre runners hospedados em GitHub e [Limites do Actions](/pt/actions/reference/limits) para limites de uso de runners auto-hospedados.\n\nSe você precisar encontrar o identificador exclusivo de um trabalho em execução em uma execução de fluxo de trabalho, poderá usar a GitHub API. Para saber mais, confira [Endpoints da API REST para Ações do GitHub](/pt/rest/actions#workflow-jobs).\n\n## `jobs.`\n\nUse `jobs.` para fornecer ao seu trabalho um identificador exclusivo. A chave `job_id` é uma cadeia de caracteres, e o valor dela é um mapa dos dados de configuração do trabalho. Você precisa substituir `` por uma cadeia de caracteres exclusiva para o objeto `jobs`. A `` precisa começar com uma letra ou `_` e conter apenas caracteres alfanuméricos, `-` ou `_`.\n\n### Exemplo: Criando trabalhos\n\nNeste exemplo, dois trabalhos foram criados, e os valores de `job_id` são `my_first_job` e `my_second_job`.\n\n```yaml\njobs:\n my_first_job:\n name: My first job\n my_second_job:\n name: My second job\n```\n\n## `jobs..name`\n\nUse `jobs..name` para definir um nome para o trabalho, que é exibido na interface do usuário do GitHub.\n\n## `jobs..permissions`\n\nPara um trabalho específico, você pode usar `jobs..permissions` para modificar as permissões padrão concedidas ao `GITHUB_TOKEN`, adicionando ou removendo o acesso conforme necessário, para que você permita apenas o acesso mínimo necessário. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).\n\nAo especificar a permissão em uma definição de trabalho, você pode configurar um conjunto diferente de permissões para o `GITHUB_TOKEN` em cada trabalho, se necessário. Como alternativa, você pode especificar as permissões para todas as tarefas do fluxo de trabalho. Para obter informações sobre como definir permissões no nível do fluxo de trabalho, confira [`permissions`](/pt/actions/reference/workflows-and-actions/workflow-syntax#permissions).\n\nPara cada uma das permissões disponíveis mostradas na tabela abaixo, você pode atribuir um dos níveis de acesso: `read` (se aplicável), `write` ou `none`.\n`write` inclui `read`. Se você especificar o acesso para qualquer uma dessas permissões, todas aquelas que não forem especificadas serão definidas como `none`.\n\nPermissões disponíveis e detalhes do que cada uma permite que uma ação faça:\n\n| Permissão | Permite uma ação que usa `GITHUB_TOKEN` para |\n| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Trabalhar com GitHub Actions. Por exemplo, `actions: write` permite que uma ação cancele uma execução de fluxo de trabalho. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions). |\n| | |\n| `artifact-metadata` | Trabalhe com metadados de artefatos. Por exemplo, `artifact-metadata: write` permite que uma ação crie registros de armazenamento em nome de um artefato de build. Para obter mais informações, confira [Pontos de extremidade de API REST para metadados de artefato](/pt/rest/orgs/artifact-metadata?apiVersion=2022-11-28). |\n| | |\n| | |\n| `attestations` | Trabalhar com atestados de artefatos. Por exemplo, `attestations: write` permite que uma ação gere um atestado de artefato para uma criação. Para obter mais informações, confira [Usar atestados de artefatos para estabelecer a procedência de compilações](/pt/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) |\n| | |\n| `checks` | Trabalhar com verificação de execuções e verificação de conjuntos. Por exemplo, `checks: write` permite que uma ação crie uma verificação de execução. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks). |\n| | |\n| `code-quality` | Trabalhe com qualidade de código. Por exemplo, `code-quality: write` permite que uma ação carregue relatórios de cobertura de código. Para obter mais informações, confira [Qualidade do Código do GitHub](/pt/code-security/concepts/code-quality/code-quality). |\n| | |\n| `contents` | Trabalhar com o conteúdo do repositório. Por exemplo, `contents: read` permite que uma ação liste os commits e `contents: write` permite que a ação crie uma versão. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents). |\n| `deployments` | Trabalhar com implantações. Por exemplo, `deployments: write` permite que uma ação crie uma implantação. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments). |\n| `discussions` | Trabalhar com discussões do GitHub. Por exemplo, `discussions: write` permite que uma ação feche ou exclua uma discussão. Para obter mais informações, confira [Usar a API do GraphQL para discussões](/pt/graphql/guides/using-the-graphql-api-for-discussions). |\n| | |\n| `id-token` | Recuperar um token OpenID Connect (OIDC). Isso exige usar `id-token: write`. Para obter mais informações, confira [OpenID Connect](/pt/actions/concepts/security/openid-connect#updating-your-workflows-for-oidc) |\n| | |\n| `issues` | Trabalhar com problemas. Por exemplo, `issues: write` permite que uma ação adicione um comentário a um problema. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues). |\n| `packages` | Trabalhar com GitHub Packages. Por exemplo, `packages: write` permite que uma ação carregue e publique pacotes no GitHub Packages. Para obter mais informações, confira [Sobre permissões para o GitHub Packages](/pt/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). |\n| `pages` | Trabalhar com páginas do GitHub. Por exemplo, `pages: write` permite que uma ação solicite um build de GitHub Pages. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages). |\n| `pull-requests` | Trabalhar com solicitações de pull. Por exemplo, `pull-requests: write` permite que uma ação adicione um rótulo a uma PR. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests). |\n| `security-events` | Trabalhar com alertas de verificação de código do GitHub. Por exemplo, `security-events: read` permite que uma ação liste os alertas da digitalização de código para o repositório e `security-events: write` permite que uma ação atualize o status de um alerta de digitalização de código. Para obter mais informações, consulte [as permissões do Repositório para \"Alertas de verificação de código\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts).

|\n| Para alertas do Dependabot, use a permissão `vulnerability-alerts`. Os alertas de verificação secreta não podem ser lidos com essa permissão e exigem um aplicativo GitHub ou um personal access token. Para obter mais informações, consulte [Permissões de Repositório para \"Alertas de verificação de segredos\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) em \"Permissões necessárias para aplicativos GitHub\". | |\n| `statuses` | Trabalhar com status de commits. Por exemplo, `statuses:read` permite que uma ação liste os status de commit de uma determinada referência. Para obter mais informações, confira [Permissões necessárias para aplicativos GitHub](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses). |\n| | |\n| `vulnerability-alerts` | Leia os alertas do Dependabot. Por exemplo, `vulnerability-alerts: read` permite que uma ação liste os alertas do Dependabot para o repositório. Somente `read` e `none` há suporte; `write` não é válido. Quando `write-all` ou `read-all` é usado, `vulnerability-alerts` é incluído automaticamente como `read`. Para obter mais informações, consulte [as permissões do Repositório para \"Alertas do Dependabot\"](/pt/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts). |\n| | |\n\n### Definindo o acesso para os escopos do `GITHUB_TOKEN`\n\nVocê pode definir o acesso que o `GITHUB_TOKEN` permitirá especificando `read`, `write` ou `none` como o valor das permissões disponíveis na chave `permissions`.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n code-quality: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nSe você especificar o acesso para uma dessas permissões, todas aquelas que não forem especificadas serão definidas como `none`.\n\nVocê pode usar a sintaxe a seguir para definir o acesso de `read-all` ou `write-all` para todas as permissões disponíveis:\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nVocê pode usar a seguinte sintaxe para desabilitar as permissões para todas as permissões disponíveis:\n\n```yaml\npermissions: {}\n```\n\n#### Alterar as permissões em um repositório bifurcado\n\nVocê pode usar a tecla `permissions` para adicionar e remover permissões de leitura de repositórios derivados (forks), mas normalmente não pode conceder acesso de gravação. A exceção a esse comportamento ocorre quando um usuário administrador seleciona a opção **Enviar tokens de gravação para fluxos de trabalho a partir de pull requests** nas GitHub Actions configurações. Para saber mais, confira [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).\n\n#### Exemplo: definir as permissões do `GITHUB_TOKEN` para um trabalho em um fluxo de trabalho\n\nEste exemplo mostra as permissões que estão sendo definidas para o `GITHUB_TOKEN` que se aplicará somente ao trabalho chamado `stale`. O acesso de gravação é permitido para as permissões `issues` e `pull-requests`. Nenhuma outra permissão terá acesso.\n\n```yaml\njobs:\n stale:\n runs-on: ubuntu-latest\n\n permissions:\n issues: write\n pull-requests: write\n\n steps:\n - uses: actions/stale@v10\n```\n\n## `jobs..needs`\n\nUse `jobs..needs` para identificar todos os trabalhos que precisam ser concluídos com êxito antes que este trabalho seja executado. Esse código pode ser uma string ou array de strings. Se houver falha em um trabalho ou ele for ignorado, todos os trabalhos que dependem dele serão ignorados, a menos que os trabalhos usem uma expressão condicional que faça o trabalho continuar. Se uma execução contiver uma série de trabalhos que precisem uns dos outros, uma falha ou omissão se aplicará a todos os trabalhos na cadeia de dependência do ponto de falha ou omissão em diante. Se quiser que um trabalho seja executado mesmo que um trabalho do qual ele dependa não seja bem-sucedido, use a expressão condicional `always()` em `jobs..if`.\n\n### Exemplo: Exigir que as tarefas dependentes sejam concluídas com êxito\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n needs: [job1, job2]\n```\n\nNeste exemplo, `job1` precisa ser concluído com êxito antes que `job2` seja iniciado, e `job3` aguarda a conclusão de `job1` e de `job2`.\n\nOs trabalhos neste exemplo são executados sequencialmente:\n\n1. `job1`\n2. `job2`\n3. `job3`\n\n### Exemplo: Sem exigir a conclusão bem-sucedida de tarefas dependentes\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n if: ${{ always() }}\n needs: [job1, job2]\n```\n\nNeste exemplo, `job3` usa a expressão condicional `always()` para que ela sempre seja executada após a conclusão de `job1` e de `job2`, independentemente de elas terem sido bem-sucedidas. Para saber mais, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions#status-check-functions).\n\n## `jobs..if`\n\nUse o condicional `jobs..if` para impedir que um trabalho seja executado, a não ser que uma condição seja atendida. Você pode usar qualquer contexto e expressão compatível para criar uma condicional. Para obter mais informações sobre quais contextos têm suporte nessa chave, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\n> \\[!NOTE]\n> A condição `jobs..if` é avaliada antes de [`jobs..strategy.matrix`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymatrix) ser aplicado.\n\nAo usar expressões em um condicional `if`, opcionalmente, você poderá omitir a sintaxe de expressão `${{ }}`, pois o GitHub Actions avalia automaticamente o condicional `if` como uma expressão. No entanto, essa exceção não se aplica a todos os lugares.\n\nVocê sempre deverá usar a sintaxe de expressão `${{ }}` ou escapar com `''`, `\"\"` ou `()` quando a expressão começar com `!`, já que `!` é a notação reservada no formato YAML. Por exemplo:\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nPara obter mais informações, consulte [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\n### Exemplo: Somente executar o trabalho para um repositório específico\n\nEste exemplo usa `if` para controlar quando o trabalho `production-deploy` pode ser executado. Ele só será executado se o repositório for chamado `octo-repo-prod` e estiver na organização `octo-org`. Caso contrário, o trabalho será marcado como *ignorado*.\n\n```yaml copy\nname: example-workflow\non: [push]\njobs:\n production-deploy:\n if: github.repository == 'octo-org/octo-repo-prod'\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n```\n\n## `jobs..runs-on`\n\nUse `jobs..runs-on` para definir o tipo de computador no qual o trabalho será executado.\n\n* A máquina de destino pode ser um [GitHubrunner](#choosing-github-hosted-runners) hospedado, [executor avançado](#choosing-runners-in-a-group), ou um [runner auto-hospedado](#choosing-self-hosted-runners).\n\n* Você pode selecionar os executores com base nos rótulos atribuídos a eles, em sua participação em um grupo ou em uma combinação desses critérios.\n\n* Você pode fornecer `runs-on` como:\n * Uma única string\n * Uma única variável que contém uma cadeia de caracteres\n * Uma matriz de cadeias de caracteres, variáveis que contêm cadeias de caracteres ou uma combinação de ambas\n * um par de `key: value` usando as chaves `group` ou `labels`\n\n* Se você especificar uma matriz de cadeias de caracteres ou variáveis, o fluxo de trabalho será executado em qualquer executor que corresponda a todos os valores `runs-on` especificados. Por exemplo, aqui o trabalho só será executado em um executor auto-hospedado que tenha os rótulos `linux`, `x64` e `gpu`:\n\n ```yaml\n runs-on: [self-hosted, linux, x64, gpu]\n ```\n\n Para obter mais informações, confira [Como escolher executores auto-hospedados](#choosing-self-hosted-runners).\n\n* Você pode misturar cadeias de caracteres e variáveis em uma matriz. Por exemplo:\n\n ```yaml\n on:\n workflow_dispatch:\n inputs:\n chosen-os:\n required: true\n type: choice\n options:\n - Ubuntu\n - macOS\n\n jobs:\n test:\n runs-on: [self-hosted, \"${{ inputs.chosen-os }}\"]\n steps:\n - run: echo Hello world!\n ```\n\n* Se você quiser executar seu fluxo de trabalho em vários computadores, use [`jobs..strategy`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy).\n\n> \\[!NOTE]\n> Aspas não são necessárias em torno de cadeias de caracteres simples como`self-hosted`, mas são necessárias para expressões como`\"${{ inputs.chosen-os }}\"` .\n\n### Escolher executores hospedados em GitHub\n\nSe você usar um runner hospedado em GitHub, cada tarefa será executada em uma nova instância de uma imagem do runner especificada por `runs-on`.\n\nO valor de runs-on, quando você estiver usando um runner hospedado pelo GitHub, é um rótulo de um fluxo de trabalho ou o nome de um grupo de executores. Os rótulos dos executores padrão hospedados em GitHub são exibidos nas tabelas a seguir.\n\nPara saber mais, confira [Executores hospedados no GitHub](/pt/actions/concepts/runners/github-hosted-runners).\n\n### Executores padrão hospedados GitHubpara repositórios públicos\n\nPara repositórios públicos, os trabalhos que usam os rótulos de fluxo de trabalho mostrados na tabela abaixo serão executados com as especificações associadas.\nCom exceção dos executores de CPU única, cada executor hospedado por GitHub é uma nova máquina virtual (VM) hospedada por GitHub. Processos de CPU única são hospedados em um contêiner em uma VM compartilhada—consulte [Referência de executores hospedados pelo GitHub](/pt/actions/reference/runners/github-hosted-runners#single-cpu-runners). O uso dos executores hospedados padrão GitHubé gratuito e ilimitado em repositórios públicos.\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n\n
\nMáquina virtual/contêiner\nProcessador (CPU)\nMemória (RAM)\nArmazenamento (SSD)\nArquitetura\nRótulo do fluxo de trabalho
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux416 GB14 GB x64 \n\n```\n ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 (Versão preliminar pública)
Windows416 GB14 GB x64 \n \n windows-latest, windows-2025, , windows-2025-vs2026windows-2022
Linux416 GB14 GB arm64 \n \n ubuntu-24.04-arm, ubuntu-22.04-arm, ubuntu-26.04-arm (Versão preliminar pública)
Windows416 GB14 GBarm64\n \n windows-11-arm, windows-11-vs2026-arm
macOS414 GB14 GB Intel \n \n macos-15-intel, macos-26-intel
macOS3 (M1)7 GB14 GB arm64 \n \n macos-latest, macos-14, macos-15, macos-26, xcode-27 (Versão preliminar pública)
\n\n### Executores hospedados padrão GitHubpara privados\n\nPara privados, os trabalhos que usam os rótulos de fluxo de trabalho mostrados na tabela abaixo serão executados em máquinas virtuais com as especificações associadas. Esses executores usam a alocação de minutos gratuitos da sua GitHub conta e, posteriormente, são cobrados a taxas por minuto de uso. Confira [Precificação do executor de ações](/pt/billing/reference/actions-runner-pricing).\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n
\nMáquina virtual\nProcessador (CPU)\nMemória (RAM)\nArmazenamento (SSD)\nArquitetura\nRótulo do fluxo de trabalho
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux28 GB14 GB x64 \n\n```\n ubuntu-latest, ubuntu-24.04, ubuntu-22.04, ubuntu-26.04 (Versão preliminar pública)
Windows28 GB14 GB x64 \n \n windows-latest, , windows-2025windows-2022
Linux28 GB14 GB arm64 \n \n ubuntu-24.04-arm, ubuntu-22.04-arm, ubuntu-26.04-arm (Versão preliminar pública)
Windows28 GB14 GB arm64 \n \n windows-11-arm, windows-11-vs2026-arm
macOS414 GB14 GB Intel \n \n macos-15-intel, macos-26-intel
macOS3 (M1)7 GB14 GB arm64 \n \n macos-latest, macos-14, macos-15, macos-26, xcode-27 (Versão preliminar pública)
\n\nAlém dos executores padrão hospedados em GitHub, GitHub oferece aos clientes dos planos GitHub Team e GitHub Enterprise Cloud uma variedade de máquinas virtuais gerenciadas com recursos avançados, como, por exemplo, mais núcleos e espaço em disco, máquinas com GPU e máquinas com arquitetura ARM. Para saber mais, confira [Executores avançados](/pt/actions/concepts/runners/larger-runners).\n\n> \\[!NOTE]\n> As imagens do executor `-latest` são as imagens estáveis mais recentes fornecidas pelo GitHub, e podem não ser a versão mais recente do sistema operacional disponível junto ao fornecedor do sistema operacional.\n\n> \\[!WARNING]\n> As imagens beta e preteridas são fornecidas “no estado em que se encontram”, “com todas as falhas” e “conforme disponível” e são excluídas do contrato de nível de serviço e da garantia. As imagens beta podem não estar cobertas pelo suporte ao cliente.\n\n#### Exemplo: Especificar um sistema operacional\n\n```yaml\nruns-on: ubuntu-latest\n```\n\nPara saber mais, confira [Executores hospedados no GitHub](/pt/actions/concepts/runners/github-hosted-runners).\n\n### Escolhendo executores auto-hospedados\n\nPara especificar um executor auto-hospedado para uma tarefa, configure `runs-on` no arquivo do fluxo de trabalho utilizando rótulos do executor auto-hospedado.\n\nOs executores auto-hospedados podem ter o rótulo `self-hosted`. Ao configurar um corredor auto-hospedado, por padrão, incluiremos o rótulo `self-hosted`. Você pode passar o sinalizador `--no-default-labels` para impedir que o rótulo auto-hospedado seja aplicado. Rótulos podem ser usados para criar opções de segmentação para os executores, como sistema operacional ou arquitetura. Recomendamos fornecer uma matriz de rótulos que comece com `self-hosted` (isso deve ser listado primeiro) e depois inclua rótulos adicionais, conforme necessário. Quando você especifica um array de rótulos, os trabalhos serão enfileirados em executores que possuem todos os rótulos que você especificou.\n\n> \\[!NOTE] Actions Runner Controller não dá suporte ao `self-hosted` rótulo.\n\n#### Exemplo: Usando etiquetas para seleção do executor\n\n```yaml\nruns-on: [self-hosted, linux]\n```\n\nPara saber mais, confira [Executores auto-hospedados](/pt/actions/concepts/runners/self-hosted-runners) e [Usar os executores auto-hospedados em um fluxo de trabalho](/pt/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow).\n\n### Escolher executores em um grupo\n\nVocê pode usar `runs-on` para direcionar grupos de executores para que o trabalho seja executado em qualquer executor que seja membro desse grupo. Para um controle mais granular, você também pode combinar grupos de executores com rótulos.\n\nOs grupos de executores só podem ter [executor avançados](/pt/actions/concepts/runners/larger-runners) ou [executores auto-hospedados](/pt/actions/how-tos/manage-runners/self-hosted-runners) como membros.\n\n#### Exemplo: usar grupos para controlar onde os trabalhos são executados\n\nNeste exemplo, foram adicionados executores a um grupo chamado `build-runners`. A chave `runs-on` envia o trabalho para qualquer executor disponível no grupo `build-runners`:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on: \n group: build-runners\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n#### Exemplo: combinar grupos e rótulos\n\nQuando você combina grupos e rótulos, o executor deve atender aos dois requisitos para ser qualificado para executar o trabalho.\n\nNeste exemplo, a `runs-on` chave combina `group` e `labels` , portanto, o trabalho é roteado para qualquer executor disponível dentro do grupo que também tenha um rótulo correspondente:\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on:\n group: ubuntu-runners\n labels: ubuntu-24.04-16core\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v7\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n## `jobs..snapshot`\n\nVocê pode usar `jobs..snapshot` para gerar uma imagem personalizada.\n\nAdicione a palavra-chave \"instantâneo\" ao trabalho, utilizando a sintaxe de string ou a sintaxe de mapeamento, conforme mostrado em [Geração de uma Imagem Personalizada](/pt/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image).\n\nCada tarefa que inclui a palavra-chave \"captura\" gera uma imagem separada. Para gerar apenas uma imagem ou versão de imagem, inclua todas as etapas de fluxo de trabalho em um único trabalho. Cada execução bem-sucedida de um trabalho que inclui a palavra-chave \"snapshot\" cria uma nova versão dessa imagem.\n\nPara saber mais, confira [Usando imagens personalizadas](/pt/actions/how-tos/manage-runners/larger-runners/use-custom-images).\n\n## `jobs..environment`\n\nUse `jobs..environment` para definir o ambiente que o trabalho referencia.\n\nVocê pode fornecer o ambiente como apenas o ambiente `name` ou como um objeto de ambiente com o `name` e a `url`. A URL é mapeada para `environment_url` na a API de implantações. Para obter mais informações sobre a API de implantações, confira [Pontos de extremidade da API REST para repositórios](/pt/rest/repos#deployments).\n\n> \\[!NOTE]\n> Todas as regras de proteção para implantação têm de ser aprovadas para que um trabalho que faça referência ao ambiente seja enviado a um executor. Para saber mais, confira [Gerenciar ambientes para implantação](/pt/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\n### Exemplo: Usando um único nome de ambiente\n\n```yaml\nenvironment: staging_environment\n```\n\n### Exemplo: Usando o nome de ambiente e URL\n\n```yaml\nenvironment:\n name: production_environment\n url: https://github.com\n```\n\nO valor de `url` pode ser uma expressão. Contextos de expressão permitidos: [`github`](/pt/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/pt/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/pt/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/pt/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/pt/actions/reference/workflows-and-actions/contexts#strategy-context), [`matrix`](/pt/actions/reference/workflows-and-actions/contexts#matrix-context), [`job`](/pt/actions/reference/workflows-and-actions/contexts#job-context), [`runner`](/pt/actions/reference/workflows-and-actions/contexts#runner-context), [`env`](/pt/actions/reference/workflows-and-actions/contexts#env-context) e [`steps`](/pt/actions/reference/workflows-and-actions/contexts#steps-context). Para obter mais informações sobre expressões, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\n### Exemplo: Usando a saída como URL\n\n```yaml\nenvironment:\n name: production_environment\n url: ${{ steps.step_id.outputs.url_output }}\n```\n\nO valor de `name` pode ser uma expressão. Contextos de expressão permitidos: [`github`](/pt/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/pt/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/pt/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/pt/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/pt/actions/reference/workflows-and-actions/contexts#strategy-context) e [`matrix`](/pt/actions/reference/workflows-and-actions/contexts#matrix-context). Para obter mais informações sobre expressões, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\n### Exemplo: usando uma expressão como nome de ambiente\n\n```yaml\nenvironment:\n name: ${{ github.ref_name }}\n```\n\n### Exemplo: usar um ambiente sem criar uma implantação\n\nDefina `deployment` para `false` usar os segredos e variáveis de um ambiente sem criar um objeto de implantação.\n\n```yaml\nenvironment:\n name: testing\n deployment: false\n```\n\nA configuração `deployment: false` não é compatível com regras de proteção de implantação personalizadas.\nPara saber mais, confira [Implantando com GitHub Actions](/pt/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments#using-environments-without-deployments).\n\n## `jobs..concurrency`\n\nVocê pode usar `jobs..concurrency` para garantir que apenas um trabalho ou fluxo de trabalho que usa o mesmo grupo de simultaneidade seja executado por vez. Um grupo de concorrência pode ser qualquer string ou expressão. Contextos de expressão permitidos: [`github`](/pt/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/pt/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/pt/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/pt/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/pt/actions/reference/workflows-and-actions/contexts#strategy-context) e [`matrix`](/pt/actions/reference/workflows-and-actions/contexts#matrix-context). Para obter mais informações sobre expressões, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\nEspecifique também `concurrency` no nível do fluxo de trabalho. Para obter mais informações, confira [`concurrency`](/pt/actions/reference/workflows-and-actions/workflow-syntax#concurrency).\n\nIsso significa que pode haver no máximo um trabalho ou fluxo de trabalho em execução em um grupo de concorrência a qualquer momento. Quando um trabalho ou um fluxo de trabalho simultâneo é colocado na fila, se outro trabalho ou fluxo de trabalho que usa o mesmo grupo de simultaneidade no repositório estiver em andamento, o trabalho ou o fluxo de trabalho na fila ficará `pending`. Por padrão, qualquer trabalho ou fluxo de trabalho existente `pending` no mesmo grupo de simultaneidade será cancelado e o novo trabalho ou fluxo de trabalho em fila tomará seu lugar.\n\nPara também cancelar qualquer trabalho ou fluxo de trabalho em execução no mesmo grupo de concorrência, especifique `cancel-in-progress: true`. Para cancelar condicionalmente trabalhos ou fluxos de trabalho em execução no mesmo grupo de simultaneidade, é possível especificar `cancel-in-progress` como uma expressão com qualquer um dos contextos de expressão permitidos.\n\nPara permitir que mais de uma tarefa ou execução de fluxo de trabalho aguardem no mesmo grupo de simultaneidade, use a propriedade opcional `queue`. A `queue` propriedade aceita os seguintes valores:\n\n* `single` (padrão): no máximo uma execução de tarefa ou de fluxo de trabalho pode ser `pending` no grupo de simultaneidade. Quando uma nova execução de trabalho ou fluxo de trabalho é enfileirada, qualquer execução existente de trabalho ou fluxo de trabalho `pending` no mesmo grupo é cancelada e substituída.\n* `max`: até 100 trabalhos ou execuções de fluxo de trabalho podem ser incluídos no grupo de simultaneidade. Quando a fila estiver cheia, quaisquer trabalhos adicionais ou execuções de fluxo de trabalho serão cancelados.\n\nA combinação de `queue: max` e `cancel-in-progress: true` não é permitida e resultará em um erro de validação de fluxo de trabalho.\n\n> \\[!NOTE]\n>\n> * O nome do grupo de simultaneidade não diferencia maiúsculas de minúsculas. Por exemplo, `prod` e `Prod` serão tratados como o mesmo grupo de simultaneidade.\n> * Trabalhos ou execuções de fluxo de trabalho no mesmo grupo de simultaneidade são processados na ordem de primeiro a entrar em primeiro lugar (FIFO), de acordo com o momento em que cada um começou a esperar no grupo de simultaneidade, não o tempo em que cada fluxo de trabalho foi expedido. Como o horário de início efetivo de um trabalho ou execução pode variar, a ordenação não é garantida.\n\n### Exemplos: Usar a simultaneidade e o comportamento padrão\n\nO comportamento GitHub Actions padrão é permitir que vários trabalhos ou execuções de fluxo de trabalho sejam executados simultaneamente. A palavra-chave `concurrency` permite controlar a simultaneidade de execuções de fluxo de trabalho.\n\nPor exemplo, você pode usar a palavra-chave `concurrency` imediatamente após a definição das condições de disparo para limitar a simultaneidade de execuções de fluxo de trabalho inteiro para uma ramificação específica:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nVocê também pode limitar a simultaneidade de trabalhos em um fluxo de trabalho usando a palavra-chave `concurrency` no nível do trabalho:\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Exemplo: grupos de concorrência\n\nOs grupos de simultaneidade fornecem uma maneira de gerenciar e limitar a execução de fluxos de trabalho ou tarefas que compartilham a mesma chave de simultaneidade.\n\nA chave `concurrency` é usada para agrupar fluxos de trabalho ou trabalhos em um grupo de simultaneidade. Quando você define uma `concurrency` chave, GitHub Actions garante que apenas um fluxo de trabalho ou trabalho com essa chave seja executado a qualquer momento. Se uma nova execução de fluxo de trabalho ou trabalho começar com a mesma `concurrency` chave, GitHub Actions cancelará qualquer fluxo de trabalho ou trabalho já em execução com essa chave. A chave `concurrency` pode ser uma cadeia de caracteres codificada ou pode ser uma expressão dinâmica que inclui variáveis de contexto.\n\nÉ possível definir condições de concorrência no seu workflow para que o workflow ou tarefa faça parte de um grupo de concorrência.\n\nIsso significa que, quando um fluxo de trabalho for executado ou iniciado, o GitHub cancelará todas as execuções de fluxo de trabalho ou trabalhos que já estejam em andamento no mesmo grupo de simultaneidade. Isso é útil em cenários em que você deseja impedir execuções paralelas para um determinado conjunto de fluxos de trabalho ou trabalhos, como os usados para implantações em um ambiente de preparo, a fim de evitar ações que possam causar conflitos ou consumir mais recursos do que o necessário.\n\nNeste exemplo, `job-1` faz parte de um grupo de simultaneidade chamado `staging_environment`. Isso significa que, se uma nova execução de `job-1` for acionada, todas as execuções do mesmo trabalho no grupo de simultaneidade `staging_environment` que já estiverem em andamento serão canceladas.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nComo alternativa, usar uma expressão dinâmica, como `concurrency: ci-${{ github.ref }}` em seu fluxo de trabalho, significa que o fluxo de trabalho ou trabalho faria parte de um grupo de concorrência chamado `ci-`, seguido pela referência da ramificação ou tag que acionou o fluxo de trabalho. Neste exemplo, se uma nova confirmação for enviada para a ramificação principal enquanto uma execução anterior ainda estiver em andamento, a execução anterior será cancelada e a nova será iniciada:\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemplo: Enfileirando várias tarefas pendentes\n\nPor padrão, apenas uma execução de tarefa ou de fluxo de trabalho pode estar `pending` em um grupo de simultaneidade por vez. Para permitir várias execuções na fila em vez de serem canceladas, defina `queue: max`. Com `queue: max`, até 100 trabalhos ou execuções de fluxo de trabalho podem aguardar no grupo de simultaneidade; depois que a fila estiver cheia, quaisquer execuções adicionais são canceladas.\n\nPor exemplo, o fluxo de trabalho a seguir enfileira implantações no ambiente `production`, processando-as uma de cada vez em ordem com base no momento em que cada execução começou a aguardar no grupo de concorrência.\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nObserve que `queue: max` não pode ser combinado com `cancel-in-progress: true`, porque as duas opções descrevem comportamentos conflitantes para lidar com execuções em andamento.\n\n### Exemplo: Usar a concorrência para cancelar qualquer trabalho em andamento ou em execução\n\nPara usar a simultaneidade para cancelar qualquer trabalho em andamento GitHub Actions ou execução, você pode usar a tecla `concurrency` com a opção `cancel-in-progress` definida como `true`:\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nObserve que, neste exemplo, sem definir um grupo de simultaneidade específico, GitHub Actions cancelará a execução de qualquer trabalho ou fluxo de trabalho em andamento.\n\n### Exemplo: Usando um valor para segunda opção\n\nSe você construir o nome do grupo com uma propriedade que só é definida para eventos específicos, você pode usar um valor de segunda opção. Por exemplo, `github.head_ref` só é definido em eventos `pull_request`. Se o fluxo de trabalho responder a outros eventos além de eventos `pull_request`, você precisará fornecer um fallback para evitar um erro de sintaxe. O grupo de simultaneidade a seguir cancela os trabalhos em andamento ou é executado somente em eventos `pull_request`. Se `github.head_ref` for indefinido, o grupo de simultaneidade fará fallback para a ID de execução, que tem a garantia de ser exclusiva e definida para a execução.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Exemplo: Cancele somente tarefas em andamento ou execuções no fluxo de trabalho atual\n\nSe você tiver vários fluxos de trabalho no mesmo repositório, os nomes dos grupos de execução concorrente devem ser únicos em todos os fluxos de trabalho para evitar o cancelamento de tarefas ou execuções em andamento de outros fluxos de trabalho. Caso contrário, qualquer trabalho em andamento ou pendente será cancelado, independentemente do fluxo de trabalho.\n\nPara cancelar apenas as execuções em andamento do mesmo fluxo de trabalho, use a propriedade `github.workflow` para criar o grupo de simultaneidade:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemplo: cancelar apenas trabalhos em andamento em ramificações específicas\n\nSe você quiser cancelar trabalhos em andamento em determinadas ramificações, mas não em outras, poderá usar expressões condicionais com `cancel-in-progress`. Por exemplo, é possível fazer isso se quiser cancelar trabalhos em andamento em branches de desenvolvimento, mas não em branches de lançamento.\n\nPara cancelar apenas execuções em andamento do mesmo fluxo de trabalho quando não estiverem em execução em um branch de lançamento, é possível definir `cancel-in-progress` para uma expressão semelhante à seguinte:\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nNeste exemplo, vários envios por push para um branch `release/1.2.3` não cancelariam execuções em andamento. Envios por push para outro branch, como `main`, cancelariam execuções em andamento.\n\n## `jobs..outputs`\n\nVocê pode usar `jobs..outputs` para criar um `map` das saídas de uma tarefa. As saídas de trabalho estão disponíveis para todos os trabalhos downstream que dependem deste trabalho. Para obter mais informações sobre como definir dependências de trabalho, confira [`jobs..needs`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).\n\nAs saídas podem ter no máximo 1 MB por trabalho. O total de todas as saídas em uma execução de fluxo de trabalho pode ter no máximo 50 MB. O tamanho é aproximado com base na codificação UTF-16.\n\nAs saídas de trabalho que contêm expressões são avaliadas no executor ao final de cada trabalho. As saídas que contêm segredos são ocultadas no runner e não são enviadas para GitHub Actions.\n\nSe uma saída for ignorada porque pode conter um segredo, você verá a seguinte mensagem de aviso: \"Ignorar saída `{output.Key}` pois ela pode conter segredo\". Para obter mais informações sobre como lidar com segredos, consulte o [Exemplo: Mascarar e passar um segredo entre trabalhos ou fluxos de trabalho](/pt/actions/reference/workflows-and-actions/workflow-commands#example-masking-and-passing-a-secret-between-jobs-or-workflows).\n\nPara usar saídas de trabalho em um trabalho dependente, você pode usar o contexto `needs`. Para saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts#needs-context).\n\n### Exemplo: Definindo saídas para um trabalho\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n # Map a step output to a job output\n outputs:\n output1: ${{ steps.step1.outputs.test }}\n output2: ${{ steps.step2.outputs.test }}\n steps:\n - id: step1\n run: echo \"test=hello\" >> \"$GITHUB_OUTPUT\"\n - id: step2\n run: echo \"test=world\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: job1\n steps:\n - env:\n OUTPUT1: ${{needs.job1.outputs.output1}}\n OUTPUT2: ${{needs.job1.outputs.output2}}\n run: echo \"$OUTPUT1 $OUTPUT2\"\n```\n\n### Uso de saídas de trabalho em um trabalho de matriz\n\nAs matrizes podem ser usadas para gerar várias saídas de nomes diferentes. Ao usar uma matriz, as saídas dos trabalhos serão combinadas a partir de todos os trabalhos na matriz.\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n outputs:\n output_1: ${{ steps.gen_output.outputs.output_1 }}\n output_2: ${{ steps.gen_output.outputs.output_2 }}\n output_3: ${{ steps.gen_output.outputs.output_3 }}\n strategy:\n matrix:\n version: [1, 2, 3]\n steps:\n - name: Generate output\n id: gen_output\n run: |\n version=\"${{ matrix.version }}\"\n echo \"output_${version}=${version}\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: [job1]\n steps:\n # Will show\n # {\n # \"output_1\": \"1\",\n # \"output_2\": \"2\",\n # \"output_3\": \"3\"\n # }\n - run: echo '${{ toJSON(needs.job1.outputs) }}'\n```\n\n> \\[!WARNING]\n> O Actions não garante a ordem em que os trabalhos da matriz serão executados. Verifique se o nome de saída é exclusivo; caso contrário, o último trabalho de matriz executado substituirá o valor de saída.\n\n## `jobs..env`\n\nUm `map` das variáveis que estão disponíveis para todas as etapas do trabalho. Também é possível definir variáveis para todo o fluxo de trabalho ou uma etapa individual. Para obter mais informações, consulte [`env`](#env) e [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nQuando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá as variáveis de ambiente do trabalho e do fluxo de trabalho que tenham o mesmo nome enquanto a etapa é executada. Uma variável de ambiente definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome enquanto o trabalho é executado.\n\n### Exemplo de `jobs..env`\n\n```yaml\njobs:\n job1:\n env:\n FIRST_NAME: Mona\n```\n\n## `jobs..defaults`\n\nUse `jobs..defaults` para criar um `map` das configurações padrão que será aplicado a todas as etapas do trabalho. Você também pode definir as configurações-padrão para todo o fluxo de trabalho. Para obter mais informações, confira [`defaults`](/pt/actions/reference/workflows-and-actions/workflow-syntax#defaults).\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `jobs..defaults.run`\n\nUse `jobs..defaults.run` para fornecer o `shell` e o `working-directory` padrão para todas as etapas `run` do trabalho.\n\nVocê pode fornecer as opções `shell` e `working-directory` padrão para todas as etapas [`run`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) de um trabalho. Também pode definir as configurações padrão para `run` em todo o fluxo de trabalho. Para obter mais informações, consulte [`defaults.run`](/pt/actions/reference/workflows-and-actions/workflow-syntax#defaultsrun).\n\nEsses podem ser substituídos nos níveis `jobs..defaults.run` e `jobs..steps[*].run`.\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `jobs..defaults.run.shell`\n\nUse `shell` para definir o `shell` para uma etapa. Essa palavra-chave pode fazer referência a vários contextos. Para obter mais informações, confira [Contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\n| Plataforma compatível | Parâmetro `shell` | Descrição | Comando executado internamente |\n| --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | não especificado | O shell padrão em plataformas não Windows. Isso executa um comando diferente para quando `bash` é especificado explicitamente. Se `bash` não for encontrado no caminho, isso será tratado como `sh`. | `bash -e {0}` |\n| Tudo | `bash` | O shell padrão em plataformas não Windows com um fallback para `sh`. Ao especificar um shell bash no Windows, é utilizado o shell bash incluído no Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tudo | `pwsh` | Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `pwsh -command \". '{0}'\"` |\n| Tudo | `python` | Executa o comando python. | `python {0}` |\n| Linux / macOS | `sh` | O comportamento de fallback para plataformas não Windows se nenhum shell for fornecido e o `bash` não for encontrado no caminho. | `sh -e {0}` |\n| Windows | `cmd` | O GitHub acrescenta a extensão `.cmd` ao nome do script e a substitui por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Essa é a shell padrão usada no Windows. Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. Se o executor auto-hospedado do Windows não tiver o *PowerShell Core* instalado, o *PowerShell Desktop* será usado. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | O PowerShell Desktop. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `powershell -command \". '{0}'\"`. |\n\nQuando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n## `jobs..defaults.run.working-directory`\n\nUse `working-directory` para definir o diretório de trabalho do `shell` de uma etapa. Essa palavra-chave pode fazer referência a vários contextos. Para obter mais informações, confira [Contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Verifique se o `working-directory` existe no executor antes de executar seu shell nele.\n> Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.\n\n### Exemplo: definição das opções da etapa `run` padrão para um trabalho\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n defaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `jobs..steps`\n\nUm trabalho contém uma sequência de tarefas chamada `steps`. As etapas podem executar comandos, executar trabalhos de configuração ou executar ações no seu repositório, em repositórios públicos, ou ações publicadas em registros do Docker. Nem todas as etapas executam ações, mas todas as ações são executadas como etapas. Cada etapa é executada em seu próprio processo no ambiente do executor, tendo acesso ao espaço de trabalho e ao sistema de arquivos. Como as etapas são executadas em seus próprios processos, as alterações nas variáveis de ambiente não são preservadas entre as etapas.\nGitHub fornece etapas internas para configurar e concluir um trabalho.\n\nGitHub exibe apenas as primeiras 1.000 verificações, no entanto, você pode executar um número ilimitado de etapas, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte [Cobrança e uso](/pt/actions/concepts/billing-and-usage) sobre executores hospedados em GitHub e [Limites do Actions](/pt/actions/reference/limits) para limites de uso de executores auto-hospedados.\n\n### Exemplo de `jobs..steps`\n\n```yaml\nname: Greeting from Mona\n\non: push\n\njobs:\n my-job:\n name: My Job\n runs-on: ubuntu-latest\n steps:\n - name: Print a greeting\n env:\n MY_VAR: Hi there! My name is\n FIRST_NAME: Mona\n MIDDLE_NAME: The\n LAST_NAME: Octocat\n run: |\n echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.\n```\n\n## `jobs..steps[*].id`\n\nIdentificador exclusivo da etapa. Use a `id` para referenciar a etapa em contextos. Para saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts).\n\n## `jobs..steps[*].if`\n\nUse o condicional `if` para impedir que uma etapa seja executada, a não ser que uma condição seja atendida. Você pode usar qualquer contexto e expressão compatível para criar uma condicional. Para obter mais informações sobre quais contextos têm suporte nessa chave, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability).\n\nAo usar expressões em um condicional `if`, opcionalmente, você poderá omitir a sintaxe de expressão `${{ }}`, pois o GitHub Actions avalia automaticamente o condicional `if` como uma expressão. No entanto, essa exceção não se aplica a todos os lugares.\n\nVocê sempre deverá usar a sintaxe de expressão `${{ }}` ou escapar com `''`, `\"\"` ou `()` quando a expressão começar com `!`, já que `!` é a notação reservada no formato YAML. Por exemplo:\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nPara obter mais informações, consulte [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions).\n\n### Exemplo: Usando contextos\n\nEssa etapa só é executada quando o tipo de evento é uma `pull_request` e a ação do evento é `unassigned`.\n\n```yaml\nsteps:\n - name: My first step\n if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n run: echo This event is a pull request that had an assignee removed.\n```\n\n### Exemplo: Usando funções de verificação de status\n\nA `my backup step` só é executada quando a etapa anterior de um trabalho falha. Para saber mais, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/reference/workflows-and-actions/expressions#status-check-functions).\n\n```yaml\nsteps:\n - name: My first step\n uses: octo-org/action-name@main\n - name: My backup step\n if: ${{ failure() }}\n uses: actions/heroku@1.0.0\n```\n\n### Exemplo: Usando segredos\n\nNão é possível referenciar segredos diretamente em condicionais `if:`. Em vez disso, considere definir segredos como variáveis de ambiente no nível de trabalho e, em seguida, fazer referência às variáveis de ambiente para executar etapas condicionalmente no trabalho.\n\nSe um segredo não tiver sido definido, o valor retornado de uma expressão referenciando o segredo (como `${{ secrets.SuperSecret }}` no exemplo) será uma cadeia de caracteres vazia.\n\n```yaml\nname: Run a step if a secret has been set\non: push\njobs:\n my-jobname:\n runs-on: ubuntu-latest\n env:\n super_secret: ${{ secrets.SuperSecret }}\n steps:\n - if: ${{ env.super_secret != '' }}\n run: echo 'This step will only run if the secret has a value set.'\n - if: ${{ env.super_secret == '' }}\n run: echo 'This step will only run if the secret does not have a value set.'\n```\n\nPara saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts#context-availability) e [Usar segredos em ações do GitHub](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\n## `jobs..steps[*].name`\n\nUm nome para sua etapa ser exibida em GitHub.\n\n## `jobs..steps[*].uses`\n\nSeleciona uma ação para executar como parte de uma etapa no trabalho. A ação é uma unidade reutilizável de código. Você pode usar uma ação definida no mesmo repositório do fluxo de trabalho, um repositório público ou em uma [imagem publicada de um contêiner do Docker](https://hub.docker.com/).\n\nÉ altamente recomendável incluir a versão da ação que você está usando especificando uma referência de Git, SHA ou uma marca do Docker. Se você não especificar uma versão, ela poderá interromper seus fluxos de trabalho ou causar um comportamento inesperado quando o proprietário da ação publicar uma atualização.\n\n* Usar o commit SHA de uma versão de ação lançada é a maneira mais garantida de obter estabilidade e segurança.\n* Se a ação publicar marcas de versão principal, você deverá esperar receber correções críticas e patches de segurança enquanto ainda mantém a compatibilidade. Observe que esse comportamento fica a critério do autor da ação.\n* Usar o branch-padrão de uma ação pode ser conveniente, mas se alguém lançar uma nova versão principal com uma mudança significativa, seu fluxo de trabalho poderá ter problemas.\n\nAlgumas ações exigem entradas que precisam ser definidas com a palavra-chave [`with`](#jobsjob_idstepswith). Revise o arquivo README da ação para determinar as entradas obrigatórias.\n\nAções são arquivos do JavaScript ou contêineres Docker. Se a ação em uso for um contêiner do Docker, você deverá executar o trabalho em um ambiente do Linux. Para obter mais detalhes, consulte [`runs-on`](#jobsjob_idruns-on).\n\n### Exemplo: Usando ações de versão\n\n```yaml\nsteps:\n # Reference a specific commit\n - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n # Reference the major version of a release\n - uses: actions/checkout@v6\n # Reference a specific version\n - uses: actions/checkout@v6.2.0\n # Reference a branch\n - uses: actions/checkout@main\n```\n\n### Exemplo: Usando uma ação pública\n\n`{owner}/{repo}@{ref}`\n\nVocê pode especificar um branch, ref ou SHA em um repositório público GitHub.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n # Uses the default branch of a public repository\n uses: actions/heroku@main\n - name: My second step\n # Uses a specific version tag of a public repository\n uses: actions/aws@v2.0.1\n```\n\n### Exemplo: Usando uma ação pública em um subdiretório\n\n`{owner}/{repo}/{path}@{ref}`\n\nUm subdiretório em um repositório público GitHub em uma ramificação, ref ou SHA específico.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/aws/ec2@main\n```\n\n### Exemplo: usando uma ação no mesmo repositório que o fluxo de trabalho na confirmação em execução (recomendado)\n\n`$/path/to/action`\n\nO `$/` prefixo é a referência de auto repositório. Ele faz referência a uma ação armazenada no mesmo repositório que o fluxo de trabalho ou a ação que está em execução no momento e resolve para esse repositório na confirmação em execução (o mesmo SHA que o fluxo de trabalho ou ação em execução). Você não precisa fazer check-out do repositório primeiro, portanto, é a maneira recomendada de referenciar uma ação em seu próprio repositório.\n\nA `$/` sintaxe não está disponível em GitHub Enterprise Server.\n\nUma `$/` referência não deve incluir um `@{ref}` sufixo. O ref é sempre a confirmação que o fluxo de trabalho ou ação em execução está usando, portanto, uma referência como `$/actions/my-action@v1` é inválida.\n\n`$/` sempre é resolvido no repositório do arquivo em que ele aparece, não no repositório que o chamou. Por exemplo, se um fluxo de trabalho reutilizável em um repositório for chamado por um fluxo de trabalho em outro repositório, uma `$/` referência no fluxo de trabalho chamado será resolvida para o repositório do fluxo de trabalho chamado, não o repositório do fluxo de trabalho de chamada. Isso torna `$/` confiável para a composição de ação, em que um caminho relativo `./` seria resolvido em relação ao que for verificado no workspace do chamador. Para usar `$/` nas etapas de uma ação composta, consulte [Referência de sintaxe de metadados](/pt/actions/reference/workflows-and-actions/metadata-syntax#runsstepsuses).\n\nA tabela a seguir compara as maneiras de referenciar uma ação.\n\n| Sintaxe | É resolvido desta forma | Recomendado para |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------- |\n| `$/path/to/action` | O mesmo repositório que o fluxo de trabalho ou ação em execução, na confirmação em execução | Ações no mesmo repositório |\n| `{owner}/{repo}@{ref}` | O repositório especificado no ref especificado | Ações em outro repositório |\n| `./path/to/action` | Um caminho no workspace de check-out do executor, em relação ao diretório de trabalho padrão (`${{ github.workspace }}`) | Somente casos de borda |\n\n```yaml\non: [push]\n\njobs:\n my_first_job:\n runs-on: ubuntu-latest\n steps:\n # References an action in the same repository at the running commit\n - uses: $/.github/actions/hello-world-action\n```\n\n### Exemplo: Usando uma ação no mesmo repositório que o fluxo de trabalho\n\n`./path/to/dir`\n\nCaminho para o diretório que contém a ação no repositório do seu fluxo de trabalho. Você deve fazer check-out do repositório antes de usar a ação e o `./` caminho é resolvido no workspace do executor em vez do repositório do fluxo de trabalho em execução. Para a maioria dos casos, use a `$/` sintaxe mostrada acima.\n\nExemplo de estrutura de arquivo de repositório:\n\n```shell\n|-- hello-world (repository)\n| |__ .github\n| └── workflows\n| └── my-first-workflow.yml\n| └── actions\n| |__ hello-world-action\n| └── action.yml\n```\n\nO caminho é relativo (`./`) ao diretório de trabalho padrão (`github.workspace`, `$GITHUB_WORKSPACE`). Se a ação fizer check-out do repositório para um local diferente do fluxo de trabalho, o caminho relativo usado para ações locais deverá ser atualizado.\n\nExemplo de arquivo de fluxo de trabalho:\n\n```yaml\njobs:\n my_first_job:\n runs-on: ubuntu-latest\n steps:\n # This step checks out a copy of your repository.\n - name: My first step - check out repository\n uses: actions/checkout@v6\n # This step references the directory that contains the action.\n - name: Use local hello-world-action\n uses: ./.github/actions/hello-world-action\n```\n\n### Exemplo: Usando uma ação do Docker Hub\n\n`docker://{image}:{tag}`\n\nUma imagem do Docker publicada no [Docker Hub](https://hub.docker.com/).\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://alpine:3.8\n```\n\n### Exemplo: usando o GitHub PackagesContainer registry\n\n`docker://{host}/{image}:{tag}`\n\nUma imagem pública do Docker na GitHub PackagesContainer registry.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://ghcr.io/OWNER/IMAGE_NAME\n```\n\n### Exemplo: Usando uma ação do registro público do Docker\n\n`docker://{host}/{image}:{tag}`\n\nImagem Docker em um registro público. Este exemplo usa o Registro de Contêiner do Google em `gcr.io`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://gcr.io/cloud-builders/gradle\n```\n\n### Exemplo: Usando uma ação dentro de um repositório privado diferente do fluxo de trabalho\n\nSe a ação estiver em um repositório interno ou em um repositório privado configurado para permitir o acesso do repositório do seu fluxo de trabalho, você poderá referenciar a ação diretamente. Para obter mais informações, consulte [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository) e [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).\n\nSe a ação não estiver em um repositório configurado para permitir acesso, você precisará verificar o repositório e referenciar a ação localmente. Gere um personal access token e adicione o token como um segredo. O exemplo a seguir mostra esse método para referenciar uma ação. Para saber mais, confira [Gerenciar seus tokens de acesso pessoal](/pt/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) e [Usar segredos em ações do GitHub](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nSubstitua `PERSONAL_ACCESS_TOKEN` no exemplo pelo nome do segredo.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: Check out repository\n uses: actions/checkout@v6\n with:\n repository: octocat/my-private-repo\n ref: v1.0\n token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n path: ./.github/actions/my-private-repo\n - name: Run my action\n uses: ./.github/actions/my-private-repo/my-action\n```\n\nComo alternativa, use um GitHub App em vez de um personal access token para garantir que seu fluxo de trabalho continue sendo executado mesmo se o personal access token proprietário sair. 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).\n\n## `jobs..steps[*].run`\n\nExecuta programas de linha de comando que não excedem 21.000 caracteres usando o shell do sistema operacional. Se você não informar um `name`, o nome da etapa usará como padrão o texto indicado no comando `run`.\n\nPor padrão, os comandos run usam shells que nao são de login. Você pode escolher um shell diferente e personalizar o shell usado para executar comandos. Para obter mais informações, consulte [`jobs..steps[*].shell`](#jobsjob_idstepsshell).\n\nCada palavra-chave `run` representa um novo processo e um shell no ambiente do executor. Ao fornecer comandos de várias linhas, cada linha será executada no mesmo shell. Por exemplo:\n\n* Um comando de linha única:\n\n ```yaml\n - name: Install Dependencies\n run: npm install\n ```\n\n* Um comando de várias linhas:\n\n ```yaml\n - name: Clean install dependencies and build\n run: |\n npm ci\n npm run build\n ```\n\n## `jobs..steps[*].working-directory`\n\nCom a palavra-chave `working-directory`, é possível especificar o diretório de trabalho do qual o comando será executado.\n\n```yaml\n- name: Clean temp directory\n run: rm -rf *\n working-directory: ./temp\n```\n\nComo alternativa, você pode especificar um diretório de trabalho padrão para todas as etapas `run` em um trabalho ou para todas as etapas `run` em todo o fluxo de trabalho. Para obter mais informações, consulte [`defaults.run.working-directory`](/pt/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunworking-directory) e [`jobs..defaults.run.working-directory`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunworking-directory).\n\nVocê também pode usar uma etapa `run` para executar um script. Para saber mais, confira [Adicionar scripts ao seu fluxo de trabalho](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/add-scripts).\n\n## `jobs..steps[*].shell`\n\nSubstitua as configurações padrão do shell no sistema operacional do executor e o padrão do trabalho usando a palavra-chave `shell`. É possível usar palavras-chave `shell` internas ou definir um conjunto personalizado de opções de shell. O comando do shell que é executado internamente executa um arquivo temporário que contém os comandos especificados na palavra-chave `run`.\n\n| Plataforma compatível | Parâmetro `shell` | Descrição | Comando executado internamente |\n| --------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | não especificado | O shell padrão em plataformas não Windows. Isso executa um comando diferente para quando `bash` é especificado explicitamente. Se `bash` não for encontrado no caminho, isso será tratado como `sh`. | `bash -e {0}` |\n| Tudo | `bash` | O shell padrão em plataformas não Windows com um fallback para `sh`. Ao especificar um shell bash no Windows, é utilizado o shell bash incluído no Git para Windows. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tudo | `pwsh` | Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `pwsh -command \". '{0}'\"` |\n| Tudo | `python` | Executa o comando python. | `python {0}` |\n| Linux / macOS | `sh` | O comportamento de fallback para plataformas não Windows se nenhum shell for fornecido e o `bash` não for encontrado no caminho. | `sh -e {0}` |\n| Windows | `cmd` | O GitHub acrescenta a extensão `.cmd` ao nome do script e a substitui por `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Essa é a shell padrão usada no Windows. Powershell Core. O GitHub acrescenta a extensão `.ps1` ao nome do script. Se o executor auto-hospedado do Windows não tiver o *PowerShell Core* instalado, o *PowerShell Desktop* será usado. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | O PowerShell Desktop. O GitHub acrescenta a extensão `.ps1` ao nome do script. | `powershell -command \". '{0}'\"`. |\n\nComo alternativa, você pode especificar um shell padrão para todas as etapas `run` em um trabalho ou para todas as etapas `run` em todo o fluxo de trabalho. Para obter mais informações, consulte [`defaults.run.shell`](/pt/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunshell) e [`jobs..defaults.run.shell`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunshell).\n\n### Exemplo: executar um comando usando o Bash\n\n```yaml\nsteps:\n - name: Display the path\n shell: bash\n run: echo $PATH\n```\n\n### Exemplo: executar um comando usando o Windows `cmd`\n\n```yaml\nsteps:\n - name: Display the path\n shell: cmd\n run: echo %PATH%\n```\n\n### Exemplo: executar um comando usando o PowerShell Core\n\n```yaml\nsteps:\n - name: Display the path\n shell: pwsh\n run: echo ${env:PATH}\n```\n\n### Exemplo: usar o PowerShell Desktop para executar um comando\n\n```yaml\nsteps:\n - name: Display the path\n shell: powershell\n run: echo ${env:PATH}\n```\n\n### Exemplo: executar um script do Python embutido\n\n```yaml\nsteps:\n - name: Display the path\n shell: python\n run: |\n import os\n print(os.environ['PATH'])\n```\n\n### Shell personalizado\n\nVocê pode definir o valor `shell` como uma cadeia de caracteres de modelo usando `command [options] {0} [more_options]`.\nGitHub interpreta a primeira palavra delimitada pelo espaço em branco da cadeia de caracteres como o comando e insere o nome do arquivo para o script temporário em `{0}`.\n\nPor exemplo:\n\n```yaml\nsteps:\n - name: Display the environment variables and their values\n shell: perl {0}\n run: |\n print %ENV\n```\n\nO comando usado, `perl` neste exemplo, precisa ser instalado no executor.\n\nPara obter informações sobre o software incluído nos executores hospedados no GitHub, consulte [Executores hospedados no GitHub](/pt/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images).\n\n### Preferências de ação de erro e códigos de saída\n\nPara palavras-chave de shell integradas, fornecemos os seguintes padrões que são executados por executores hospedados em GitHub. Você deve seguir estas diretrizes quando executar scripts shell.\n\n* `bash`\n /\n `sh`:\n * Por padrão, o comportamento fail fast é imposto usando `set -e` para `sh` e `bash`. Quando `shell: bash` é especificado, `-o pipefail` também é aplicado para impor a saída antecipada de pipelines que geram um status de saída diferente de zero.\n * Você pode ter controle total sobre os parâmetros do shell fornecendo uma string de modelo para as opções do shell. Por exemplo, `bash {0}`.\n * ```\n Shells do tipo `sh` saem com o código de saída do último comando executado em um script, que também é o comportamento padrão das ações. O executor relatará o status da etapa como falha/êxito com base nesse código de saída.\n ```\n\n* `powershell`/`pwsh`\n * Comportamento fail-fast quando possível. Para `pwsh` e o shell interno `powershell`, prefixaremos `$ErrorActionPreference = 'stop'` ao conteúdo do script.\n * Prefixamos `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` aos scripts do PowerShell para que os status de ação reflitam o último código de saída do script.\n * Os usuários sempre podem recusar o uso do shell interno e fornecer uma opção de shell personalizada como: `pwsh -File {0}` ou `powershell -Command \"& '{0}'\"`, dependendo da necessidade.\n\n* `cmd`\n * Parece não haver uma forma de optar totalmente por um comportamento fail-fast que não seja gravar seu script para verificar cada código de erro e reagir de acordo. Como não podemos fornecer esse comportamento por padrão, você precisa gravá-lo em seu script.\n * `cmd.exe` sairá com o nível de erro do último programa que executou e retornará o código de erro para o executor. Esse comportamento é internamente consistente com o comportamento anterior de `sh` e `pwsh` padrão e é o `cmd.exe` padrão. Portanto, esse comportamento permanece intacto.\n\n## `jobs..steps[*].with`\n\nUm `map` dos parâmetros de entrada definidos pela ação. Cada parâmetro de entrada é um par chave/valor. Parâmetros de entrada são definidos como variáveis de ambiente. A variável é precedida por `INPUT_` e convertida em letras maiúsculas.\n\nOs parâmetros de entrada definidos para um contêiner do Docker devem usar `args`. Para obter mais informações, consulte [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs).\n\n### Exemplo de `jobs..steps[*].with`\n\nDefine os três parâmetros de entrada (`first_name`, `middle_name` e `last_name`) definidos pela ação `hello_world`. Essas variáveis de entrada estarão acessíveis para a ação `hello-world` como variáveis de ambiente `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` e `INPUT_LAST_NAME`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/hello_world@main\n with:\n first_name: Mona\n middle_name: The\n last_name: Octocat\n```\n\n## `jobs..steps[*].with.args`\n\nUma `string` que define as entradas para um contêiner do Docker. O GitHub passa o `args` para o `ENTRYPOINT` do contêiner quando o contêiner é iniciado. Não há suporte para uma `array of strings` nesse parâmetro. Um único argumento que inclui espaços deve ser cercado por aspas duplas `\"\"`.\n\n### Exemplo de `jobs..steps[*].with.args`\n\n```yaml\nsteps:\n - name: Explain why this job ran\n uses: octo-org/action-name@main\n with:\n entrypoint: /bin/echo\n args: The ${{ github.event_name }} event triggered this step.\n```\n\nOs `args` são usados no lugar da instrução `CMD` em um `Dockerfile`. Se você usar `CMD` no `Dockerfile`, use as diretrizes ordenadas por preferência:\n\n1. Documente os argumentos necessários no README da ação e omita-os da instrução `CMD`.\n2. Use padrões que permitam o uso da ação sem a especificação de `args`.\n3. Se a ação expõe um sinalizador `--help` ou algo do tipo, use isso como o padrão para que a ação seja documentada automaticamente.\n\n## `jobs..steps[*].with.entrypoint`\n\nSubstitui o `ENTRYPOINT` do Docker no `Dockerfile` ou define-o se um ainda não foi especificado. Ao contrário da instrução `ENTRYPOINT` do Docker que tem um shell e um formulário executável, a palavra-chave `entrypoint` só aceita uma cadeia de caracteres individual que define o executável para execução.\n\n### Exemplo de `jobs..steps[*].with.entrypoint`\n\n```yaml\nsteps:\n - name: Run a custom command\n uses: octo-org/action-name@main\n with:\n entrypoint: /a/different/executable\n```\n\nA palavra-chave `entrypoint` destina-se a ser usada com as ações de contêiner do Docker, mas você também pode usá-la com as ações JavaScript que não definem nenhuma entrada.\n\n## `jobs..steps[*].env`\n\nDefine variáveis para etapas a serem usadas no ambiente do executor. Também é possível definir variáveis para todo o fluxo de trabalho ou para um trabalho. Para obter mais informações, consulte [`env`](#env) e [`jobs..env`](#jobsjob_idenv).\n\nQuando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá as variáveis de ambiente do trabalho e do fluxo de trabalho que tenham o mesmo nome enquanto a etapa é executada. Uma variável de ambiente definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome enquanto o trabalho é executado.\n\nAções públicas podem especificar variáveis esperadas no arquivo LEIAME. Se você estiver definindo um valor secreto ou confidencial, como uma senha ou um token, deverá definir segredos usando o contexto `secrets`. Para saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts).\n\n### Exemplo de `jobs..steps[*].env`\n\n```yaml\nsteps:\n - name: My first action\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n FIRST_NAME: Mona\n LAST_NAME: Octocat\n```\n\n## `jobs..steps[*].continue-on-error`\n\nImpede a falha de um trabalho se uma etapa não funcionar. Defina isso como `true` para permitir que um trabalho seja aprovado quando houver uma falha nessa etapa.\n\n## `jobs..steps[*].timeout-minutes`\n\nNúmero máximo de minutos para executar a etapa antes de interromper o processo. Máximo: 360 para executores hospedados em GitHub e auto-hospedados.\n\nValores fracionados não são compatíveis.\n`timeout-minutes` deve ser um número inteiro positivo.\n\n## `jobs..steps[*].background`\n\nExecuta uma etapa de forma assíncrona para que o trabalho continue para a próxima etapa sem esperar que ela seja concluída. Use `background: true` para processos de execução longa, como bancos de dados, servidores ou tarefas de monitoramento, que precisam ser executados junto com outras etapas. Você sincroniza com as etapas em segundo plano mais tarde usando [`wait`](#jobsjob_idstepswait) ou [`wait-all`](#jobsjob_idstepswait-all) interrompendo-as com [`cancel`](#jobsjob_idstepscancel).\n\nVocê pode usar `background` em etapas que usam `run` ou `uses`. Para fazer referência a uma etapa em segundo plano de [`wait`](#jobsjob_idstepswait) ou [`cancel`](#jobsjob_idstepscancel), dê-lhe um [`id`](#jobsjob_idstepsid). No máximo, 10 etapas em segundo plano podem ser executadas simultaneamente em uma única tarefa; etapas adicionais em segundo plano ficam enfileiradas até haver uma vaga livre.\n\nAs saídas e as alterações de ambiente de uma etapa em segundo plano somente ficam disponíveis após a execução de uma etapa `wait` ou `wait-all` que inclua essa etapa. Se uma etapa em segundo plano falhar, o trabalho falhará na próxima `wait` ou `wait-all` que a inclui (a menos que [`continue-on-error`](#jobsjob_idstepscontinue-on-error) esteja definida nessa etapa). Uma `wait-all` implícita é executada antes de qualquer limpeza pós-tarefa.\n\nUse `background` quando precisar de um controle refinado: iniciar um processo de execução longa (como um servidor ou banco de dados) que permaneça ativo enquanto as etapas posteriores são executadas, fazendo referência a uma etapa específica com [`wait`](#jobsjob_idstepswait) ou [`cancel`](#jobsjob_idstepscancel)ou intercalando o trabalho em segundo plano com outras etapas. Se, em vez disso, você tiver um grupo independente de etapas que devam ser concluídas antes que o trabalho continue, [`parallel`](#jobsjob_idstepsparallel) é uma forma abreviada mais conveniente.\n\n> \\[!NOTE]\n> Você não pode usar `background` em etapas dentro de uma ação composta. Uma ação composta pode ser executada como uma etapa em segundo plano, mas não pode declarar etapas em segundo plano internamente.\n\n### Exemplo: executando uma etapa em segundo plano\n\n```yaml\nsteps:\n - name: Start server\n id: server\n run: npm start\n background: true\n\n - name: Run tests against the server\n run: npm test\n\n - name: Wait for the server step to finish\n wait: server\n```\n\n## `jobs..steps[*].wait`\n\nPausa o trabalho até que uma ou mais etapas em segundo plano sejam concluídas. Uma `wait` etapa não executa nenhum trabalho em si, ela só é bloqueada até que as etapas em segundo plano referenciadas sejam concluídas. Forneça uma única etapa `id` como uma cadeia de caracteres ou várias etapas `id`como uma matriz.\n\nApós a conclusão de uma etapa `wait`, as saídas das etapas em segundo plano referenciadas tornam-se disponíveis para as etapas subsequentes. Se uma etapa em segundo plano referenciada falhar, a `wait` etapa também falhará.\n\n> \\[!NOTE]\n> Uma `wait` etapa sempre é executada e não oferece suporte à condicional [`if`](#jobsjob_idstepsif).\n\n### Exemplo: aguardando etapas específicas em segundo plano\n\n```yaml\nsteps:\n - name: Build frontend\n id: build-frontend\n run: npm run build:frontend\n background: true\n\n - name: Build backend\n id: build-backend\n run: npm run build:backend\n background: true\n\n - name: Run linter while builds run\n run: npm run lint\n\n - name: Wait for both builds to finish\n wait: [build-frontend, build-backend]\n\n - name: Run tests\n run: npm test\n```\n\n## `jobs..steps[*].wait-all`\n\nPausa o trabalho até que todas as etapas em segundo plano ativas sejam concluídas. Isso é útil quando várias etapas em segundo plano estão em execução e você deseja que todas elas sejam concluídas antes de continuar. Assim como `wait`, a etapa `wait-all` falhará se qualquer uma das etapas em segundo plano das quais ela depende falhar, a menos que você defina [`continue-on-error`](#jobsjob_idstepscontinue-on-error) como `true`.\n\nA `wait-all` palavra-chave não usa argumentos.\n\n> \\[!NOTE]\n> Uma `wait-all` etapa sempre é executada e não oferece suporte à condicional [`if`](#jobsjob_idstepsif).\n\n### Exemplo: aguardando todas as etapas em segundo plano\n\n```yaml\nsteps:\n - name: Start database\n id: db\n run: docker run -d postgres:15\n background: true\n\n - name: Start cache\n id: cache\n run: docker run -d redis:7\n background: true\n\n - name: Run integration tests\n run: npm run test:integration\n\n - name: Wait for all services to stop\n wait-all:\n```\n\n## `jobs..steps[*].cancel`\n\nEncerra de forma controlada uma etapa em segundo plano em execução. O executor envia ao processo da etapa um sinal de terminação (`SIGTERM`) para que ele possa limpar e o interrompe à força (`SIGKILL`) se ele não sair em um curto período de carência. A palavra-chave `cancel` tem como alvo uma única etapa de segundo plano pelo seu `id`.\n\n> \\[!NOTE]\n> Uma `cancel` etapa sempre é executada e não oferece suporte à condicional [`if`](#jobsjob_idstepsif).\n\n### Exemplo: Cancelando uma etapa em segundo plano\n\n```yaml\nsteps:\n - name: Start long-running monitor\n id: monitor\n run: ./scripts/monitor.sh\n background: true\n\n - name: Run the main task\n run: npm test\n\n - name: Stop the monitor\n cancel: monitor\n```\n\n## `jobs..steps[*].parallel`\n\nExecuta um grupo de etapas simultaneamente e aguarda que todas elas sejam concluídas antes de continuar. A palavra-chave `parallel` é uma forma abreviada: cada etapa do grupo é executada em segundo plano, com um `wait` implícito no final do grupo. Use-o quando você tiver um grupo independente de etapas que possa ser executado ao mesmo tempo e não precisar referenciá-las individualmente.\n\nUse `parallel` quando houver um grupo independente de etapas em que todas devem ser concluídas antes que a tarefa prossiga, como criar vários componentes de uma só vez. Use [`background`](#jobsjob_idstepsbackground) quando precisar de um controle mais fino: iniciar um processo de execução longa (como um servidor ou banco de dados) que permaneça ativo enquanto as etapas posteriores são executadas, fazendo referência a uma etapa específica com [`wait`](#jobsjob_idstepswait) ou [`cancel`](#jobsjob_idstepscancel)ou intercalando o trabalho em segundo plano com outras etapas. Em suma, `parallel` é mais limitado, mas mais conveniente para o caso de \"executar este grupo de uma só vez\", enquanto `background` é a primitiva de uso geral.\n\nCada etapa do grupo está sujeita ao mesmo limite de simultaneidade de 10 etapas aplicado às outras etapas em segundo plano.\n\n> \\[!NOTE]\n> Você não pode usar `parallel` dentro de uma ação composta.\n\n### Exemplo: executando etapas em paralelo\n\n```yaml\nsteps:\n - uses: actions/checkout@v6\n\n - parallel:\n - name: Build frontend\n run: npm run build:frontend\n\n - name: Build backend\n run: npm run build:backend\n\n - name: Build docs\n run: npm run build:docs\n\n - name: Run tests after all builds complete\n run: npm test\n```\n\nO grupo acima é equivalente a declarar cada etapa com `background: true`, seguida por uma etapa `wait`.\n\n## `jobs..timeout-minutes`\n\nO número máximo de minutos para permitir que o trabalho seja executado antes que GitHub o cancele automaticamente. Padrão: 360\n\nSe o tempo-limite exceder o tempo limite de execução do trabalho para o executor, o trabalho será cancelado quando o tempo limite de execução for atingido. Para obter mais informações sobre os limites de tempo de execução de trabalho, consulte [Cobrança e uso](/pt/actions/concepts/billing-and-usage#usage-limits-and-policy) para executores hospedados em GitHub e, para limites de uso de executores auto-hospedados, consulte [Limites do Actions](/pt/actions/reference/limits).\n\n> \\[!NOTE]\n> O `GITHUB_TOKEN` expira quando um trabalho é concluído ou após, no máximo, 24 horas. Para executores auto-hospedados, o token pode ser o fator limitante se o tempo limite do trabalho for maior que 24 horas. Para obter mais informações sobre `GITHUB_TOKEN`, consulte [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/tutorials/authenticate-with-github_token).\n\n## `jobs..strategy`\n\nCom o `jobs..strategy` você usa uma estratégia de matriz para seus trabalhos.\nUma estratégia de matriz permite que você use variáveis em uma única definição de trabalho para criar automaticamente várias execuções de trabalho baseadas nas combinações das variáveis. Por exemplo, você pode usar uma estratégia de matriz para testar seu código em várias versões de um idioma ou em vários sistemas operacionais. Para obter mais informações, consulte [Executando variações de tarefas em um workflow](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\n## `jobs..strategy.matrix`\n\nUse `jobs..strategy.matrix` para definir uma matriz de diferentes configurações de trabalho. Para saber mais, confira [Executando variações de tarefas em um workflow](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\nUma matriz pode gerar 256 tarefas no máximo por execução do fluxo de trabalho. Esse limite se aplica a executores hospedados em GitHub e auto-hospedados.\n\nAs variáveis que você define se tornam propriedades no contexto `matrix`, e você pode referenciar a propriedade em outras áreas do arquivo de fluxo de trabalho. Neste exemplo, você pode usar `matrix.version` e `matrix.os` para acessar o valor atual de `version` e `os` que o trabalho está usando. Para saber mais, confira [Referência de contextos](/pt/actions/reference/workflows-and-actions/contexts).\n\nPor padrão, GitHub maximizará o número de trabalhos executados em paralelo, dependendo da disponibilidade do executor. A ordem das variáveis na matriz determina a ordem na qual os trabalhos são criados. A primeira variável definida será o primeiro trabalho criado na execução do fluxo de trabalho.\n\n### Como usar uma matriz unidimensional\n\nO fluxo de trabalho a seguir define a variável `version` com os valores `[10, 12, 14]`. O fluxo de trabalho executará três trabalhos, um para cada valor na variável. Cada trabalho acessará o valor `version` por meio do contexto `matrix.version` e passará o valor como `node-version` à ação `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n version: [10, 12, 14]\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.version }}\n```\n\n### Como usar uma matriz multidimensional\n\nEspecifique diversas variáveis para criar uma matriz multidimensional. Um trabalho será executado para cada combinação possível das variáveis.\n\nPor exemplo, o fluxo de trabalho a seguir especifica duas variáveis:\n\n* Dois sistemas operacionais especificados na variável `os`\n* Três versões do Node.js especificadas na variável `version`\n\nO fluxo de trabalho executará seis trabalhos, um para cada combinação entre as variáveis `os` e `version`. Cada trabalho definirá o valor `runs-on` como o valor atual `os` e passará o valor atual `version` para a ação `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [ubuntu-22.04, ubuntu-24.04]\n version: [10, 12, 14]\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.version }}\n```\n\nUma configuração variável em uma matriz pode ser um `array` de `object`s. Por exemplo, a matriz a seguir produz quatro trabalhos com contextos correspondentes.\n\n```yaml\nmatrix:\n os:\n - ubuntu-latest\n - macos-latest\n node:\n - version: 14\n - version: 20\n env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\nCada trabalho na matriz terá uma combinação própria de valores `os` e `node`, como mostrado abaixo.\n\n```yaml\n- matrix.os: ubuntu-latest\n matrix.node.version: 14\n- matrix.os: ubuntu-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n- matrix.os: macos-latest\n matrix.node.version: 14\n- matrix.os: macos-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n## `jobs..strategy.matrix.include`\n\nPara cada objeto na lista `include`, os pares key:value no objeto serão adicionados a cada uma das combinações de matriz se nenhum dos pares key:value substituir qualquer um dos valores de matriz originais. Se o objeto não puder ser adicionado a nenhuma das combinações de matriz, uma nova combinação de matriz será criada. Observe que os valores de matriz originais não serão substituídos, mas os valores de matriz adicionados podem ser substituídos.\n\n### Exemplo: expandindo configurações\n\nPor exemplo, o fluxo de trabalho a seguir executará quatro trabalhos, um para cada combinação de `os` e `node`. Quando o trabalho para o valor `os` de `windows-latest` e valor `node` as execuções `16`, uma variável adicional chamada `npm` com o valor de `6` será incluída no trabalho.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [windows-latest, ubuntu-latest]\n node: [14, 16]\n include:\n - os: windows-latest\n node: 16\n npm: 6\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v7\n with:\n node-version: ${{ matrix.node }}\n - if: ${{ matrix.npm }}\n run: npm install -g npm@${{ matrix.npm }}\n - run: npm --version\n```\n\n### Exemplo: adicionando configurações\n\nPor exemplo, essa matriz executará dez trabalhos, um para cada combinação de `os` e `version` na matriz, além de um trabalho para o valor `os` de `windows-latest` e o valor `version` de `17`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [macos-latest, windows-latest, ubuntu-latest]\n version: [12, 14, 16]\n include:\n - os: windows-latest\n version: 17\n```\n\nSe você não especificar nenhuma variável de matriz, todas as configurações abaixo de `include` serão executadas. Por exemplo, o fluxo de trabalho a seguir executaria dois trabalhos, um para cada entrada `include`. Isso permite que você aproveite a estratégia de matriz sem ter uma matriz totalmente populada.\n\n```yaml\njobs:\n includes_only:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n include:\n - site: \"production\"\n datacenter: \"site-a\"\n - site: \"staging\"\n datacenter: \"site-b\"\n```\n\n## `jobs..strategy.matrix.exclude`\n\nUma configuração excluída só precisa ser uma correspondência parcial para que ela seja excluída.\n\nTodas as combinações de `include` são processadas após `exclude`. Isso permite que você use `include` para adicionar combinações anteriores que já foram excluídas.\n\n## `jobs..strategy.fail-fast`\n\nVocê pode controlar como as falhas de trabalho são tratadas com `jobs..strategy.fail-fast` e `jobs..continue-on-error`.\n\n`jobs..strategy.fail-fast` aplica-se a toda a matriz. Se `jobs..strategy.fail-fast` estiver definido como `true` ou sua expressão for avaliada como `true`, o GitHub cancelará todos os trabalhos em andamento e enfileirados na matriz se algum trabalho na matriz falhar. Essa propriedade tem como padrão `true`.\n\n`jobs..continue-on-error` aplica-se a um único trabalho. Se `jobs..continue-on-error` for `true`, outros trabalhos na matriz continuarão em execução mesmo que o trabalho com `jobs..continue-on-error: true` falhe.\n\nVocê não pode usar `jobs..strategy.fail-fast` e `jobs..continue-on-error` juntos. Por exemplo, o fluxo de trabalho a seguir iniciará quatro trabalhos. Para cada trabalho, `continue-on-error` é determinado pelo valor de `matrix.experimental`. Se algum dos trabalhos com `continue-on-error: false` falhar, todos os trabalhos em andamento ou enfileirados serão cancelados. Se o trabalho com `continue-on-error: true` falhar, os outros trabalhos não serão afetados.\n\n```yaml\njobs:\n test:\n runs-on: ubuntu-latest\n continue-on-error: ${{ matrix.experimental }}\n strategy:\n fail-fast: true\n matrix:\n version: [6, 7, 8]\n experimental: [false]\n include:\n - version: 9\n experimental: true\n```\n\n## `jobs..strategy.max-parallel`\n\nPor padrão, GitHub maximizará o número de trabalhos executados em paralelo, dependendo da disponibilidade do executor.\n\n## `jobs..continue-on-error`\n\n`jobs..continue-on-error` aplica-se a um único trabalho. Se `jobs..continue-on-error` for `true`, outros trabalhos na matriz continuarão em execução mesmo que o trabalho com `jobs..continue-on-error: true` falhe.\n\nImpede que ocorra falha na execução de um fluxo de trabalho quando ocorrer uma falha em um trabalho. Defina isso como `true` para permitir que uma execução de fluxo de trabalho seja aprovada quando houver uma falha nesse trabalho.\n\n### Exemplo: Evitando uma falha específica na matriz de trabalho por falha na execução de um fluxo de trabalho\n\nVocê pode permitir que as tarefas específicas em uma matriz de tarefas falhem sem que ocorra falha na execução do fluxo de trabalho. Por exemplo, caso deseje permitir apenas um trabalho experimental com o `node` definido como `15` para falhar sem falhar a execução de fluxo de trabalho.\n\n```yaml\nruns-on: ${{ matrix.os }}\ncontinue-on-error: ${{ matrix.experimental }}\nstrategy:\n fail-fast: false\n matrix:\n node: [13, 14]\n os: [macos-latest, ubuntu-latest]\n experimental: [false]\n include:\n - node: 15\n os: ubuntu-latest\n experimental: true\n```\n\n## `jobs..container`\n\n> \\[!NOTE]\n> Se os fluxos de trabalho usarem ações de contêiner do Docker, contêineres de trabalho ou contêineres de serviço, você precisará usar um executor do Linux:\n>\n> * Se você estiver usando executores hospedados em GitHub, você deverá usar um executor do Ubuntu.\n> * Se você estiver usando executores auto-hospedados, você deve usar uma máquina Linux, pois seu executor e o Docker precisam ser instalados.\n\nUse `jobs..container` para criar um contêiner e executar as etapas de um trabalho que ainda não especificam um contêiner. Se você tiver etapas que usam ações de script e de contêiner, as ações de contêiner serão executadas como contêineres irmãos na mesma rede e com as mesmas montagens de volume.\n\nSe você não definir um `container`, todas as etapas serão executadas diretamente no host especificado por `runs-on`, a menos que uma etapa se refira a uma ação configurada para ser executada em um contêiner.\n\n> \\[!NOTE]\n> O shell padrão para etapas `run` dentro de um contêiner é `sh` em vez de `bash`. Isso pode ser substituído por [`jobs..defaults.run`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun) ou por [`jobs..steps[*].shell`](/pt/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell).\n\n### Exemplo: Executar um trabalho dentro de um contêiner\n\n```yaml copy\nname: CI\non:\n push:\n branches: [ main ]\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container:\n image: node:18\n env:\n NODE_ENV: development\n ports:\n - 80\n volumes:\n - my_docker_volume:/volume_mount\n options: --cpus 1\n steps:\n - name: Check for dockerenv file\n run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nQuando você especifica apenas uma imagem de contêiner, pode omitir a palavra-chave `image`.\n\n```yaml\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container: node:18\n```\n\n## `jobs..container.image`\n\nUse `jobs..container.image` para definir a imagem do Docker a ser usada como o contêiner para executar a ação. O valor pode ser o nome da imagem do Docker Hub ou um nome de registro.\n\n> \\[!NOTE]\n> O Docker Hub normalmente impõe limites de taxa em operações de push e pull, o que afetará os trabalhos em executores auto-hospedados. No entanto, executores hospedados pelo GitHub não estão sujeitos a esses limites com base em um contrato entre o GitHub e o Docker.\n\n## `jobs..container.credentials`\n\nSe o registro de contêiner da imagem exigir autenticação para efetuar pull da imagem, use `jobs..container.credentials` para definir um `map` do `username` e da `password`. As credenciais são os mesmos valores que você fornecerá ao comando [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Exemplo: Definindo credenciais para o registro de um contêiner\n\n```yaml\ncontainer:\n image: ghcr.io/owner/image\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n```\n\n## `jobs..container.env`\n\nUse `jobs..container.env` para definir um `map` das variáveis de ambiente no contêiner.\n\n## `jobs..container.ports`\n\nUse `jobs..container.ports` para definir uma `array` das portas a serem expostas no contêiner.\n\n## `jobs..container.volumes`\n\nUse `jobs..container.volumes` para definir uma `array` de volumes para uso do contêiner. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.\n\nPara especificar um volume, especifique o caminho de origem e destino:\n\n`:`.\n\n`` é um nome de volume ou um caminho absoluto no computador host, e `` é um caminho absoluto no contêiner.\n\n### Exemplo: Montando volumes em um contêiner\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..container.options`\n\nUse `jobs..container.options` para configurar opções adicionais de recurso de contêiner do Docker. Para ver uma lista de opções, confira [Opções de `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> As opções `--network` e `--entrypoint` não têm suporte.\n\n## `jobs..services`\n\n> \\[!NOTE]\n> Se os fluxos de trabalho usarem ações de contêiner do Docker, contêineres de trabalho ou contêineres de serviço, você precisará usar um executor do Linux:\n>\n> * Se você estiver usando executores hospedados em GitHub, você deverá usar um executor do Ubuntu.\n> * Se você estiver usando executores auto-hospedados, você deve usar uma máquina Linux, pois seu executor e o Docker precisam ser instalados.\n\nUsado para hospedar contêineres de serviço para um trabalho em um fluxo de trabalho. Contêineres de serviço são úteis para a criação de bancos de dados ou serviços armazenamento em cache como o Redis. O executor cria automaticamente uma rede do Docker e gerencia o ciclo de vida dos contêineres do serviço.\n\nSe você configurar seu trabalho para ser executado em um contêiner, ou a sua etapa usar ações ao contêiner, você não precisará mapear as portas para acessar o serviço ou a ação. O Docker expõe automaticamente todas as portas entre os contêineres da mesma rede de ponte definida pelo usuário. Você pode fazer referência ao contêiner de serviço diretamente pelo seu nome de host. O nome do host é mapeado automaticamente com o nome da etiqueta que você configurar para o serviço no fluxo de trabalho.\n\nSe você configurar a tarefa para executar diretamente na máquina do executor e sua etapa não usar uma ação de contêiner, você deverá mapear todas as portas de contêiner de serviço do Docker necessárias para o host do Docker (a máquina do executor). Você pode acessar o contêiner de serviço usando host local e a porta mapeada.\n\nPara obter mais informações sobre as diferenças entre os contêineres de serviço de rede, consulte [Comunicar-se com os contêineres de serviço do Docker](/pt/actions/tutorials/use-containerized-services/use-docker-service-containers).\n\n### Exemplo: Usando host local\n\nEste exemplo cria dois serviços: nginx e redis. Quando você especifica a porta do contêiner, mas não a porta do host, a porta do contêiner é atribuída aleatoriamente a uma porta livre no host.\nGitHub define a porta de host atribuída no contexto `${{job.services..ports}}`. Neste exemplo, você pode acessar as portas de host de serviço usando os `${{ job.services.nginx.ports['80'] }}` e `${{ job.services.redis.ports['6379'] }}` contextos.\n\n```yaml\nservices:\n nginx:\n image: nginx\n # Map port 8080 on the Docker host to port 80 on the nginx container\n ports:\n - 8080:80\n redis:\n image: redis\n # Map random free TCP port on Docker host to port 6379 on redis container\n ports:\n - 6379/tcp\nsteps:\n - run: |\n echo \"Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}\"\n echo \"Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}\"\n```\n\n## `jobs..services..image`\n\nImagem Docker a ser usada como contêiner de serviço para executar a ação. O valor pode ser o nome da imagem do Docker Hub ou um nome de registro.\n\nSe uma sequência vazia for atribuída a `jobs..services..image`, o serviço não será iniciado. Você pode usar essa condição para configurar serviços condicionais, conforme o exemplo a seguir.\n\n```yaml\nservices:\n nginx:\n image: ${{ options.nginx == true && 'nginx' || '' }}\n```\n\n## `jobs..services..credentials`\n\nSe o registro de contêiner da imagem exigir autenticação para efetuar pull da imagem, use `jobs..container.credentials` para definir um `map` do `username` e da `password`. As credenciais são os mesmos valores que você fornecerá ao comando [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Exemplo de `jobs..services..credentials`\n\n```yaml\nservices:\n myservice1:\n image: ghcr.io/owner/myservice1\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n myservice2:\n image: dockerhub_org/myservice2\n credentials:\n username: ${{ secrets.DOCKER_USER }}\n password: ${{ secrets.DOCKER_PASSWORD }}\n```\n\n## `jobs..services..env`\n\nDefine um `map` das variáveis de ambiente no contêiner de serviço.\n\n## `jobs..services..ports`\n\nDefine uma `array` de portas a serem expostas no contêiner de serviço.\n\n## `jobs..services..volumes`\n\nDefine uma `array` de volumes para uso do contêiner de serviço. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.\n\nPara especificar um volume, especifique o caminho de origem e destino:\n\n`:`.\n\n`` é um nome de volume ou um caminho absoluto no computador host, e `` é um caminho absoluto no contêiner.\n\n### Exemplo de `jobs..services..volumes`\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..services..options`\n\nOpções adicionais de recursos do contêiner Docker. Para obter uma lista de opções, consulte [`docker create` opções](https://docs.docker.com/engine/reference/commandline/create/#options).\n\n> \\[!WARNING]\n> Não há suporte para a opção `--network`.\n\n## `jobs..services..command`\n\nSubstitui o comando padrão da imagem do Docker (`CMD`). O valor é passado como argumentos após o nome da imagem no `docker create` comando. Se você também especificar `entrypoint`, `command` fornecerá os argumentos para esse ponto de entrada.\n\n### Exemplo de `jobs..services..command`\n\n```yaml\nservices:\n mysql:\n image: mysql:8\n command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n env:\n MYSQL_ROOT_PASSWORD: test\n ports:\n - 3306:3306\n```\n\n## `jobs..services..entrypoint`\n\nSubstitui o padrão `ENTRYPOINT` da imagem do Docker. O valor é uma única cadeia de caracteres que define o executável a ser executado. Use isso quando precisar substituir totalmente o ponto de entrada da imagem. Você pode combinar `entrypoint` com `command` para passar argumentos para o ponto de entrada personalizado.\n\n### Exemplo de `jobs..services..entrypoint`\n\n```yaml\nservices:\n etcd:\n image: quay.io/coreos/etcd:v3.5.17\n entrypoint: etcd\n command: >-\n --listen-client-urls http://0.0.0.0:2379\n --advertise-client-urls http://0.0.0.0:2379\n ports:\n - 2379:2379\n```\n\n## `jobs..uses`\n\nO local e a versão de um arquivo de fluxo de trabalho reutilizável para ser executado como trabalho. Use uma das seguintes sintaxes:\n\n* `$/.github/workflows/{filename}` para um fluxo de trabalho reutilizável no mesmo repositório. Essa é a sintaxe recomendada para referenciar um fluxo de trabalho reutilizável no mesmo repositório. Essa sintaxe não está disponível em GitHub Enterprise Server.\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` para fluxos de trabalho reutilizáveis em repositórios públicos e privados.\n* `./.github/workflows/{filename}` para fluxos de trabalho reutilizáveis no mesmo repositório.\n\nQuando você faz referência a um fluxo de trabalho reutilizável com `{owner}/{repo}` e `@{ref}`, pode `{ref}` ser um SHA, uma marca de versão ou um nome de branch. Se uma tag de release e uma ramificação tiverem o mesmo nome, a tag de release terá precedência sobre o nome da ramificação. Usar o commit SHA é a opção mais segura para fins de estabilidade e segurança. Para saber mais, confira [Referência de uso seguro](/pt/actions/reference/security/secure-use#reusing-third-party-workflows).\n\nQuando você faz referência a um fluxo de trabalho reutilizável no mesmo repositório usando `$/` ou `./` (sem `{owner}/{repo}` e `@{ref}`), o fluxo de trabalho chamado é da mesma confirmação que o fluxo de trabalho do chamador. Uma `$/` referência não deve incluir um `@{ref}` sufixo e `$/` não está disponível em GitHub Enterprise Server. Prefixos de referência como `refs/heads` e `refs/tags` não são permitidos. Você não pode usar contextos ou expressões nesta palavra-chave.\n\n### Exemplo de `jobs..uses`\n\n```yaml\njobs:\n call-workflow-1-in-local-repo:\n uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n call-workflow-2-in-local-repo:\n uses: ./.github/workflows/workflow-2.yml\n # The `$/` syntax is not available in GitHub Enterprise Server.\n call-workflow-in-same-repo-at-running-commit:\n uses: $/.github/workflows/workflow-2.yml\n call-workflow-in-another-repo:\n uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\nPara saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n\n## `jobs..with`\n\nQuando um trabalho é usado para chamar um fluxo de trabalho reutilizável, você pode usar `with` para fornecer um mapa das entradas que são transmitidas para o fluxo de trabalho chamado.\n\nQualquer entrada que você passe deve corresponder às especificações de entrada definidas no fluxo de trabalho de chamada.\n\nAo contrário de [`jobs..steps[*].with`](#jobsjob_idstepswith), as entradas transmitidas com `jobs..with` não estão disponíveis como variáveis de ambiente no fluxo de trabalho chamado. Você pode referenciar as entradas usando o contexto `inputs`.\n\n### Exemplo de `jobs..with`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n with:\n username: mona\n```\n\n## `jobs..with.`\n\nUm par composto de um identificador de string para a entrada e o valor da entrada. O identificador precisa corresponder ao nome de uma entrada definida por [`on.workflow_call.inputs.`](/pt/actions/reference/workflows-and-actions/metadata-syntax#inputsinput_id) no fluxo de trabalho chamado. O tipo de dados do valor precisa corresponder ao tipo definido por [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) no fluxo de trabalho chamado.\n\nContextos de expressão permitidos: `github` e `needs`.\n\n## `jobs..secrets`\n\nQuando um trabalho é usado para chamar um fluxo de trabalho reutilizável, você pode usar `secrets` para fornecer um mapa de segredos que são transmitidos para o fluxo de trabalho chamado.\n\nQualquer segredo que você passar deve corresponder aos nomes definidos no fluxo de trabalho chamado.\n\n### Exemplo de `jobs..secrets`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n secrets:\n access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n```\n\n## `jobs..secrets.inherit`\n\nUse a palavra-chave `inherit` para passar todos os segredos do fluxo de trabalho que faz a chamada para o fluxo de trabalho chamado. Isso inclui todos os segredos aos quais o fluxo de trabalho que faz a chamada tem acesso, ou seja, segredos de organização, repositório e ambiente. A palavra-chave `inherit` pode ser usada para passar segredos entre repositórios dentro da mesma organização ou entre organizações dentro da mesma empresa.\n\n### Exemplo de `jobs..secrets.inherit`\n\n```yaml\non:\n workflow_dispatch:\n\njobs:\n pass-secrets-to-workflow:\n uses: ./.github/workflows/called-workflow.yml\n secrets: inherit\n```\n\n```yaml\non:\n workflow_call:\n\njobs:\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n - name: Use a repo or org secret from the calling workflow.\n run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}\n```\n\n## `jobs..secrets.`\n\nUm par composto por um identificador string para o segredo e o valor do segredo. O identificador precisa corresponder ao nome de um segredo definido por [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id) no fluxo de trabalho chamado.\n\nContextos de expressão permitidos: `github`, `needs` e `secrets`.\n\n## Folha de dados de padrão de filtro\n\nVocê pode usar caracteres especiais nos filtros de caminhos, branches e tags.\n\n* `*`: corresponde a zero ou mais caracteres, mas não corresponde ao caractere `/`. Por exemplo, `Octo*` corresponde a `Octocat`.\n* `**`: corresponde a zero ou mais de qualquer caractere.\n* `?`: corresponde a zero ou a um dos caracteres anteriores.\n* `+`: corresponde a um ou mais dos caracteres anteriores.\n* `[]`: corresponde a um caractere alfanumérico listado entre colchetes ou incluído nos intervalos. Os intervalos só podem incluir `a-z`, `A-Z` e `0-9`. Por exemplo, o intervalo `[0-9a-z]` corresponde a qualquer dígito ou letra minúscula. Por exemplo, `[CB]at` corresponde a `Cat` ou `Bat` e `[1-2]00` correspondem a `100` e a `200`.\n* `!`: no início de um padrão, faz com que ele anule os padrões positivos anteriores. Não tem nenhum significado especial caso não seja o primeiro caractere.\n\nOs caracteres `*`, `[` e `!` são caracteres especiais no YAML. Se você iniciar um padrão com `*`, `[` ou `!`, precisará colocar o padrão entre aspas. Além disso, se você usar uma [sequência de fluxo](https://yaml.org/spec/1.2.2/#flow-sequences) com um padrão contendo `[` e/ou `]`, o padrão deverá estar entre aspas.\n\n```yaml\n# Valid\npaths:\n - '**/README.md'\n\n# Invalid - creates a parse error that\n# prevents your workflow from running.\npaths:\n - **/README.md\n\n# Valid\nbranches: [ main, 'release/v[0-9].[0-9]' ]\n\n# Invalid - creates a parse error\nbranches: [ main, release/v[0-9].[0-9] ]\n```\n\nPara obter mais informações sobre a sintaxe de filtro de ramificação, marca e caminho, consulte [`on..`](#onpushbranchestagsbranches-ignoretags-ignore), [`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore) e [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore).\n\n### Padrões para corresponder branches e tags\n\n| Padrão | Descrição | Correspondências de exemplo |\n| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |\n| `feature/*` | O curinga `*` corresponde a qualquer caractere, mas não à barra (`/`). | `feature/my-branch`

`feature/your-branch` |\n| `feature/**` | O curinga `**` corresponde a qualquer caractere, incluindo a barra (`/`) em nomes de branches e marcas. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` |\n| `main`

`releases/mona-the-octocat` | Corresponde ao nome exato de um branch ou tag. | `main`

`releases/mona-the-octocat` |\n| `'*'` | Corresponde a todos os nomes de branches e marcas que não contêm uma barra (`/`). O caractere `*` é um caractere especial no YAML. Ao inciar um padrão com `*`, você precisa usar aspas. | `main`

`releases` |\n| `'**'` | Corresponde a todos os nomes de branches e tags. Esse é o comportamento padrão quando um filtro `branches` ou `tags` não é usado. | `all/the/branches`

`every/tag` |\n| `'*feature'` | O caractere `*` é um caractere especial no YAML. Ao inciar um padrão com `*`, você precisa usar aspas. | `mona-feature`

`feature`

`ver-10-feature` |\n| `v2*` | Corresponde aos nomes de branches e marcas que começam com `v2`. | `v2`

`v2.0`

`v2.9` |\n| `v[12].[0-9]+.[0-9]+` | Corresponde a todas as marcas e a todos os branches de controle de versão semântica com a versão principal 1 ou 2. | `v1.10.1`

`v2.0.0` |\n\n### Padrões para corresponder a caminhos de arquivos\n\nPadrões de caminhos devem corresponder ao caminho completo e iniciar a partir da raiz do repositório.\n\n| Padrão | Descrição das correspondências | Correspondências de exemplo |\n| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `'*'` | O curinga `*` corresponde a qualquer caractere, mas não à barra (`/`). O caractere `*` é um caractere especial no YAML. Ao inciar um padrão com `*`, você precisa usar aspas. | `README.md`

`server.rb` |\n| `'*.jsx?'` | O caractere `?` corresponde a zero ou um dos caracteres anteriores. | `page.js`

`page.jsx` |\n| `'**'` | O curinga `**` corresponde a qualquer caractere, incluindo a barra (`/`). Esse é o comportamento padrão quando um filtro `path` não é usado. | `all/the/files.md` |\n| `'*.js'` | O curinga `*` corresponde a qualquer caractere, mas não à barra (`/`). Corresponde a todos os arquivos `.js` na raiz do repositório. | `app.js`

`index.js` |\n| `'**.js'` | Corresponde a todos os arquivos `.js` do repositório. | `index.js`

`js/index.js`

`src/js/app.js` |\n| `docs/*` | Somente os arquivos localizados na raiz do diretório `docs`, na raiz do repositório. | `docs/README.md`

`docs/file.txt` |\n| `docs/**` | Qualquer arquivo no diretório `docs` e seus subdiretórios na raiz do repositório. | `docs/README.md`

`docs/mona/octocat.txt` |\n| `docs/**/*.md` | Um arquivo com um sufixo `.md` em qualquer lugar do diretório `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` |\n| `'**/docs/**'` | Qualquer arquivo no diretório `docs`, em qualquer lugar do repositório. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` |\n| `'**/README.md'` | Um arquivo README.md em qualquer local do repositório. | `README.md`

`js/README.md` |\n| `'**/*src/**'` | Qualquer arquivo em uma pasta com o sufixo `src` em qualquer lugar do repositório. | `a/src/app.js`

`my-src/code/js/app.js` |\n| `'**/*-post.md'` | Um arquivo com o sufixo `-post.md` em qualquer lugar no repositório. | `my-post.md`

`path/their-post.md` |\n| `'**/migrate-*.sql'` | Um arquivo com o prefixo `migrate-` e o sufixo `.sql` em qualquer lugar no repositório. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` |\n| `'*.md'`

`'!README.md'` | O uso de um sinal de exclamação (`!`) na frente de um padrão o anula. Quando um arquivo corresponde a um padrão e também corresponde a um padrão negativo definido posteriormente no arquivo, o arquivo não será incluído. | `hello.md`

|\n| *Não corresponde a*

`README.md`

`docs/hello.md` | | |\n| `'*.md'`

`'!README.md'`

`README*` | Os padrões são verificados sequencialmente. Um padrão que anula um padrão anterior irá incluir caminhos de arquivos novamente. | `hello.md`

`README.md`

`README.doc` |"}