Reutilización de configuraciones de flujo de trabajo

Flujos de trabajo reutilizables

Información de referencia para flujos de trabajo reutilizables.

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 invocado se almacena en un repositorio público y tu organización te permite usar flujos de trabajo públicos reutilizables.
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 más información, consulte Compartir acciones y flujos de trabajo con tu organización y Uso compartido de acciones y flujos de trabajo desde el repositorio privado.

En la tabla siguiente se muestra la accesibilidad de los flujos de trabajo reutilizables a un flujo de trabajo de llamada, en función de la visibilidad del repositorio host.

Repositorio del autor de la llamada	Repositorios de flujos de trabajo accesibles
`private`	`private` y `public`
`public`	`public`

Los permisos de acciones de la página de configuración de acciones del repositorio de llamadores deben configurarse para permitir el uso de acciones y flujos de trabajo reutilizables; consulte Administrar los ajustes de las GitHub Actions de un repositorio.

Para repositorios privados, la directiva de acceso de la página de configuración de acciones del repositorio del flujo de trabajo llamado debe configurarse explícitamente para permitir el acceso desde un repositorio que contenga flujos de trabajo de llamador; consulte Administrar los ajustes de las GitHub Actions de un repositorio.

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.

Limitaciones de los flujos de trabajo reutilizables

Puede conectar hasta diez 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 50 flujos de trabajo reutilizables únicos desde un único archivo de flujo de trabajo. 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 más información, consulta Almacenamiento de información en variables y Referencia de 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 contexto env 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, consulta 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 más información, consulte Almacenamiento de información en variables y Referencia de 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.

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:

jobs.<job_id>.name
jobs.<job_id>.uses
jobs.<job_id>.with
jobs.<job_id>.with.<input_id>
jobs.<job_id>.secrets
jobs.<job_id>.secrets.<secret_id>
jobs.<job_id>.secrets.inherit
jobs.<job_id>.strategy
jobs.<job_id>.needs
jobs.<job_id>.if
jobs.<job_id>.concurrency
jobs.<job_id>.permissions
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 de GITHUB_TOKEN. Para más información, consulta Sintaxis del flujo de trabajo para GitHub Actions.
- 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 para jobs.<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 de jobs.<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.

Uso de ejecutores en flujos de trabajo reutilizables

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 más información, consulta Ejecutores hospedados en GitHub.

Ejecutores autohospedados

Los flujos de trabajo llamados que pertenecen al mismo usuario u organización 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, de la organización del repositorio, siempre y cuando se haya hecho disponible al ejecutor para el repositorio llamante

