{"meta":{"title":"Reutilizando configurações de fluxo de trabalho","intro":"Encontre informações sobre como evitar a duplicação ao criar um fluxo de trabalho reutilizando fluxos de trabalho existentes e usando âncoras e aliases YAML.","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/reusing-workflow-configurations","title":"Reutilizando configurações de fluxo de trabalho"}],"documentType":"article"},"body":"# Reutilizando configurações de fluxo de trabalho\n\nEncontre informações sobre como evitar a duplicação ao criar um fluxo de trabalho reutilizando fluxos de trabalho existentes YAML.\n\n## Fluxos de trabalho reutilizáveis\n\nInformações de referência para fluxos de trabalho reutilizáveis.\n\n### Acesso a fluxos de trabalho reutilizáveis\n\nUm fluxo de trabalho reutilizável pode ser usado por outro fluxo de trabalho se qualquer uma das seguintes opções for verdadeira:\n\n* Ambos os fluxos de trabalho estão no mesmo repositório.\n* O fluxo de trabalho chamado é armazenado em um repositórioe sua  empresarialpermite que você use fluxos de trabalho reutilizáveis públicos.\n* O fluxo de trabalho chamado é armazenado em um repositório privado e as configurações desse repositório permitem que ele seja acessado. Para obter mais informações, consulte [Compartilhamento de ações e fluxos de trabalho com sua organização](/pt/actions/creating-actions/sharing-actions-and-workflows-with-your-organization) e [Compartilhamento de ações e fluxos de trabalho de seu repositório privado](/pt/actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository).\n\nA tabela a seguir mostra a acessibilidade de fluxos de trabalho reutilizáveis a um fluxo de trabalho do chamador, dependendo da visibilidade do repositório do host.\n\n| Repositório do chamador | Repositórios de fluxos de trabalho acessíveis |\n| ----------------------- | --------------------------------------------- |\n| `private`               |                                               |\n| `private`               |                                               |\n| e`public`               |                                               |\n|                         |                                               |\n| `public`                | `public`                                      |\n\nAs **permissões de ações** na página de configurações de ações do repositório do chamador devem ser configuradas para permitir o uso de ações e fluxos de trabalho reutilizáveis; 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#allowing-select-actions-and-reusable-workflows-to-run).\n\nPara privados, é necessário configurar explicitamente a política de **Acesso** na página de configurações de Ações do repositório do fluxo de trabalho chamado, permitindo o acesso por repositórios que contenham fluxos de trabalho de origem — 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#allowing-access-to-components-in-a-private-repository).\n\n> \\[!NOTE]\n> Para aprimorar a segurança, o GitHub Actions não dá suporte a redirecionamentos de ações nem a fluxos de trabalho reutilizáveis. Isso significa que quando o proprietário, o nome do repositório de uma ação ou o nome da ação é alterado, todos os fluxos de trabalho que usarem essa ação com o nome anterior falharão.\n\n### Limitações de fluxos de trabalho reutilizáveis\n\n* Você pode conectar até dez níveis de fluxos de trabalho. Para obter mais informações, confira [Aninhar fluxos de trabalho reutilizáveis](/pt/actions/how-tos/sharing-automations/reuse-workflows#nesting-reusable-workflows).\n\n* Você pode chamar até 50 fluxos de trabalho reutilizáveis exclusivos por meio de um só arquivo de fluxo de trabalho. Esse limite inclui árvores de fluxos de trabalho aninhados reutilizáveis que podem ser chamados começando do arquivo de fluxo de trabalho do chamador de nível superior.\n\n  Por exemplo, *top-level-caller-workflow\\.yml* → *called-workflow-1.yml* → *called-workflow-2.yml* conta como 2 fluxos de trabalho reutilizáveis.\n\n* As variáveis de ambiente definidas em um contexto `env` definido no nível do fluxo de trabalho do chamador não são propagadas para o fluxo de trabalho chamado. Para saber mais, confira [Armazenar informações em variáveis](/pt/actions/learn-github-actions/variables) e [Referência de contextos](/pt/actions/learn-github-actions/contexts#env-context).\n\n* Da mesma forma, as variáveis de ambiente definidas no contexto de `env`, definidas no fluxo de trabalho chamado, não são acessíveis no contexto do fluxo de trabalho do chamador `env`. Em vez disso, você deve usar saídas do fluxo de trabalho reutilizável. Para obter mais informações, consulte [Usando saídas de um fluxo de trabalho reutilizável](/pt/actions/how-tos/sharing-automations/reuse-workflows#using-outputs-from-a-reusable-workflow).\n\n* Para reutilizar variáveis em vários fluxos de trabalho, defina-as nos níveis da organização, do repositório ou do ambiente e faça referência a elas usando o contexto `vars`. Para saber mais, confira [Armazenar informações em variáveis](/pt/actions/learn-github-actions/variables) e [Referência de contextos](/pt/actions/learn-github-actions/contexts#vars-context).\n\n* Fluxos de trabalho reutilizáveis são chamados diretamente dentro de um trabalho, e não de dentro de uma etapa de trabalho. Portanto, você não pode usar `GITHUB_ENV` para passar valores para as etapas de trabalho no fluxo de trabalho do chamador.\n\n### Palavras-chave compatíveis com tarefas que utilizam um fluxo de trabalho reutilizável\n\nAo chamar um fluxo de trabalho reutilizável, você só poderá usar as palavras-chave a seguir no trabalho que contém a chamada:\n\n* [`jobs.<job_id>.name`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idname)\n* [`jobs.<job_id>.uses`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iduses)\n* [`jobs.<job_id>.with`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idwith)\n* [`jobs.<job_id>.with.<input_id>`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idwithinput_id)\n* [`jobs.<job_id>.secrets`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecrets)\n* [`jobs.<job_id>.secrets.<secret_id>`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id)\n* [`jobs.<job_id>.secrets.inherit`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretsinherit)\n* [`jobs.<job_id>.strategy`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy)\n* [`jobs.<job_id>.needs`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)\n* [`jobs.<job_id>.if`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif)\n* [`jobs.<job_id>.concurrency`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency)\n* [`jobs.<job_id>.permissions`](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions)\n\n  > \\[!NOTE]\n  >\n  > * Se `jobs.<job_id>.permissions` não for especificado no trabalho de chamada, o fluxo de trabalho chamado terá as permissões padrão para o `GITHUB_TOKEN`. Para saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/reference/workflow-syntax-for-github-actions#permissions).\n  > * As permissões `GITHUB_TOKEN` transmitidas do fluxo de trabalho do chamador só podem ser rebaixadas (não elevadas) pelo fluxo de trabalho chamado.\n  > * Se você usar `jobs.<job_id>.concurrency.cancel-in-progress: true`, não use o mesmo valor para `jobs.<job_id>.concurrency.group` nos fluxos de trabalho chamado e chamador, pois isso fará com que o fluxo de trabalho que já está em execução seja cancelado. Um fluxo de trabalho chamado utiliza o nome do fluxo de trabalho de origem em ${{ github.workflow }}, então, usar esse contexto como o valor de `jobs.<job_id>.concurrency.group` tanto no fluxo de trabalho de origem quanto no fluxo de trabalho chamado fará com que o fluxo de trabalho de origem seja cancelado quando o fluxo de trabalho chamado for executado.\n\n### Como os fluxos de trabalho reutilizáveis usam executores\n\n#### Executores hospedados em GitHub\n\nA atribuição de executores hospedados em GitHub é sempre avaliada considerando apenas o contexto do chamador. A cobrança de executores hospedados em GitHub está sempre vinculada ao chamador. O fluxo de trabalho do chamador não pode utilizar executores hospedados em GitHub do repositório chamado. Para saber mais, confira [Executores hospedados no GitHub](/pt/actions/using-github-hosted-runners/about-github-hosted-runners).\n\n#### Executores auto-hospedados\n\nFluxos de trabalho chamados que pertencem ao mesmo usuário, organização que o fluxo de trabalho do chamador podem acessar executores auto-hospedados a partir do contexto do chamador. Isso significa que um fluxo de trabalho chamado pode acessar executores auto-hospedados que estão:\n\n* No repositório do chamador\n* Na organização do repositório do chamador, desde que o executor tenha sido disponibilizado para esse repositório.\n\n### Acesso e permissões para fluxos de trabalho aninhados\n\nUm fluxo de trabalho que contém fluxos de trabalho aninhados reutilizáveis falhará se qualquer um dos fluxos de trabalho aninhados estiver inacessível ao fluxo de trabalho inicial do chamador. Para obter mais informações, confira \"[Como acessar a fluxos de trabalho reutilizáveis](#access-to-reusable-workflows)\".\n\nAs permissões `GITHUB_TOKEN` só podem ser as mesmas ou mais restritivas nos fluxos de trabalho aninhados. Por exemplo, na cadeia de fluxo de trabalho A > B > C, se o fluxo de trabalho A tiver permissão do token `package: read`, B e C não poderão ter a permissão `package: write`. Para saber mais, confira [Usar GITHUB\\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/security-guides/automatic-token-authentication).\n\nPara obter informações sobre como usar a API para determinar quais arquivos de fluxo de trabalho estavam envolvidos em uma execução de fluxo de trabalho específica, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/sharing-automations/reuse-workflows#monitoring-which-workflows-are-being-used).\n\n### Comportamento de fluxos de trabalho reutilizáveis ao executar trabalhos novamente\n\nFluxos de trabalho reutilizáveis de repositórios públicos podem ser referenciados usando um SHA, uma tag de lançamento ou um nome de branch. Para saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow).\n\nQuando você executa novamente um fluxo de trabalho que usa um fluxo de trabalho reutilizável e a referência não é um SHA, há alguns comportamentos a serem observados:\n\n* A reexecução de todos os trabalhos em um fluxo de trabalho usará o fluxo de trabalho reutilizável da referência especificada. Para obter mais informações sobre como executar novamente todos os trabalhos em um fluxo de trabalho, confira [Reexecutando fluxos de trabalho e tarefas](/pt/actions/managing-workflow-runs/re-running-workflows-and-jobs#re-running-all-the-jobs-in-a-workflow).\n* Reexecutar trabalhos com falha ou um trabalho específico em um fluxo usará o fluxo de trabalho reutilizável do mesmo SHA de commit da primeira tentativa. Para obter mais informações sobre como executar novamente trabalhos com falha em um fluxo de trabalho, confira [Reexecutando fluxos de trabalho e tarefas](/pt/actions/managing-workflow-runs/re-running-workflows-and-jobs#re-running-failed-jobs-in-a-workflow). Para obter mais informações sobre como executar um trabalho específico em um fluxo de trabalho, confira [Reexecutando fluxos de trabalho e tarefas](/pt/actions/managing-workflow-runs/re-running-workflows-and-jobs#re-running-a-specific-job-in-a-workflow).\n\n### Contexto `github`\n\nQuando um fluxo de trabalho reutilizável é disparado por um fluxo de trabalho do chamador, o contexto `github` é sempre associado ao fluxo de trabalho do chamador. O fluxo de trabalho chamado recebe automaticamente o acesso a `github.token` e a `secrets.GITHUB_TOKEN`. Para saber mais sobre o contexto `github`, confira [Referência de contextos](/pt/actions/learn-github-actions/contexts#github-context).\n\n## Modelos de fluxo de trabalho\n\nInformações de referência a serem usadas ao criar modelos de fluxo de trabalho para sua organização.\n\n### Disponibilidade do modelo de fluxo de trabalho\n\nVocê pode usar modelos em repositórios que correspondem ou têm visibilidade mais restrita do que o repositório modelo.\n\n* Modelos de fluxo de trabalho em um repositório público do `.github` estão disponíveis para todos os tipos de repositório.\n* Modelos de fluxo de trabalho em um repositório interno do `.github` só estão disponíveis para repositórios internos e privados.\n* Modelos de fluxo de trabalho em um repositório privado do `.github` só estão disponíveis para repositórios privados.\n\n### Concedendo acesso a repositórios privados/internos\n\nSe você estiver usando um repositório privado ou interno do `.github`, precisará conceder acesso de leitura aos usuários ou às equipes que deverão poder usar os modelos.\n\n### O espaço reservado `$default-branch`\n\nSe você precisar referir-se ao branch padrão de um repositório, pode usar o marcador de posição `$default-branch` em seu modelo de fluxo de trabalho. Quando um fluxo de trabalho é criado, o placeholder será automaticamente substituído pelo nome do branch padrão do repositório.\n\n### Exemplo de arquivo de modelo de fluxo de trabalho\n\nEste arquivo chamado `octo-organization-ci.yml` demonstra um fluxo de trabalho básico.\n\n```yaml copy\nname: Octo Organization CI\non:\n  push:\n    branches: [ $default-branch ]\n  pull_request:\n    branches: [ $default-branch ]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Run a one-line script\n        run: echo Hello from Octo Organization\n```\n\n### Requisitos de arquivo de metadados\n\nO arquivo de metadados precisa ter o mesmo nome do arquivo de fluxo de trabalho, mas, em vez da extensão `.yml`, é preciso acrescentar `.properties.json` a ele. Por exemplo, este arquivo chamado `octo-organization-ci.properties.json` contém os metadados para o arquivo de fluxo de trabalho chamado `octo-organization-ci.yml`:\n\n```json copy\n{\n    \"name\": \"Octo Organization Workflow\",\n    \"description\": \"Octo Organization CI workflow template.\",\n    \"iconName\": \"example-icon\",\n    \"categories\": [\n        \"Go\"\n    ],\n    \"filePatterns\": [\n        \"package.json$\",\n        \"^Dockerfile\",\n        \".*\\\\.md$\"\n    ]\n}\n```\n\n* `name`\n\n- **Obrigatório.** Nome do fluxo de trabalho. É exibido na lista de fluxos de trabalho disponíveis.\n\n* `description`\n\n- **Obrigatório.** Descrição do fluxo de trabalho. É exibido na lista de fluxos de trabalho disponíveis.\n\n* `iconName`\n\n- **Opcional**. Especifica um ícone para o fluxo de trabalho exibido na lista correspondente.\n  `iconName` pode ser um dos seguintes tipos:\n  * Um arquivo SVG armazenado no diretório de `workflow-templates`. Para fazer referência a um arquivo, o valor deve ser o nome do arquivo sem a extensão dele. Por exemplo, um arquivo SVG chamado `example-icon.svg` é referenciado como `example-icon`.\n  * Um ícone do conjunto de [Octicons](https://primer.style/octicons/) do GitHub. Para fazer referência a um octicon, o valor dele deve ser `octicon <icon name>`. Por exemplo, `octicon smiley`.\n\n* `categories`\n\n- **Opcional**. Define as categorias em que o fluxo de trabalho é mostrado. Você pode usar nomes de categoria das seguintes listas:\n  * Nomes de categorias gerais do repositório [starter-workflows](https://github.com/actions/starter-workflows/blob/main/README.md#categories).\n  * Linguagens Linguist da lista de repositório em [linguist](https://github.com/github-linguist/linguist/blob/main/lib/linguist/languages.yml).\n  * Pilhas de tecnologia com suporte da lista no repositório [starter-workflows](https://github.com/github-starter-workflows/repo-analysis-partner/blob/main/tech_stacks.yml).\n\n* `filePatterns`\n\n- **Opcional**. Permite que o modelo seja usado caso o repositório do usuário tenha um arquivo no diretório raiz que corresponda a uma expressão regular definida.\n\n## Âncoras e aliases YAML\n\nVocê pode usar âncoras e aliases YAML para reduzir a repetição nos fluxos de trabalho. Uma âncora (marcada com `&`) identifica uma parte do conteúdo que você deseja reutilizar, enquanto um alias (marcado com `*`) repete esse conteúdo em outro local.\n\nPara obter informações detalhadas sobre âncoras e aliases, consulte [Aliases e âncoras do Node na especificação YAML](https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases).\n\nVeja um exemplo que usa âncoras e aliases YAML com variáveis de ambiente:\n\n```yaml\njobs:\n  job1:\n    env: &env_vars # Define the anchor on first use\n      NODE_ENV: production\n      DATABASE_URL: ${{ secrets.DATABASE_URL }}\n    steps:\n      - run: echo \"Using production settings\"\n\n  job2:\n    env: *env_vars # Reuse the environment variables\n    steps:\n      - run: echo \"Same environment variables here\"\n```\n\nIsso é equivalente a escrever o seguinte YAML, sem âncoras e aliases:\n\n```yaml\njobs:\n  job1:\n    env:\n      NODE_ENV: production\n      DATABASE_URL: ${{ secrets.DATABASE_URL }}\n    steps:\n      - run: echo \"Using production settings\"\n\n  job2:\n    env:\n      NODE_ENV: production\n      DATABASE_URL: ${{ secrets.DATABASE_URL }}\n    steps:\n      - run: echo \"Same environment variables here\"\n```\n\nVocê também pode usar âncoras para configurações mais complexas, como a reutilização de uma configuração de trabalho inteira:\n\n```yaml\njobs:\n  test: &base_job # Define the anchor on first use\n    runs-on: ubuntu-latest\n    timeout-minutes: 30\n    env:\n      NODE_VERSION: '18'\n    steps:\n      - uses: actions/checkout@v6\n      - name: Set up Node.js\n        uses: actions/setup-node@v4\n        with:\n          node-version: ${{ env.NODE_VERSION }}\n      - run: npm test\n\n  alt-test: *base_job # Reuse the entire job configuration\n```"}