# Reutilización de configuraciones de flujo de trabajo Busque información sobre cómo evitar la duplicación al crear un flujo de trabajo mediante la reutilización de flujos de trabajo existentes y el uso de anclajes de YAML. ## Flujos de trabajo reutilizables En este artículo se proporciona información de referencia para flujos de trabajo reutilizables y plantillas de flujo de trabajo, incluidas las reglas de acceso, las limitaciones, las palabras clave admitidas y el comportamiento del ejecutor. Puede centralizar la lógica determinista y repetible en flujos de trabajo reutilizables y usar agentic workflows para tareas que requieren juicio contextual sobre el contenido del repositorio, como análisis, resúmenes y recomendaciones. Para más información, consulta [Creación de flujos de trabajo agente de GitHub](/es/copilot/how-tos/github-agentic-workflows/creating-github-agentic-workflows). ### 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 denominado se almacena en un repositorioy su le permiten usar flujos de trabajo reutilizables públicos. * 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 organización](/es/actions/how-tos/reuse-automations/share-with-your-organization) y [Uso compartido de acciones y flujos de trabajo desde el repositorio privado](/es/actions/how-tos/reuse-automations/share-across-private-repositories). 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` | | | `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 [Administración de la configuración de Acciones de GitHub para un repositorio](/es/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). Para privados, la **política de acceso** en la página de configuración de Acciones del repositorio del flujo de trabajo llamado debe configurarse explícitamente para permitir el acceso desde repositorios que contienen flujos de trabajo que llaman; consulte [Administración de la configuración de Acciones de GitHub para un repositorio](/es/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). > \[!NOTE] > 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](/es/actions/how-tos/reuse-automations/reuse-workflows#nesting-reusable-workflows). * Puede llamar a un máximo de 50 flujos de trabajo únicos reutilizables a través de 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](/es/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) y [Contextos de referencia](/es/actions/reference/workflows-and-actions/contexts#env-context). * 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](/es/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow). * 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, consulta [Almacenamiento de información en variables](/es/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) y [Contextos de referencia](/es/actions/reference/workflows-and-actions/contexts#vars-context). * 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..name`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idname) * [`jobs..uses`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iduses) * [`jobs..with`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) * [`jobs..with.`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwithinput_id) * [`jobs..secrets`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecrets) * [`jobs..secrets.`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretssecret_id) * [`jobs..secrets.inherit`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit) * [`jobs..strategy`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy) * [`jobs..needs`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds) * [`jobs..if`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idif) * [`jobs..concurrency`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency) * [`jobs..permissions`](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions) > \[!NOTE] > > * Si no se especifica `jobs..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 Acciones de GitHub](/es/actions/reference/workflows-and-actions/workflow-syntax#permissions). > * 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..concurrency.cancel-in-progress: true`, no use el mismo valor para `jobs..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. El flujo de trabajo llamado utiliza el nombre del flujo de trabajo que realiza la llamada en ${{ github.workflow }}, por lo que si se usa este contexto como valor de `jobs..concurrency.group` tanto en el flujo de trabajo que hace la llamada como en al que llaman, el flujo de trabajo que realiza la llamada se cancelará cuando se ejecute el flujo de trabajo llamado. ### Uso de ejecutores en flujos de trabajo reutilizables #### Ejecutores alojados en GitHub La asignación de ejecutores alojados en GitHub siempre se evalúa usando solo el contexto del proceso o entidad que llama. La facturación de los ejecutores alojados en GitHub siempre está asociada al proceso o entidad que invoca. El flujo de trabajo del proceso o entidad que realiza la llamada no puede usar ejecutores alojados en GitHub a través del repositorio al que se llama. Para más información, consulta [Ejecutores hospedados en GitHub](/es/actions/concepts/runners/github-hosted-runners). #### Ejecutores autohospedados Los flujos de trabajo que se llaman que pertenecen al mismo usuario o organización como el flujo de trabajo que realiza la llamada puede acceder a los ejecutores autohospedados según el contexto del proceso o entidad que invoca. 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 del repositorio que invoca, siempre que el ejecutor esté disponible para el repositorio que invoca ### 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](#access-to-reusable-workflows). 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 [Uso de GITHUB\_TOKEN para la autenticación en flujos de trabajo](/es/actions/tutorials/authenticate-with-github_token). 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](/es/actions/how-tos/reuse-automations/reuse-workflows#monitoring-which-workflows-are-being-used). ### 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](/es/actions/how-tos/reuse-automations/reuse-workflows#calling-a-reusable-workflow). 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 tareas](/es/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-all-the-jobs-in-a-workflow). * 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 tareas](/es/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow). 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 tareas](/es/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-a-specific-job-in-a-workflow). ### 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 [Contextos de referencia](/es/actions/reference/workflows-and-actions/contexts#github-context). ## 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 copy name: Octo Organization CI on: push: branches: [ $default-branch ] pull_request: branches: [ $default-branch ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - 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 copy { "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](https://primer.style/octicons/) de GitHub. Para hacer referencia a un octicon, el valor debe ser `octicon `. 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](https://github.com/actions/starter-workflows/blob/main/README.md#categories). * Idiomas lingüistas de la lista del repositorio [linguist](https://github.com/github-linguist/linguist/blob/main/lib/linguist/languages.yml). * Pilas técnicas admitidas en la lista en el repositorio [starter-workflows](https://github.com/github-starter-workflows/repo-analysis-partner/blob/main/tech_stacks.yml). * `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](https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases). Este es un ejemplo que usa delimitadores y alias YAML con variables de entorno: ```yaml 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: ```yaml 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: ```yaml 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@v6 - name: Set up Node.js uses: actions/setup-node@v7 with: node-version: ${{ env.NODE_VERSION }} - run: npm test alt-test: *base_job # Reuse the entire job configuration ```