Acceso y permisos para flujos de trabajo anidados

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 más información, consulta Acceso a flujos de trabajo reutilizables.

          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`, entonces B y C no pueden tener permiso `package: write`. Para más información, consulta [AUTOTITLE](/actions/security-guides/automatic-token-authentication).

Para obtener información sobre cómo usar la API para determinar qué archivos de flujo de trabajo han participado en una ejecución de flujo de trabajo determinada, consulta Reutilización de flujos de trabajo.

Comportamiento de los flujos de trabajo reutilizables al volver a ejecutar trabajos

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 más información, consulta 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 con error 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.

Contexto `github`

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, consulta Referencia de contextos.

Plantillas de flujos de trabajo

Información de referencia que se usará al crear plantillas de flujo de trabajo para tu organización.

Disponibilidad de plantillas de flujo de trabajo

Puedes usar plantillas en repositorios que coincidan o tengan una visibilidad más restringida que el repositorio de plantillas.

Las plantillas de flujo de trabajo de un repositorio público de .github están disponibles para todos los tipos de repositorio.
Las plantillas de flujo de trabajo de un repositorio interno de .github solo están disponibles para repositorios internos y privados.
Las plantillas de flujo de trabajo de un repositorio privado de .github solo están disponibles para repositorios privados.

Concesión de acceso para repositorios privados e internos

Si usas un repositorio privado o interno de .github, debes conceder acceso de lectura a los usuarios o equipos que deberían poder usar las plantillas.

Marcador de posición `$default-branch`

Si necesitas hacer referencia a la rama predeterminada de un repositorio, puedes usar el marcador de posición $default-branch en la plantilla de flujo de trabajo. Cuando un flujo de trabajo se crea, el marcador de posición se reemplazará automáticamente con el nombre de la rama predeterminada del repositorio.

Ejemplo de archivo de plantilla de flujo de trabajo

Este archivo denominado octo-organization-ci.yml muestra un flujo de trabajo básico.

YAML

name: Octo Organization CI
on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run a one-line script
        run: echo Hello from Octo Organization

name: Octo Organization CI
on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run a one-line script
        run: echo Hello from Octo Organization

Requisitos del archivo de metadatos

El archivo de metadatos debe tener el mismo nombre que el archivo de flujo de trabajo, pero en lugar de la extensión .yml, se le tiene que anexar .properties.json. Por ejemplo, un archivo denominado octo-organization-ci.properties.json contiene los metadatos del archivo de flujo de trabajo denominado octo-organization-ci.yml.

JSON

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

        `name`
         - 
        **Obligatorio.** El nombre del flujo de trabajo. Esta se muestra en la lista de flujos de trabajo disponibles.

        `description`
         - 
        **Obligatorio.** La descripción del flujo de trabajo. Esta se muestra en la lista de flujos de trabajo disponibles.

```
        `iconName`
         - 
        **Opcional.** Especifica un icono para el flujo de trabajo que se muestra en la lista de flujos de trabajo. 
        `iconName` puede ser uno de los siguientes tipos:
```
- Un archivo SVG que se almacena en el directorio workflow-templates. Para hacer referencia a un archivo, el valor debe ser el nombre de archivo sin la extensión de archivo. Por ejemplo, se hace referencia a un archivo SVG denominado example-icon.svg como example-icon.
- Un icono del conjunto de Octicons de GitHub. Para hacer referencia a un octicon, el valor debe ser octicon <icon name>. Por ejemplo: octicon smiley.
```
        `categories`
         - 
        **Opcional.** Define las categorías en las que se muestra el flujo de trabajo. Puede usar nombres de categoría de las listas siguientes:
```
- Nombres de categoría generales del repositorio starter-workflows.
- Idiomas lingüistas de la lista del repositorio linguist.
- Pilas técnicas admitidas en la lista en el repositorio starter-workflows.

        `filePatterns`
         - 
        **Opcional.** Permite usar el flujo de trabajo si el repositorio del usuario tiene un archivo en su directorio raíz que coincide con una expresión regular definida.

Delimitadores y alias de YAML

Puedes usar delimitadores y alias de YAML para reducir la repetición en los flujos de trabajo. Un delimitador (marcado con &) identifica un fragmento de contenido que deseas reutilizar, mientras que un alias (marcado con *) repite ese contenido en otra ubicación.

Para obtener información detallada sobre los delimitadores y alias, consulta Anclajes y alias de nodo en la especificación YAML.

Este es un ejemplo que usa delimitadores y alias YAML con variables de entorno:

jobs:
  job1:
    env: &env_vars # Define the anchor on first use
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Using production settings"

  job2:
    env: *env_vars # Reuse the environment variables
    steps:
      - run: echo "Same environment variables here"

Esto equivale a escribir el siguiente YAML sin delimitadores ni alias:

jobs:
  job1:
    env:
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Using production settings"

  job2:
    env:
      NODE_ENV: production
      DATABASE_URL: ${{ secrets.DATABASE_URL }}
    steps:
      - run: echo "Same environment variables here"

También puedes usar delimitadores para configuraciones más complejas, como reutilizar una configuración de trabajo completa:

jobs:
  test: &base_job # Define the anchor on first use
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      NODE_VERSION: '18'
    steps:
      - uses: actions/checkout@v5
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm test

  alt-test: *base_job # Reuse the entire job configuration

Reutilización de configuraciones de flujo de trabajo

En este artículo