{"meta":{"title":"Reutilización de flujos de trabajo","intro":"Aprende cómo evitar la duplicación al crear un flujo de trabajo reusando los flujos existentes.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/how-tos","title":"Procedimientos"},{"href":"/es/actions/how-tos/reuse-automations","title":"Reutilización de automatizaciones"},{"href":"/es/actions/how-tos/reuse-automations/reuse-workflows","title":"Reutilización de flujos de trabajo"}],"documentType":"article"},"body":"# Reutilización de flujos de trabajo\n\nAprende cómo evitar la duplicación al crear un flujo de trabajo reusando los flujos existentes.\n\n## Crear un flujo de trabajo reutilizable\n\nLos flujos de trabajo reutilizables son archivos con formato YAML, muy similares a cualquier otro archivo de flujo de trabajo. Al igual que con otros archivos de flujo de trabajo, puede buscar flujos de trabajo reutilizables en el directorio `.github/workflows` de un repositorio. No se admiten subdirectorios del directorio `workflows`.\n\nPara que un flujo de trabajo sea reutilizable, los valores de `on` deben incluir `workflow_call`:\n\n```yaml\non:\n  workflow_call:\n```\n\n## Utilizar entradas y secretos en un flujo de trabajo reutilizable\n\nPuede definir entradas y secretos, las cuales pueden pasarse desde el flujo de trabajo llamante y luego utilizarse dentro del flujo llamado. Existen tres etapas para utilizar una entrada o un secreto en un flujo de trabajo reutilizable.\n\n1. En el flujo de trabajo reutilizable, use las palabras clave `inputs` y `secrets` para definir entradas o secretos que se enviarán desde un flujo de trabajo que inicia una llamada.\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\nPara obtener más información sobre la sintaxis para definir entradas y secretos, consulte [`on.workflow_call.inputs`](/es/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callinputs) y [`on.workflow_call.secrets`](/es/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets).\n\n1. En el flujo de trabajo reutilizable, haz referencia a la entrada o el secreto que definiste en la clave `on` del paso anterior.\n\n   > \\[!NOTE]\n   > Si los secretos se heredan mediante `secrets: inherit` en el flujo de trabajo de llamada, puede hacer referencia a ellos incluso si no están definidos en la clave `on`. Para más información, consulta [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/using-workflows/workflow-syntax-for-github-actions#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   En el ejemplo anterior, `personal_access_token` es un secreto que está definido a nivel de repositorio u organización.\n\n   > \\[!WARNING]\n   > Los secretos de entorno no se pueden pasar desde el flujo de trabajo del autor de la llamada, ya que `on.workflow_call` no admite la palabra clave `environment`. Si incluye `environment` en el flujo de trabajo reutilizable a nivel de trabajo, se usará el secreto de entorno y no el secreto pasado desde el flujo de trabajo del autor de la llamada. Para más información, consulta [Administrar entornos para la implementación](/es/actions/deployment/targeting-different-environments/managing-environments-for-deployment#environment-secrets) y [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_call).\n\n2. Pasa la entrada o secreto desde el flujo de trabajo llamante.\n\n   Para pasar entradas con nombre a un flujo de trabajo con nombre, use la palabra clave `with` en un trabajo. Use la palabra clave `secrets` para pasar secretos con nombre. Para las entradas, el tipo de datos del valor de entrada debe empatar con el tipo especificado en el flujo de trabajo llamado (ya sea booleano, número o secuencia).\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   Los flujos de trabajo que llaman a flujos de trabajo reutilizables de la misma organización o empresa pueden usar la palabra clave `inherit` para pasar implícitamente los secretos.\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### Flujo de trabajo reutilizable de ejemplo\n\nEste archivo de flujo de trabajo reutilizable llamado `workflow-B.yml` (nos referiremos a él más adelante en el [flujo de trabajo llamante de ejemplo](#example-caller-workflow)) toma una cadena de entrada y un secreto del flujo que inicia la llamada y lo utiliza en una acción.\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## Llamar a un flujo de trabajo reutilizable\n\nPara llamar a un flujo de trabajo reutilizable, use la palabra clave `uses`. A diferencia de cuando utilizas acciones en un flujo de trabajo, los flujos de trabajo reutilizables se llaman directamente desde un job y no dentro de los pasos de un job.\n\n[`jobs.<job_id>.uses`](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iduses)\n\nPuede hacer referencia a archivos de flujo de trabajo reutilizables mediante una de las sintaxis siguientes:\n\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` para flujos de trabajo reutilizables en repositorios públicos y privados.\n* `./.github/workflows/{filename}` para flujos de trabajo reutilizables en el mismo repositorio.\n\nEn la primera opción, `{ref}` puede ser un SHA, una etiqueta de lanzamiento o un nombre de rama. Si una etiqueta de versión y una rama tienen el mismo nombre, la primera tiene prioridad sobre el nombre de la rama. Utilizar el SHA de la confirmación es la opción más segura para lograr estabilidad y seguridad. Para más información, consulta [Referencia de uso seguro](/es/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows).\n\nSi usas la segunda opción de sintaxis (sin `{owner}/{repo}` y `@{ref}`), el flujo de trabajo que se llama procede de la misma confirmación que el flujo de trabajo autor de la llamada. No se permiten prefijos de referencia como `refs/heads` y `refs/tags`. No puedes utilizar contextos o expresiones en esta palabra clave.\n\nPuede llamar a flujos de trabajo múltiples, referenciando cada uno en un job 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  call-workflow-in-another-repo:\n    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\n### Flujo de trabajo llamante de ejemplo\n\nEste archivo de flujo de trabajo llama a otros dos archivos de flujo de trabajo. El segundo, `workflow-B.yml` (que se muestra en el [flujo de trabajo reutilizable de ejemplo](#example-reusable-workflow)), recibe una entrada (`config-path`) y un secreto (`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## Pasar entradas y secretos a un flujo de trabajo reutilizable\n\nPara pasar entradas con nombre a un flujo de trabajo con nombre, use la palabra clave `with` en un trabajo. Use la palabra clave `secrets` para pasar secretos con nombre. Para las entradas, el tipo de datos del valor de entrada debe empatar con el tipo especificado en el flujo de trabajo llamado (ya sea booleano, número o secuencia).\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\nLos flujos de trabajo que llaman a flujos de trabajo reutilizables de la misma organización o empresa pueden usar la palabra clave `inherit` para pasar implícitamente los secretos.\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## Uso de una estrategia de matriz con un flujo de trabajo reutilizable\n\nLos trabajos que usan la estrategia de matriz pueden llamar a un flujo de trabajo reutilizable.\n\nUna estrategia de matriz permite usar variables en una definición de trabajo para crear automáticamente varias ejecuciones de trabajos basadas en las combinaciones de las variables. Por ejemplo, puede usar una estrategia de matriz para pasar diferentes entradas a un flujo de trabajo reutilizable. Para obtener más información sobre las matrices, consulta [Ejecución de variaciones de trabajos en un flujo de trabajo](/es/actions/using-jobs/using-a-matrix-for-your-jobs).\n\nEl siguiente trabajo de ejemplo llama a un flujo de trabajo reutilizable y hace referencia al contexto de la matriz mediante la definición de la variable `target` con los valores `[dev, stage, prod]`. Ejecutará tres trabajos, uno para cada valor de la variable.\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## Anidación de flujos de trabajo reutilizables\n\nPuede conectar un máximo de diez niveles de flujos de trabajo, es decir, el flujo de trabajo del llamador de nivel superior y hasta nueve niveles de flujos de trabajo reutilizables. Por ejemplo: *caller-workflow\\.yml* → *called-workflow-1.yml* → *called-workflow-2.yml* → *called-workflow-3.yml* → ... → *called-workflow-9.yml*.\n\nNo se permiten bucles en el árbol de flujo de trabajo.\n\n> \\[!NOTE] Los flujos de trabajo reutilizables anidados requieren que todos los flujos de trabajo de la cadena sean accesibles para el autor de la llamada, y los permisos solo se pueden mantener o reducir (no elevar) en toda la cadena. Para más información, consulta [Reutilización de configuraciones de flujo de trabajo](/es/actions/reference/reusable-workflows-reference#access-and-permissions-for-nested-workflows).\n\nDesde dentro de un flujo de trabajo reutilizable, puede llamar a otro flujo de trabajo reutilizable.\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## Pasar secretos a flujos de trabajo anidados\n\nPuede usar `jobs.<job_id>.secrets` en un flujo de trabajo de llamada para pasar secretos con nombre a un flujo de trabajo llamado directamente. Como alternativa, puede usar `jobs.<job_id>.secrets.inherit` para pasar todos los secretos del flujo de trabajo de llamada a un flujo de trabajo llamado directamente. Para obtener más información, consulte la sección [Reutilización de flujos de trabajo](/es/actions/using-workflows/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow) anterior y el artículo de referencia [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretsinherit). Los secretos solo se pasan al flujo de trabajo llamado directamente, por lo que en la cadena de flujo de trabajo A > B > C, el flujo de trabajo C solo recibirá secretos de A si se han pasado de A a B y, a continuación, de B a C.\n\nEn el ejemplo siguiente, el flujo de trabajo A pasa todos sus secretos al flujo de trabajo B, mediante la palabra clave `inherit`, pero el flujo de trabajo B solo pasa un secreto al flujo de trabajo C. Ninguno de los demás secretos pasados al flujo de trabajo B no está disponible para el flujo de trabajo 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## Utilizar salidas desde un flujo de trabajo reutilizable\n\nUn flujo de trabajo reutilizable podría generar datos que quieras utilizar en el flujo de trabajo llamante. Para utilizar estas salidas, debe especificarlas como las salidas del flujo de trabajo reutilizable.\n\nSi un flujo de trabajo reutilizable que establece una salida se ejecuta con una estrategia de matriz, la salida será la salida establecida por el último flujo de trabajo reutilizable completado correctamente de la matriz que realmente establece un valor.\nEsto significa que si el último flujo de trabajo reutilizable completado correctamente establece una cadena vacía para su salida y el segundo último flujo de trabajo reutilizable completado correctamente establece un valor real para su salida, la salida contendrá el valor del segundo último flujo de trabajo reutilizable.\n\nLos siguientes flujos de trabajo reutilizables tienen un solo job que contiene dos pasos. En cada uno de estos pasos, configuramos una sola palabra como la salida: \"hello\" y \"world\". En la sección `outputs` del trabajo, asignamos estas salidas de paso a las salidas de trabajo llamadas: `output1` y `output2`. En la sección `on.workflow_call.outputs`, definimos dos salidas para el propio flujo de trabajo: una denominada `firstword` que se asigna a `output1` y otra denominada `secondword` que se asigna a `output2`.\n\n```\n          `value` debe establecerse en el valor de una salida de nivel de trabajo dentro del flujo de trabajo llamado. Las salidas de nivel de paso deben asignarse primero a las salidas de nivel de trabajo, como se muestra a continuación.\n```\n\nPara más información, consulta [Pasar información entre trabajos](/es/actions/using-jobs/defining-outputs-for-jobs#overview) y [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/using-workflows/workflow-syntax-for-github-actions#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\nAhora podemos utilizar las salidas en el flujo de trabajo llamante, de la misma forma en la que utilizarías las salidas de un job dentro del mismo flujo de trabajo. Hacemos referencia a las salidas mediante los nombres definidos a nivel de flujo de trabajo en el flujo de trabajo reutilizable: `firstword` y `secondword`. En este flujo de trabajo, `job1` llama al flujo de trabajo reutilizable y `job2` imprime las salidas del flujo de trabajo reutilizable (\"hola mundo\") a la salida estándar del registro de flujo de trabajo.\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 obtener más información sobre el uso de salidas de trabajo, consulte [Sintaxis del flujo de trabajo para GitHub Actions](/es/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idoutputs). Si desea compartir algo distinto de una variable (por ejemplo, un artefacto de compilación) entre flujos de trabajo, consulte [Almacenamiento y uso compartido de datos con artefactos de flujo de trabajo](/es/actions/using-workflows/storing-workflow-data-as-artifacts).\n\n## Monitorear qué flujos de trabajo se están utilizando\n\nLas organizaciones que usan GitHub Enterprise Cloud pueden interactuar con el registro de auditoría mediante la API REST de GitHub para supervisar qué flujos de trabajo se usan. Para obtener más información, consulte la [documentación de GitHub Enterprise Cloud](/es/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## Pasos siguientes\n\nPara buscar información sobre las complejidades de la reutilización de flujos de trabajo, consulta [Reutilización de configuraciones de flujo de trabajo](/es/actions/reference/reusable-workflows-reference)."}