{"meta":{"title":"Reutilizar fluxos de trabalho","intro":"Aprenda a evitar a duplicação ao criar um fluxo de trabalho reutilizando os fluxos de trabalho existentes.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/pt/enterprise-cloud@latest/actions/how-tos","title":"Instruções"},{"href":"/pt/enterprise-cloud@latest/actions/how-tos/reuse-automations","title":"Reutilizar automações"},{"href":"/pt/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows","title":"Reutilizar fluxos de trabalho"}],"documentType":"article"},"body":"# Reutilizar fluxos de trabalho\n\nAprenda a evitar a duplicação ao criar um fluxo de trabalho reutilizando os fluxos de trabalho existentes.\n\n## Criar um fluxo de trabalho reutilizável\n\nOs fluxos de trabalho reutilizáveis são arquivos formatados com YAML, muito semelhantes a qualquer outro arquivo de fluxo de trabalho. Assim como acontece com outros arquivos de fluxo de trabalho, você localiza fluxos de trabalho reutilizáveis no diretório `.github/workflows` de um repositório. Não há suporte para subdiretórios do diretório `workflows`.\n\nVocê pode padronizar implantações criando um grupo de executores auto-hospedados que só pode executar um fluxo de trabalho reutilizável específico. Para obter mais informações, consulte [Gerenciar o acesso a executores auto-hospedados usando grupos](/pt/enterprise-cloud@latest/actions/how-tos/manage-runners/self-hosted-runners/manage-access).\n\nPara que um fluxo de trabalho seja reutilizável, os valores de `on` precisam incluir `workflow_call`:\n\n```yaml\non:\n  workflow_call:\n```\n\n## Usando entradas e segredos em um fluxo de trabalho reutilizável\n\nVocê pode definir entradas e segredos, que podem ser passados do fluxo de trabalho de de chamada e, em seguida, usados no fluxo de trabalho chamado. Há três etapas para usar uma entrada ou um segredo em um fluxo de trabalho reutilizável.\n\n1. No fluxo de trabalho reutilizável, use as palavras-chave `inputs` e `secrets` para definir entradas ou segredos que serão transmitidos de um fluxo de trabalho do chamador.\n\n   ```yaml\n   on:\n     workflow_call:\n       inputs:\n         config-path:\n           required: true\n           type: string\n       secrets:\n         personal_access_token:\n           required: true\n   ```\n\n   Para obter detalhes da sintaxe para definir entradas e segredos, consulte [`on.workflow_call.inputs`](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callinputs) e [`on.workflow_call.secrets`](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callsecrets).\n\n2. No fluxo de trabalho reutilizável, faça referência à entrada ou ao segredo que você definiu na chave `on` na etapa anterior.\n\n   > \\[!NOTE]\n   > Se os segredos forem herdados usando `secrets: inherit` no fluxo de trabalho de chamada, você poderá referenciá-los mesmo que não estejam explicitamente definidos na chave `on`. Para saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit).\n\n   ```yaml\n   jobs:\n     reusable_workflow_job:\n       runs-on: ubuntu-latest\n       steps:\n       - uses: actions/labeler@v6\n         with:\n           repo-token: ${{ secrets.personal_access_token }}\n           configuration-path: ${{ inputs.config-path }}\n   ```\n\n   No exemplo acima, `personal_access_token` é um segredo definido no nível do repositório ou da organização.\n\n   > \\[!WARNING]\n   > Os segredos do ambiente não podem ser transmitidos do fluxo de trabalho do chamador, pois `on.workflow_call` não dá suporte à palavra-chave `environment`. Se você incluir `environment` no fluxo de trabalho reutilizável no nível do trabalho, o segredo do ambiente será usado, não o segredo passado do fluxo de trabalho do chamador. Para saber mais, confira [Gerenciar ambientes para implantação](/pt/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) e [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_call).\n\n3. Passe a entrada ou o segredo do fluxo de trabalho da chamada.\n\n   Para transmitir entradas nomeadas para um fluxo de trabalho chamado, use a palavra-chave `with` em um trabalho. Use a palavra-chave `secrets` para transmitir segredos nomeados. Para entradas, o tipo de dado do valor de entrada deve corresponder ao tipo especificado no fluxo de trabalho chamado (booleano, número ou string).\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets:\n         personal_access_token: ${{ secrets.token }}\n   ```\n\n   Fluxos de trabalho que chamam fluxos de trabalho reutilizáveis na mesma organização ou empresa podem usar a palavra-chave `inherit` para passar implicitamente os segredos.\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets: inherit\n   ```\n\n### Exemplo de fluxo de trabalho reutilizável\n\nEsse arquivo de fluxo de trabalho reutilizável chamado `workflow-B.yml` (vamos nos referir a ele mais adiante no [exemplo de fluxo de trabalho do chamador](#example-caller-workflow)) usa uma cadeia de caracteres de entrada e um segredo do fluxo de trabalho do chamador e os usa em uma ação.\n\n```yaml copy\nname: Reusable workflow example\n\non:\n  workflow_call:\n    inputs:\n      config-path:\n        required: true\n        type: string\n    secrets:\n      token:\n        required: true\n\njobs:\n  triage:\n    runs-on: ubuntu-latest\n    steps:\n    - uses: actions/labeler@v6\n      with:\n        repo-token: ${{ secrets.token }}\n        configuration-path: ${{ inputs.config-path }}\n```\n\n## Chamando um fluxo de trabalho reutilizável\n\nUm fluxo de trabalho reutilizável é chamado por meio da palavra-chave `uses`. Ao contrário de quando você usa ações em um fluxo de trabalho, você chama os fluxos de trabalho reutilizáveis diretamente em um trabalho, e não de dentro de etapas de trabalho.\n\n[`jobs.<job_id>.uses`](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iduses)\n\nPara fazer referência a arquivos reutilizáveis do fluxo de trabalho, use uma destas 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, internos 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/enterprise-cloud@latest/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\nVocê pode chamar vários fluxos de trabalho, fazendo referência a cada um em um trabalho separado.\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\n### Exemplo de fluxo de trabalho do chamador\n\nEste arquivo de fluxo de trabalho chama dois arquivos de fluxo de trabalho. O segundo deles, `workflow-B.yml` (mostrado no [exemplo de fluxo de trabalho reutilizável](#example-reusable-workflow)), recebe uma entrada (`config-path`) e um segredo (`token`).\n\n```yaml copy\nname: Call a reusable workflow\n\non:\n  pull_request:\n    branches:\n      - main\n\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1\n\n  call-workflow-passing-data:\n    permissions:\n      contents: read\n      pull-requests: write\n    uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      token: ${{ secrets.GITHUB_TOKEN }}\n```\n\n## Passando entradas e segredos para um fluxo de trabalho reutilizável\n\nPara transmitir entradas nomeadas para um fluxo de trabalho chamado, use a palavra-chave `with` em um trabalho. Use a palavra-chave `secrets` para transmitir segredos nomeados. Para entradas, o tipo de dado do valor de entrada deve corresponder ao tipo especificado no fluxo de trabalho chamado (booleano, número ou string).\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      personal_access_token: ${{ secrets.token }}\n```\n\nFluxos de trabalho que chamam fluxos de trabalho reutilizáveis na mesma organização ou empresa podem usar a palavra-chave `inherit` para passar implicitamente os segredos.\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets: inherit\n```\n\n## Como usar uma estratégia de matriz com um fluxo de trabalho reutilizável\n\nTrabalhos que usam a estratégia de matriz podem chamar um fluxo de trabalho reutilizável.\n\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 a fim de passar entradas diferentes para um fluxo de trabalho reutilizável. Para obter mais informações sobre matrizes, confira [Executando variações de tarefas em um workflow](/pt/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\nEste trabalho de exemplo abaixo chama um fluxo de trabalho reutilizável e faz referência ao contexto de matriz definindo a variável `target` com os valores `[dev, stage, prod]`. Ele executará três trabalhos, um para cada valor na variável.\n\n```yaml copy\njobs:\n  ReusableMatrixJobForDeployment:\n    strategy:\n      matrix:\n        target: [dev, stage, prod]\n    uses: octocat/octo-repo/.github/workflows/deployment.yml@main\n    with:\n      target: ${{ matrix.target }}\n```\n\n## Como aninhar fluxos de trabalho reutilizáveis\n\nVocê pode conectar no máximo dez níveis de fluxos de trabalho, ou seja, o fluxo de trabalho de chamadas de nível superior e até nove níveis de fluxos de trabalho reutilizáveis. Por exemplo: *caller-workflow\\.yml\\_\\_→ called-workflow-1.yml\\_\\_→ called-workflow-2.yml* → *called-workflow-3.yml* →... → *called-workflow-9.yml*.\n\nLoops na árvore de fluxo de trabalho não são permitidos.\n\n> \\[!NOTE] Fluxos de trabalho reutilizáveis aninhados exigem que todos os fluxos de trabalho na cadeia sejam acessíveis ao chamador, e as permissões só podem ser mantidas ou reduzidas, e não elevadas, em toda a cadeia. Para saber mais, confira [Reutilizando configurações de fluxo de trabalho](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/reusing-workflow-configurations).\n\nDe dentro de um fluxo de trabalho reutilizável, você pode chamar outro fluxo de trabalho reutilizável.\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n\njobs:\n  call-another-reusable:\n    uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1\n```\n\n## Como passar informações confidenciais para fluxos de trabalho aninhados\n\nVocê pode usar `jobs.<job_id>.secrets` em um fluxo de trabalho de chamada para passar segredos nomeados para um fluxo de trabalho chamado diretamente. Como alternativa, você pode usar `jobs.<job_id>.secrets.inherit` para passar todos os segredos do fluxo de trabalho que efetuou a chamada para um fluxo de trabalho chamado diretamente. Para saber mais, confira a seção [Reutilizar fluxos de trabalho](/pt/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows#passing-inputs-and-secrets-to-a-reusable-workflow) acima e o artigo de referência [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit). Os segredos são passados apenas para o fluxo de trabalho chamado diretamente, portanto, na cadeia de fluxo de trabalho A > B > C, o fluxo de trabalho C só receberá segredos de A se tiverem sido passados de A para B e, em seguida, de B para C.\n\nNo exemplo a seguir, o fluxo de trabalho A passa todos os segredos dele para o fluxo de trabalho B, usando a palavra-chave `inherit`, mas o fluxo de trabalho B passa apenas um segredo para o fluxo de trabalho C. Qualquer um dos outros segredos passados para o fluxo de trabalho B não está disponível para o fluxo de trabalho C.\n\n```yaml\njobs:\n  workflowA-calls-workflowB:\n    uses: octo-org/example-repo/.github/workflows/B.yml@main\n    secrets: inherit # pass all secrets\n```\n\n```yaml\njobs:\n  workflowB-calls-workflowC:\n    uses: different-org/example-repo/.github/workflows/C.yml@main\n    secrets:\n      repo-token: ${{ secrets.personal_access_token }} # pass just this secret\n```\n\n## Usando saídas de um fluxo de trabalho reutilizável\n\nUm fluxo de trabalho reutilizável pode gerar dados que você deseja usar no fluxo de trabalho da chamada. Para usar essas saídas, você deve especificá-las como saídas do fluxo de trabalho reutilizável.\n\nSe um fluxo de trabalho reutilizável que define uma saída for executado com uma estratégia de matriz, a saída será aquela definida pelo último fluxo de trabalho reutilizável que foi concluído com sucesso na matriz e que realmente definiu um valor.\nIsso significa que se o último fluxo de trabalho reutilizável bem-sucedido definir uma cadeia de caracteres vazia para sua saída e a segunda última conclusão bem-sucedida do fluxo de trabalho reutilizável definir um valor real para sua saída, a saída conterá o valor do segundo último fluxo de trabalho reutilizável.\n\nO seguinte fluxo de trabalho reutilizável tem um único trabalho que contém duas etapas. Em cada uma dessas etapas, definimos uma única palavra como a saída: \"olá\" e \"mundo\". Na seção `outputs` do trabalho, mapeamos essas saídas de etapa para saídas de trabalho chamadas: `output1` e `output2`. Na seção `on.workflow_call.outputs`, definimos duas saídas para o fluxo de trabalho em si, uma chamada `firstword`, que mapeamos para `output1`, e outra chamada `secondword`, que mapeamos para `output2`.\n\nO `value` deve ser definido como o valor de uma saída de nível de trabalho no fluxo de trabalho chamado. As saídas em nível de etapa devem primeiro ser mapeadas às saídas em nível de trabalho, conforme mostrado abaixo.\n\nPara saber mais, confira [Passando informações entre tarefas](/pt/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs) e [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_calloutputs).\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n    # Map the workflow outputs to job outputs\n    outputs:\n      firstword:\n        description: \"The first output string\"\n        value: ${{ jobs.example_job.outputs.output1 }}\n      secondword:\n        description: \"The second output string\"\n        value: ${{ jobs.example_job.outputs.output2 }}\n\njobs:\n  example_job:\n    name: Generate output\n    runs-on: ubuntu-latest\n    # Map the job outputs to step outputs\n    outputs:\n      output1: ${{ steps.step1.outputs.firstword }}\n      output2: ${{ steps.step2.outputs.secondword }}\n    steps:\n      - id: step1\n        run: echo \"firstword=hello\" >> $GITHUB_OUTPUT\n      - id: step2\n        run: echo \"secondword=world\" >> $GITHUB_OUTPUT\n```\n\nAgora podemos usar as saídas no fluxo de trabalho da chamada, da mesma forma que você usaria as saídas de um trabalho dentro do mesmo fluxo de trabalho. Referenciamos as saídas usando os nomes definidos no nível do fluxo de trabalho no fluxo de trabalho reutilizável: `firstword` e `secondword`. Nesse fluxo de trabalho, `job1` chama o fluxo de trabalho reutilizável e `job2` imprime as saídas do fluxo de trabalho reutilizável (\"olá, mundo\") para a saída padrão no log do fluxo de trabalho.\n\n```yaml copy\nname: Call a reusable workflow and use its outputs\n\non:\n  workflow_dispatch:\n\njobs:\n  job1:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1\n\n  job2:\n    runs-on: ubuntu-latest\n    needs: job1\n    steps:\n      - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}\n```\n\nPara saber mais sobre como usar saídas de trabalho, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs). Se você desejar compartilhar algo diferente de uma variável (por exemplo, um artefato de criação) entre fluxos de trabalho, consulte [Armazenar e compartilhar dados com artefatos de fluxo de trabalho](/pt/enterprise-cloud@latest/actions/tutorials/store-and-share-data).\n\n## Monitorando quais fluxos de trabalho estão sendo utilizados\n\nVocê pode usar a GitHub API REST para monitorar como fluxos de trabalho reutilizáveis estão sendo usados. A ação `prepared_workflow_job` do log de auditoria é disparada quando um trabalho de fluxo de trabalho é iniciado. Estão incluídos nos dados registrados:\n\n* `repo` – A organização/o repositório em que a tarefa de fluxo de trabalho está localizada. Para um trabalho que chama outro fluxo de trabalho, este é a organização/repositório do fluxo de trabalho chamador.\n* `@timestamp`: a data e a hora em que o trabalho foi iniciado, no formato de época do UNIX.\n* `job_name` – O nome do trabalho que foi executado.\n* `calling_workflow_refs`: uma matriz de caminhos de arquivo para todos os fluxos de trabalho de chamador envolvidos neste trabalho de fluxo de trabalho. Os itens na matriz estão na ordem inversa em que foram chamados. Por exemplo, em uma cadeia de fluxos de trabalho A > B > C, ao exibir os logs de um trabalho no fluxo de trabalho C, a matriz seria `[\"octo-org/octo-repo/.github/workflows/B.yml\", \"octo-org/octo-repo/.github/workflows/A.yml\"]`.\n* `calling_workflow_shas`: uma matriz de SHAs para todos os fluxos de trabalho de chamador envolvidos neste trabalho de fluxo de trabalho. A matriz contém o mesmo número de itens, na mesma ordem, que a matriz `calling_workflow_refs`.\n* `job_workflow_ref` – O arquivo de fluxo de trabalho que foi usado, no formato `{owner}/{repo}/{path}/{filename}@{ref}`. Para um trabalho que chama outro fluxo de trabalho, isso identifica o fluxo de trabalho chamado.\n\nPara saber mais, confira [Revisar o log de auditoria da organização](/pt/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization#using-the-audit-log-api).\n\n> \\[!NOTE]\n> Os dados de auditoria de `prepared_workflow_job` só podem ser vistos por meio da API REST. Ele não está visível na interface da GitHub Web ou incluído nos dados de auditoria exportados JSON/CSV.\n\n## Próximas etapas\n\nPara encontrar informações sobre os meandros da reutilização de fluxos de trabalho, consulte [Reutilizando configurações de fluxo de trabalho](/pt/enterprise-cloud@latest/actions/reference/workflows-and-actions/reusing-workflow-configurations)."}