Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Información general
En vez de copiar y pegar desde un flujo de trabajo hacia otro, puede hacer flujos de trabajo reutilizables. Tú y cualquiera que tenga acceso a un flujo de trabajo reutilizable pueden entonces llamarlo desde otro flujo.
El reutilizar flujos de trabajo evita la duplicación. Esto hace que los flujos de trabajo se puedan mantener más fácilmente y te permite crear flujos de trabajo nuevos más fácilmente compilando sobre el trabajo de los demás, tal como lo haces con las acciones. La reutilización de flujos de trabajo también promueve las mejores prácticas al ayudarte a utilizar los flujos de trabajo que están bien diseñados, que ya se han probado y cuya efectividad ya se comprobó. Tu organización puede crear una librería de flujos de trabajo reutilizables que puede mantenerse centralmente.
En el diagrama siguiente se muestra una ejecución de flujo de trabajo en curso que usa un flujo de trabajo reutilizable.
- Una vez que cada uno de los tres trabajos de compilación de la izquierda del diagrama se completa correctamente, se ejecuta un trabajo dependiente denominado "Implementar".
- El trabajo "Implementar" llama a un flujo de trabajo reutilizable que contiene otros tres trabajos: "Almacenamiento provisional", "Revisión" y "Producción".
- El job de despliegue "Production" solo se ejecuta después de que el job "Staging" se haya completado con éxito.
- Cuando un trabajo tiene como destino un entorno, la ejecución del flujo de trabajo muestra una barra de progreso en la que se puede ver el número de etapas del trabajo. En el diagrama siguiente, el trabajo "Producción" contiene ocho pasos, y se puede ver cómo se está procesando el paso 6.
- El utilizar un flujo de trabajo reutilizable para ejecutar jobs de despliegue te permite ejecutarlos para cada compilación sin duplicar el código en los flujos de trabajo.
A un flujo de trabajo que utiliza otro flujo de trabajo se le llama flujo de trabajo "llamante". El flujo de trabajo reutilizable es un flujo "llamado". Un flujo de trabajo llamante puede utilizar varios flujos de trabajo llamados. Cada flujo de trabajo llamado se referencia en una línea simple. El resultado es que el archivo de flujo de trabajo llamante podrá contener solo unas cuantas líneas de YAML, pero podría realizar una cantidad grande de tareas cuando se ejecute. Cuando reutilizas un flujo de trabajo, se utiliza todo el flujo de trabajo llamado justo como si fuera parte del flujo de trabajo llamante.
Si utilizas un flujo de trabajo desde un repositorio diferente, cualquier acción en el flujo de trabajo llamado se ejecutará como si fuera parte del llamante. Por ejemplo, si el flujo de trabajo al que se ha llamado usa actions/checkout
, la acción comprueba el contenido del repositorio que hospeda el flujo de trabajo que ha iniciado la llamada y no el que la recibe.
Cuando un flujo de trabajo que inicia llamadas activa uno reutilizable, el contexto github
siempre se asocia con el primer flujo. El flujo de trabajo al que se llama se le concede acceso automáticamente a github.token
y secrets.GITHUB_TOKEN
. Para obtener más información sobre el contexto de github
, consulte "Contextos".
Puede ver los flujos de trabajo reutilizados que se referencian en sus flujos de trabajo de GitHub Actions como dependencias en la gráfica de dependencias del repositorio que los contiene. Para obtener más información, consulte "Acerca del gráfico de dependencias".
Flujos de trabajo reutilizables e iniciales
Los flujos de trabajo iniciales permiten que toda persona en tu organización que tenga permiso para crear flujos de trabajo lo haga de forma más fácil y rápida. Cuando las personas crean un flujo de trabajo nuevo, pueden elegir un flujo de trabajo inicial y parte o todo el trabajo de escribir dicho flujo de trabajo se hará automáticamente. Dentro de un flujo de trabajo inicial, también puede referenciar los flujos de trabajo reutilizables para hacer más fácil que las personas se beneficien de reutilizar el código de flujo de trabajo que se administra centralmente. Si utiliza un SHA de confirmación cuando hace referencia al flujo de trabajo reutilizable, puede garantizar que todo aquel que reutilice ese flujo de trabajo siempre estará utilizando el mismo código de YAML. Sin embargo, si referencias un flujo de trabajo reutilizable mediante una etiqueta o rama, asegúrate de que puedas confiar en esa versión del flujo de trabajo. Para obtener más información, vea «Fortalecimiento de seguridad para GitHub Actions».
Para obtener más información, vea «Crear flujos de trabajo iniciales para tu organización».
Acceso a los flujos de trabajo reutilizables
Otros flujos de trabajo pueden usar uno reutilizable si se cumple alguna de las siguientes condiciones:
- Ambos flujos de trabajo están en el mismo repositorio.
- El flujo de trabajo que recibe la llamada se almacena en un repositorio público.
- El flujo de trabajo llamado se almacena en un repositorio interno y los ajustes de dicho repositorio permiten que se acceda a él. Para obtener más información, consulte "Compartir acciones y flujos de trabajo con tu empresa".
- El flujo de trabajo que se llama se almacena en un repositorio privado y los ajustes de ese repositorio permiten que se acceda a él. Para obtener más información, consulte "Compartir acciones y flujos de trabajo con tu empresa".
Nota: Para mejorar la seguridad, GitHub Actions no admite redireccionamientos de acciones o flujos de trabajo reutilizables. Esto significa que cuando se cambia el propietario, el nombre del repositorio de una acción o el nombre de una acción, cualquier flujo de trabajo que utilice esa acción con el nombre anterior dará error.
Utilizar ejecutores
Utilizar los ejecutores hospedados en GitHub
La asignación de ejecutores hospedados en GitHub siempre se evalúa utilizando únicamente el contexto del llamante. La facturación de los ejecutores hospedados en GitHub siempre se asocia con el llamador. El flujo de trabajo llamante no puede utilizar ejecutores hospedados en GitHub desde el repositorio llamado. Para obtener más información, vea «Utilizar los ejecutores hospedados en GitHub».
Utilizar ejecutores auto-hospedados
Los flujos de trabajo llamados que pertenecen al mismo usuario u organización o empresa que el flujo de trabajo llamante pueden acceder a los ejecutores auto-hospedados desde el contexto del llamante. Esto significa que el flujo de trabajo llamado puede acceder a los ejecutores auto-hospedados que están:
- En el repositorio del llamador
- En la organización o empresa, de la organización del repositorio, siempre y cuando se haya hecho disponible al ejecutor para el repositorio llamante
Limitaciones
-
Puede conectar hasta cuatro niveles de flujos de trabajo. Para obtener más información, consulta: "Anidamiento de flujos de trabajo reutilizables".
-
Puede llamar a un máximo de 20 flujos de trabajo únicos reutilizables desde un único archivo de flujo de trabajo.P Este límite incluye los árboles de flujos de trabajo reutilizables anidados a los que se puede llamar desde el archivo de flujo de trabajo del autor de llamada de nivel superior.
Por ejemplo, flujo-de-trabajo-del-autor-de-llamada-de-nivel-superior.yml → flujo-de-trabajo-llamado-1.yml → flujo-de-trabajo-llamado-2.yml cuenta como dos flujos de trabajo reutilizables.
-
Las variables de entorno que se configuren en un contexto
env
y que se definan a nivel del flujo de trabajo que inicia la llamada no se propagan al flujo de trabajo que recibe la llamada. Para obtener más información, vea «variables» y «Contextos». -
Del mismo modo, las variables de entorno establecidas en el contexto
env
, definidas en el flujo de trabajo llamado, no son accesibles en el contextoenv
del flujo de trabajo del autor de la llamada. En su lugar, debe usar salidas del flujo de trabajo reutilizable. Para obtener más información, consulte "Uso de salidas de un flujo de trabajo reutilizable". -
Para reutilizar variables en varios flujos de trabajo, debes establecerlas en los niveles de organización, repositorio o entorno, y hacer referencia a ellas mediante el contexto
vars
. Para obtener más información, consulta: "variables" y "Contextos". -
Los flujos de trabajo reutilizables se llaman directamente dentro de un trabajo y no desde dentro de un paso de trabajo. Por lo tanto, no puede usar
GITHUB_ENV
para pasar valores a los pasos del trabajo en el flujo de trabajo del autor de la llamada.
Crear un flujo de trabajo reutilizable
Los 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
.
Para que un flujo de trabajo sea reutilizable, los valores de on
deben incluir workflow_call
:
on:
workflow_call:
Utilizar entradas y secretos en un flujo de trabajo reutilizable
Puede 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.
-
En el flujo de trabajo reutilizable, use las palabras clave
inputs
ysecrets
para definir entradas o secretos que se enviarán desde un flujo de trabajo que inicia una llamada.on: workflow_call: inputs: config-path: required: true type: string secrets: envPAT: required: true
Para obtener más información sobre la sintaxis para definir entradas y secretos, consulte on.workflow_call.inputs
y on.workflow_call.secrets
.
-
En el flujo de trabajo reutilizable, haz referencia a la entrada o el secreto que definiste en la clave
on
del paso anterior.Nota: Si los secretos se heredan mediante
secrets: inherit
flujos de trabajo de llamada, puede hacer referencia a ellos incluso si no están definidos en laon
clave. Para obtener más información, vea «Sintaxis del flujo de trabajo para Acciones de GitHub».jobs: reusable_workflow_job: runs-on: ubuntu-latest environment: production steps: - uses: actions/labeler@v4 with: repo-token: ${{ secrets.envPAT }} configuration-path: ${{ inputs.config-path }}
En el ejemplo anterior, envPAT
es un secreto de entorno que se ha agregado al entorno production
. Por lo tanto, este ambiente se referencia dentro del job.
Nota: Los secretos de entorno son cifradas que se almacenan en un entorno definido para un repositorio. Los secretos de ambiente solo se encuentran disponibles para los jobs de flujo de trabajo que referencian al ambiente adecuado. Para obtener más información, vea «Utilizar ambientes para el despliegue».
-
Pasa la entrada o secreto desde el flujo de trabajo llamante.
Para pasar entradas con nombre a un flujo de trabajo con nombre, use la palabra clave
with
en un trabajo. Use la palabra clavesecrets
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).jobs: call-workflow-passing-data: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main with: config-path: .github/labeler.yml secrets: envPAT: ${{ secrets.envPAT }}
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.jobs: call-workflow-passing-data: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main with: config-path: .github/labeler.yml secrets: inherit
Flujo de trabajo reutilizable de ejemplo
Este 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) toma una cadena de entrada y un secreto del flujo que inicia la llamada y lo utiliza en una acción.
name: Reusable workflow example on: workflow_call: inputs: config-path: required: true type: string secrets: token: required: true jobs: triage: runs-on: ubuntu-latest steps: - uses: actions/labeler@v4 with: repo-token: ${{ secrets.token }} configuration-path: ${{ inputs.config-path }}
name: Reusable workflow example
on:
workflow_call:
inputs:
config-path:
required: true
type: string
secrets:
token:
required: true
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v4
with:
repo-token: ${{ secrets.token }}
configuration-path: ${{ inputs.config-path }}
Llamar a un flujo de trabajo reutilizable
Para 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.
Puede hacer referencia a archivos de flujo de trabajo reutilizables mediante una de las sintaxis siguientes:
{owner}/{repo}/.github/workflows/{filename}@{ref}
para flujos de trabajo reutilizables en repositorios públicos, internos y privados../.github/workflows/{filename}
para flujos de trabajo reutilizables en el mismo repositorio.
En 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 obtener más información, vea «Fortalecimiento de seguridad para GitHub Actions».
Si 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
.
Puede llamar a flujos de trabajo múltiples, referenciando cada uno en un job separado.
jobs:
call-workflow-1-in-local-repo:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
call-workflow-2-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
call-workflow-in-another-repo:
uses: octo-org/another-repo/.github/workflows/workflow.yml@v1
Pasar entradas y secretos a un flujo de trabajo reutilizable
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).
jobs:
call-workflow-passing-data:
uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
with:
config-path: .github/labeler.yml
secrets:
envPAT: ${{ secrets.envPAT }}
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.
jobs:
call-workflow-passing-data:
uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
with:
config-path: .github/labeler.yml
secrets: inherit
Uso de una estrategia de matriz con un flujo de trabajo reutilizable
Los trabajos que usan la estrategia de matriz pueden llamar a un flujo de trabajo reutilizable.
Una 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, consulte "Uso de una matriz para tus trabajos".
El 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.
jobs: ReuseableMatrixJobForDeployment: strategy: matrix: target: [dev, stage, prod] uses: octocat/octo-repo/.github/workflows/deployment.yml@main with: target: ${{ matrix.target }}
jobs:
ReuseableMatrixJobForDeployment:
strategy:
matrix:
target: [dev, stage, prod]
uses: octocat/octo-repo/.github/workflows/deployment.yml@main
with:
target: ${{ matrix.target }}
Palabras clave compatibles con los jobs que llaman a un flujo de trabajo reutilizable
Cuando llama a un flujo de trabajo reutilizable, solo puede utilizar las siguientes palabras clave en el job que contiene la llamada:
-
Nota:
- Si no se especifica
jobs.<job_id>.permissions
en el trabajo que inicia la llamada, el flujo de trabajo que la recibe tendrá los permisos predeterminados deGITHUB_TOKEN
. Para obtener más información, vea «Autenticación automática de tokens». - Los permisos de
GITHUB_TOKEN
que se trasladaron desde el flujo de trabajo que inició la llamada solo pueden reducirse (no aumentarse) a través del flujo de trabajo que recibió la llamada. - Si usa
jobs.<job_id>.concurrency.cancel-in-progress: true
, no use el mismo valor parajobs.<job_id>.concurrency.group
en los flujos de trabajo de receptor de llamada y autor de llamada, ya que esto hará que el flujo de trabajo que ya se esté ejecutando se cancele. Un flujo de trabajo de receptor de llamada usa el nombre de su flujo de trabajo de autor de llamada en ${{ github.workflow }}, por lo que el uso de este contexto como valor dejobs.<job_id>.concurrency.group
en los flujos de trabajo de autor de llamada y receptor de llamada hará que el flujo de trabajo de autor de llamada se cancele cuando se ejecute el flujo de trabajo de receptor de llamada.
- Si no se especifica
Flujo de trabajo llamante de ejemplo
Este 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), recibe una entrada (config-path
) y un secreto (token
).
name: Call a reusable workflow on: pull_request: branches: - main jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1 call-workflow-passing-data: permissions: contents: read pull-requests: write uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main with: config-path: .github/labeler.yml secrets: token: ${{ secrets.GITHUB_TOKEN }}
name: Call a reusable workflow
on:
pull_request:
branches:
- main
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1
call-workflow-passing-data:
permissions:
contents: read
pull-requests: write
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
config-path: .github/labeler.yml
secrets:
token: ${{ secrets.GITHUB_TOKEN }}
Anidación de flujos de trabajo reutilizables
Puede conectar un máximo de cuatro niveles de flujos de trabajo, es decir, el flujo de trabajo del autor de la llamada de nivel superior y hasta tres niveles de flujos de trabajo reutilizables. Por ejemplo: caller-workflow.yml → called-workflow-1.yml → called-workflow-2.yml → called-workflow-3.yml. No se permiten bucles en el árbol de flujo de trabajo.
Desde dentro de un flujo de trabajo reutilizable, puede llamar a otro flujo de trabajo reutilizable.
name: Reusable workflow on: workflow_call: jobs: call-another-reusable: uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1
name: Reusable workflow
on:
workflow_call:
jobs:
call-another-reusable:
uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1
Pasar secretos a flujos de trabajo anidados
Puede 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" anterior y el artículo de referencia "Sintaxis del flujo de trabajo para Acciones de GitHub". 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.
En 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.
jobs:
workflowA-calls-workflowB:
uses: octo-org/example-repo/.github/workflows/B.yml@main
secrets: inherit # pass all secrets
jobs:
workflowB-calls-workflowC:
uses: different-org/example-repo/.github/workflows/C.yml@main
secrets:
envPAT: ${{ secrets.envPAT }} # pass just this secret
Acceso y permisos
Se producirá un error en un flujo de trabajo que contenga flujos de trabajo reutilizables anidados si alguno de los flujos de trabajo anidados no es accesible para el flujo de trabajo inicial del autor de la llamada. Para obtener más información, vea «Reutilización de flujos de trabajo».
Los permisos GITHUB_TOKEN
solo pueden ser los mismos o más restrictivos en los flujos de trabajo anidados. Por ejemplo, en la cadena de flujo de trabajo A > B > C, si el flujo de trabajo A tiene permiso de token package: read
, por lo que B y C no pueden tener permiso package: write
. Para obtener más información, vea «Autenticación automática de tokens».
Para obtener información sobre cómo usar la API para determinar qué archivos de flujo de trabajo participaron en una ejecución de flujo de trabajo determinada, consulta: "Supervisión de qué flujos de trabajo se están usando".
Utilizar salidas desde un flujo de trabajo reutilizable
Un flujo de trabajo reutilizable podría generar datos que quieras utilizar en el flujo de trabajo llamante. Para utilizar estas salidas, debes especificarlas como las salidas del flujo de trabajo reutilizable .
Si 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. Esto 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 completado.
Los 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
.
name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT
name: Reusable workflow
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.firstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "firstword=hello" >> $GITHUB_OUTPUT
- id: step2
run: echo "secondword=world" >> $GITHUB_OUTPUT
Ahora 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.
name: Call a reusable workflow and use its outputs on: workflow_dispatch: jobs: job1: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1 job2: runs-on: ubuntu-latest needs: job1 steps: - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
name: Call a reusable workflow and use its outputs
on:
workflow_dispatch:
jobs:
job1:
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
Para obtener más información sobre el uso de salidas de trabajo, consulte "Sintaxis del flujo de trabajo para Acciones de GitHub". Si desea compartir algo distinto de una variable (por ejemplo, un artefacto de compilación) entre flujos de trabajo, consulte "Almacenar los datos de los flujos de trabajo como artefactos".
Monitorear qué flujos de trabajo se están utilizando
Puede utilizar la API de REST de GitHub para monitorear cómo se utilizan los flujos de trabajo reutilizables. La acción de registro de auditoría prepared_workflow_job
se desencadena cuando se inicia un trabajo de flujo de trabajo. Entre los datos registrados se incluyen:
-
repo
: la organización o el repositorio donde se ubica el trabajo de flujo de trabajo. Para un job que llama a otro flujo de trabajo, esta es la organización/repositorio del flujo llamador. -
@timestamp
: la fecha y hora en que se inició el trabajo, en formato de tiempo de Unix. -
job_name
: el nombre del trabajo que se ejecutó. -
calling_workflow_refs
: una matriz de rutas de acceso de archivo para todos los flujos de trabajo del autor de la llamada implicados en este trabajo del flujo de trabajo. Los elementos de la matriz están en el orden inverso con el que se llamaron. Por ejemplo, en una cadena de flujos de trabajo A > B > C, al ver los registros de un trabajo en el flujo de trabajo C, la matriz será["octo-org/octo-repo/.github/workflows/B.yml", "octo-org/octo-repo/.github/workflows/A.yml"]
. -
calling_workflow_shas
: una matriz de varios SHA para todos los flujos de trabajo del autor de la llamada implicados en este trabajo del flujo de trabajo. La matriz contiene el mismo número de elementos, y en el mismo orden, que la matrizcalling_workflow_refs
. -
job_workflow_ref
: el archivo de flujo de trabajo que se usó, con el formato{owner}/{repo}/{path}/{filename}@{ref}
. Para un job que llama a otro flujo de trabajo, esto identifica al flujo llamado.
Para obtener información sobre el uso de la API de REST para consultar el registro de auditoría de una organización, consulte "Puntos de conexión de API REST para organizaciones".
Nota: Los datos de auditoría de prepared_workflow_job
solo se pueden ver mediante la API de REST. No se puede ver en la interfaz web de GitHub ni se incluye en los datos de auditoría exportados en JSON/CSV.
Volver a ejecutar flujos de trabajo y trabajos con flujos de trabajo reutilizables
Se puede hacer referencia a flujos de trabajo reutilizables de repositorios públicos mediante SHA, una etiqueta de versión o un nombre de rama. Para obtener más información, vea «Reutilización de flujos de trabajo».
Cuando se vuelve a ejecutar un flujo de trabajo que usa un flujo de trabajo reutilizable y la referencia no es SHA, hay algunos comportamientos que se deben tener en cuenta:
- Al volver a ejecutar todos los trabajos de un flujo de trabajo, se usará el flujo de trabajo reutilizable de la referencia especificada. Para más información sobre cómo volver a ejecutar todos los trabajos de un flujo de trabajo, consulta: "Volver a ejecutar flujos de trabajo y jobs".
- Volver a ejecutar trabajos con errores o un trabajo específico en un flujo de trabajo usará el flujo de trabajo reutilizable desde el mismo SHA de confirmación del primer intento. Para más información sobre cómo volver a ejecutar todos los trabajos fallidos de un flujo de trabajo, consulta: "Volver a ejecutar flujos de trabajo y jobs". Para más información sobre cómo volver a ejecutar un trabajo específico de un flujo de trabajo, consulta: "Volver a ejecutar flujos de trabajo y jobs".
Pasos siguientes
Para continuar el aprendizaje sobre GitHub Actions, consulte "Eventos que desencadenan flujos de trabajo".
Puede estandarizar las implementaciones creando un grupo de ejecutores autohospedado que solo ejecute un flujo de trabajo reutilizable. Para más información, consulta "Administración del acceso a los ejecutores autohospedados mediante grupos".