Workflow syntax for GitHub Actions

About YAML syntax for workflows

Workflow files use YAML syntax, and must have either a .yml or .yaml file extension. Si eres nuevo en YAML y quieres aprender más, consulta la guía "Aprende YAML en Y minutos".

You must store workflow files in the .github/workflows directory of your repository.

name

The name of your workflow. GitHub displays the names of your workflows on your repository's actions page. If you omit name, GitHub sets it to the workflow file path relative to the root of the repository.

on

To automatically trigger a workflow, use on to define which events can cause the workflow to run. Para obtener una lista de eventos disponibles, consulta "Eventos que desencadenan flujos de trabajo".

You can define single or multiple events that can a trigger workflow, or set a time schedule. You can also restrict the execution of a workflow to only occur for specific files, tags, or branch changes. Estas opciones se describen en las siguietnes secciones.

Utilizar un evento simple

Por ejemplo, un flujo de trabajo con el siguiente valor de on se ejecutará cuando se realice una subida a cualquier rama en el repositorio del flujo de trabajo:

on: push 

Utilizar eventos múltiples

Puedes especificar eventos sencillos o múltiples. Por ejemplo, un flujo de trabajo con el siguiente valor de on se ejecutará cuando se haga una subida a cualquier rama del repositorio o cuando alguien lo bifurque:

on: [push, fork] 

Si especificas eventos múltiples, únicamente uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren eventos múltiples de activación para tu flujo de trabajo al mismo tiempo, se activarán las ejecuciones de flujo de trabajo múltiples.

Utilizar tipos de actividad

Algunos eventos tienen tipos de actividad que te proporcionan más control sobre cuándo debería ejecutarse tu flujo de trabajo. Use on.<event_name>.types to define the type of event activity that will trigger a workflow run.

Por ejemplo, el evento issue_comment tiene los tipos de actividad created, edited y deleted. Si tu flujo de trabajo activa el evento label, este se ejecutará cada que se cree, edite o borre una etiqueta. Si especificas el tipo de actividad created para el evento label, tu flujo de trabajo se ejecutará cuando se cree una etiqueta pero no cuando esta se borre o edite.

on: label: types: - created 

Si especificas tipos de actividad múltiples, solo uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren tipos de actividad de eventos activadores múltiples al mismo tiempo para tu flujo de trabajo, se activarán ejecuciones de flujo de trabajo múltiples. Por ejemplo, el siguiente flujo de trabajo se activa cuando se abre o etiqueta una propuesta. Si se abre una propuesta con dos etiquetas, iniciarán tres ejecuciones de flujo de trabajo: una para el evento de la propuesta abierta y dos para los eventos etiquetados de las dos propuestas.

on: issue: types: - opened - labeled 

Para obtener más información acerca de cada evento y sus tipos de actividad, consulta "Eventos que desencadenan flujos de trabajo".

Utilizar filtros

Algunos eventos tienen filtros que te dan más control sobre qué flujo de trabajo debería ejecutarse.

Por ejemplo, el evento push tiene un filtro branches que ocasiona que tu flujo de trabajo se ejecute únicamente cuando ocurra una subida a una rama que empate con el filtro branches, en vez de cuando ocurra una subida.

on: push: branches: - main - 'releases/**' 

Utilizar los tipos de actividad y filtros con eventos múltiples

Si especificas los tipos de actividad o filtros para un evento y tu flujo de trabajo activa eventos múltiples, deberás configurar cada uno de ellos por separado. Debes agregar dos puntos (:) a todos los eventos, incluyendo aquellos sin configuración.

Por ejemplo, un flujo de trabajo con el siguiente valor on se ejecutará cuando:

• Se crea una etiqueta
• Se hace una subida a la rama main en el repositorio
• Se hace una subida a la rama habilitada por Páginas de GitHub

on: label: types: - created push: branches: - main page_build: 

on.<event_name>.types

Use on.<event_name>.types to define the type of activity that will trigger a workflow run. La mayoría de los eventos GitHub son desencadenados por más de un tipo de actividad. Por ejemplo, la label se activa cuando esta está como created, edited o deleted. La palabra clave types (tipos) te permite reducir la actividad que hace que se ejecute el flujo de trabajo. Cuando solo un tipo de actividad activa el evento webhook, la palabra clave types (tipos) es innecesaria.

Puedes usar una matriz de tipos de eventos. Para obtener más información acerca de cada evento y sus tipos de actividad, consulta "Eventos que desencadenan flujos de trabajo".

on: label: types: [created, edited] 

on.<pull_request|pull_request_target>.<branches|branches-ignore>

Al usar los eventos pull_request y pull_request_target, puedes configurar un flujo de trabajo para que se ejecute únicamente para las solicitudes de cambio que apuntan a ramas específicas.

Utiliza el filtro branches cuando quieras incluir patrones de nombre de rama o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro branches-ignore cuando solo quieras excluir los patrones de nombre de rama. No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo.

Si defines branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando ambos filtros se hayan satisfecho.

Las palabras clave branches y branches-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quieres una coincidencia literal, necesitas escapar a cada uno de estos caracteres especiales con \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

Ejemplo: Incluir ramas

Los patrones que se definen en branches se evalúan contra el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que exista un evento pull_request para una solicitud de cambios que apunte a:

• Una rama de nombre main (refs/heads/main)
• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre inicie con releases/, tal como releases/10 (refs/heads/releases/10)

on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' 

Ejemplo: Excluir ramas

Cuando un patrón empata con el de branches-ignore, el flujo de trabajo no se ejecutará. Los patrones que se definen en branches se evalúan contra el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que haya un evento de pull_request a menos de que la solicitud de cambios apunte a:

• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre empate con releases/**-alpha, tal como beta/3-alpha (refs/releases/beta/3-alpha)

on: pull_request: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' 

Ejemplo: Incluir y excluir ramas

No puedes utilizar branches y branches-ignore para filtrar el mismo evento en un mismo flujo de trabajo. Si quieres tanto incluir como excluir patrones de rama para un solo evento, utiliza el filtro branches junto con el carácter ! para indicar qué ramas deberían excluirse.

Si defines una rama con el carácter !, también debes definir por lo mismo una rama sin el carácter !. Si solo quieres excluir ramas, utiliza branches-ignore en su lugar.

El orden en que defines los patrones importa.

• Un patrón negativo de coincidencia (con prefijo !) luego de una coincidencia positiva excluirá la ref de Git.
• Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.

El siguiente flujo de trabajo se ejecutará en eventos de pull_request para las solicitudes de cambio que apunten a releases/10 o releases/beta/mona, pero para aquellas que empaten con releases/10-alpha o releases/beta/3-alpha, ya que el patrón negativo !releases/**-alpha sigue al patrón positivo.

on: pull_request: branches: - 'releases/**' - '!releases/**-alpha' 

on.push.<branches|tags|branches-ignore|tags-ignore>

Cuando utilices el evento push, podrás configurar un flujo de trabajo para que se ejecute en ramas o etiquetas específicas.

Utiliza el filtro branches cuando quieras incluir patrones de nombre de rama o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro branches-ignore cuando solo quieras excluir los patrones de nombre de rama. No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo.

Utiliza el filtro de tags cuando quieras incluir los patrones de nombre de etiqueta o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro tags-ignore cuando solo quieras excluir los patrones de nombre de etiqueta. No puedes utilizar ambos filtros, tags y tags-ignore, para el mismo evento en un flujo de trabajo.

Si solo defines tags/tag-ignore o solo branches/branches-ignore, el flujo de trabajo no se ejecutará para los eventos que afectan la ref de Git indefinida. Si no defines ni tags/tag-ignore ni branches/branches-ignore, el flujo de trabajo se ejecutará para los eventos que no afecten a ninguna rama o etiqueta. Si defines branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando ambos filtros se hayan satisfecho.

Las palabras clave branches, branches-ignore, tags, y tags-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de una rama o nombre de etiqueta. Si un nombre contiene cualquiera de estos caracteres y quieres tener una coincidencia literal, necesitas escapar cada uno de estos caracteres especiales con una \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

Ejemplo: Incluyendo ramas y etiquetas

Los patrones definidos en branches y tags se evalúan con el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que hubiera un evento de push para:

• Una rama de nombre main (refs/heads/main)
• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre inicie con releases/, tal como releases/10 (refs/heads/releases/10)
• Una etiqueta de nombre v2 (refs/tags/v2)
• Una etiqueta cuyo nombre inicie con v1., tal como v1.9.1 (refs/tags/v1.9.1)

on: push: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' # Sequence of patterns matched against refs/tags tags: - v2 - v1.* 

Ejemplo: Excluir ramas y etiquetas

Cuando un patrón empata con el de branches-ignore o tags-ignore, no se ejecutará el flujo de trabajo. Los patrones definidos en branches y tags se evalúan con el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que haya un evento push, a menos de que el evento push sea para:

• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre empate con releases/**-alpha, tal como beta/3-alpha (refs/releases/beta/3-alpha)
• Una etiqueta de nombre v2 (refs/tags/v2)
• Una etiqueta cuyo nombre inicie con v1., tal como v1.9 (refs/tags/v1.9)

on: push: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' # Sequence of patterns matched against refs/tags tags-ignore: - v2 - v1.* 

Ejemplo: incluir y excluir ramas y etiquetas

No puedes utilizar branches y branches-ignore para filtrar el mismo evento en un solo flujo de trabajo. De forma similar, no puedes utilizar tags y tags-ignore para filtrar el mismo evento en un solo flujo de trabajo. Si quieres incluir y excluir patrones de etiquetas o ramas para un solo evento, utiliza el filtro branches o tags junto con el carácter ! para indicar qué ramas o etiquetas deberían excluirse.

Si defines una rama con el carácter !, también debes definir por lo mismo una rama sin el carácter !. Si solo quieres excluir ramas, utiliza branches-ignore en su lugar. Del mismo modo, si defines una etiqueta con el carácter !, también debes definir por lo menos una etiqueta sin el carácter !. Si solo quieres excluir las etiquetas, utiliza tags-ignore en su lugar.

El orden en que defines los patrones importa.

• Un patrón negativo de coincidencia (con prefijo !) luego de una coincidencia positiva excluirá la ref de Git.
• Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.

El siguiente flujo de trabajo se ejecutará en las subidas a releases/10 o releases/beta/mona, pero no en releases/10-alpha o releases/beta/3-alpha porque el patrón negativo !releases/**-alpha le sigue al patrón positivo.

on: push: branches: - 'releases/**' - '!releases/**-alpha' 

on.<push|pull_request|pull_request_target>.<paths|paths-ignore>

Cuando utilices los eventos push y pull_request, puedes configurar un flujo de trabajo para que se ejecute con base en qué rutas de archivo cambiaron. Los filtros de ruta no se evalúan para subidas de etiquetas.

Utiliza el filtro paths cuando quieras incluir los patrones de ruta de archivo o cuando quieras tanto incluirlos como excluirlos. Use the paths-ignore filter when you only want to exclude file path patterns. You cannot use both the paths and paths-ignore filters for the same event in a workflow.

If you define both branches/branches-ignore and paths, the workflow will only run when both filters are satisfied.

The paths and paths-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. Para obtener más información, consulta "Hoja de referencia de patrones de filtro".

Ejemplo: Incluyendo rutas

Si al menos una ruta coincide con un patrón del filtro de rutas, se ejecuta el flujo de trabajo. For example, the following workflow would run anytime you push a JavaScript file (.js).

on: push: paths: - '**.js' 

Example: Excluding paths

Cuando todos los nombres de ruta coincidan con los patrones en paths-ignore, el flujo de trabajo no se ejecutará. If any path names do not match patterns in paths-ignore, even if some path names match the patterns, the workflow will run.

Un flujo de trabajo con el siguiente filtro de ruta solo se ejecutará en los eventos de subida que incluyan al menos un archivo externo al directorio docs en la raíz del repositorio.

on: push: paths-ignore: - 'docs/**' 

Example: Including and excluding paths

You can not use paths and paths-ignore to filter the same event in a single workflow. If you want to both include and exclude path patterns for a single event, use the paths filter along with the ! character to indicate which paths should be excluded.

If you define a path with the ! character, you must also define at least one path without the ! character. If you only want to exclude paths, use paths-ignore instead.

El orden en que defines los patrones importa:

• Una coincidencia de patrón negativo (con prefijo !) luego de una coincidencia positiva excluirá la ruta.
• Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta.

Este ejemplo se ejecuta cada vez que el evento de subida incluye un archivo en el directorio sub-project o sus subdirectorios, a menos que el archivo esté en el directorio sub-project/docs. Por ejemplo, una subida que haya cambiado sub-project/index.js o sub-project/src/index.js desencadenará una ejecución de flujo de trabajo, pero una subida que cambie solo sub-project/docs/readme.md no lo hará.

on: push: paths: - 'sub-project/**' - '!sub-project/docs/**' 

Comparaciones de diferencias de Git

El filtro determina si un flujo de trabajo se debe ejecutar al evaluar los archivos modificados y al ejecutarlos comparándolos con la lista de paths-ignore o paths. Si no hay archivos modificados, no se ejecutará el flujo de trabajo.

GitHub genera la lista de archivos modificados usando diferencias de dos puntos para las subidas y de tres puntos para las solicitudes de extracción:

• Solicitudes de extracción: las diferencias de tres puntos son una comparación entre la versión más reciente de la rama de tema y la confirmación, cuando la rama de tema se sincronizó por última vez con la rama base.
• Subidas a ramas existentes: una diferencia de dos puntos compara las SHA de encabezado y de base directamente entre sí.
• Subidas a ramas nuevas: una diferencia de dos puntos comparada con el padre del antepasado de la confirmación más profunda subida.

Los diffs se limitan a 300 archivos. Si hay archivos que cambiaron y no se empataron en los primeros 300 archivos que devuelve el filtro, el flujo de trabajo no se ejecutará. Puede que necesites crear filtros más específicos para que el flujo de trabajo se ejecute automáticamente.

Para obtener más información, consulta "Acerca de comparar ramas en las solicitudes de extracción".

on.schedule

You can use on.schedule to define a time schedule for your workflows. Puedes programar un flujo de trabajo para que se ejecute en horarios UTC específicos usando sintaxis de cron POSIX. Los flujos de trabajo programados se ejecutan en la confirmación más reciente en la rama base o en la rama por defecto. El intervalo más corto en el que puedes programar flujos de trabajo es cada 5 minutos.

Este ejemplo activa el flujo de trabajo diariamente a las 5:30 y 17:30 UTC:

on: schedule: # * is a special character in YAML so you have to quote this string - cron: '30 5,17 * * *' 

Se puede activar un flujo de trabajo sencillo mediante eventos múltiples de schedule. Puedes acceder al evento de programación que activó el flujo de trabajo mediante el contexto github.event.schedule. Este ejemplo activa el flujo de trabajo para que se ejecute a las 5:30 UTC cada lunes a viernes, pero se salta el paso Not on Monday or Wednesday para los lunes y miércoles.

on: schedule: - cron: '30 5 * * 1,3' - cron: '30 5 * * 2,4' jobs: test_schedule: runs-on: ubuntu-latest steps: - name: Not on Monday or Wednesday if: github.event.schedule != '30 5 * * 1,3' run: echo "This step will be skipped on Monday and Wednesday" - name: Every time run: echo "This step will always run" 

Para obtener más información acerca de la sintaxis cron, consulta la sección "Eventos que activan flujos de trabajo".

on.workflow_run.<branches|branches-ignore>

When using the workflow_run event, you can specify what branches the triggering workflow must run on in order to trigger your workflow.

Los filtros de branches y branches-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quieres tener una coincidencia literal, necesitas escapar cada uno de estos caracteres especiales con una \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

For example, a workflow with the following trigger will only run when the workflow named Build runs on a branch whose name starts with releases/:

on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' 

A workflow with the following trigger will only run when the workflow named Build runs on a branch that is not named canary:

on: workflow_run: workflows: ["Build"] types: [requested] branches-ignore: - "canary" 

No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo. Si quieres tanto incluir como excluir patrones de rama para un solo evento, utiliza el filtro branches junto con el carácter ! para indicar qué ramas deberían excluirse.

El orden en que defines los patrones importa.

• A matching negative pattern (prefixed with !) after a positive match will exclude the branch.
• A matching positive pattern after a negative match will include the branch again.

Por ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cuando el flujo de trabajo llamado Build se ejecute en una rama que se llame releases/10 o releases/beta/mona pero no en las de nombre releases/10-alpha, releases/beta/3-alpha o main.

on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' - '!releases/**-alpha' 

on.workflow_dispatch.inputs

Cuando se utiliza el evento workflow_dispatch, puedes especificar opcionalmente entradas que se pasan al flujo de trabajo.

El flujo de trabajo que se activa recibe las entradas en el contexto de github.event.inputs. Para obtener más información, consulta "Contextos".

on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' tags: description: 'Test scenario tags' required: false jobs: print-tag: runs-on: ubuntu-latest steps: - name: Print the input tag to STDOUT run: echo The tag is ${{ github.event.inputs.tag }} 

env

A map of environment variables that are available to the steps of all jobs in the workflow. You can also set environment variables that are only available to the steps of a single job or to a single step. For more information, see jobs.<job_id>.env and jobs.<job_id>.steps[*].env.

Cuando se define más de una variable de ambiente con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de ambiente definida en un paso anulará aquellas de los jobs y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras ejecuta el job.

Example

env: SERVER: production 

defaults

Use defaults to create a map of default settings that will apply to all jobs in the workflow. También puedes configurar los ajustes predeterminados que solo estén disponibles para un job. Para obtener más información, consulta la sección jobs.<job_id>.defaults.

Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo.

defaults.run

Puedes utilizar defaults.run para proporcionar opciones predeterminadas de shell y working-directory para todos los pasos de run en un flujo de trabajo. También puedes configurar ajustes predeterminados para run que solo estén disponibles para un job. Para obtener más información, consulta jobs.<job_id>.defaults.run. No podrás utilizar contextos o expresiones en esta palabra clave.

Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo.

Ejemplo: Configurar el directorio de trabajo y shell predeterminados

defaults: run: shell: bash working-directory: scripts 

jobs

A workflow run is made up of one or more jobs, which run in parallel by default. Para ejecutar trabajos de manera secuencial, puedes definir dependencias en otros trabajos utilizando la palabra clave jobs.<job_id>.needs.

Cada job se ejecuta en un ambiente ejecutor que especifica runs-on.

Puedes ejecutar una cantidad ilimitada de trabajos siempre que estés dentro de los límites de uso del flujo de trabajo. Para obtener más información, consulta las secciones "Límites de uso y facturación" para los ejecutores hospedados en GitHub y "Acerca de los ejecutores auto hospedados" para los límites de uso de los ejecutores auto-hospedados.

Si necesitas encontrar el identificador único de un job que se ejecuta en una ejecución de flujo de trabajo, puedes utilizar la API de GitHub Enterprise Server. Para obtener más información, consulta la sección "Jobs de los Flujos de Trabajo".

jobs.<job_id>

Use jobs.<job_id> to give your job a unique identifier. La clave job_id es una cadena y su valor es un mapa de los datos de configuración del trabajo. Debes reemplazar <job_id> con una cadena que sea exclusiva del objeto jobs. El <job_id> debe comenzar con una letra o _ y debe contener solo caracteres alfanuméricos, -, o _.

Example: Creating jobs

En este ejemplo, se crearon dos jobs y sus valores de job_id son my_first_job y my_second_job.

jobs: my_first_job: name: My first job my_second_job: name: My second job 

jobs.<job_id>.name

Use jobs.<job_id>.name to a name for the job, which is displayed on GitHub.

jobs.<job_id>.needs

Use jobs.<job_id>.needs to identify any jobs that must complete successfully before this job will run. Puede ser una cadena o matriz de cadenas. Si un job falla, se saltarán todos los jobs que lo necesiten a menos de que éstos utilicen una expresión condicional que ocasione que el job continúe.

Example: Requiring successful dependent jobs

jobs: job1: job2: needs: job1 job3: needs: [job1, job2] 

En este ejemplo, job1 debe completarse con éxito antes de que job2 comience, y job3 espera a quejob1 y job2 se completen.

En este ejemplo, los trabajos se ejecutan de manera secuencial:

1. job1
2. job2
3. job3

Example: Not requiring successful dependent jobs

jobs: job1: job2: needs: job1 job3: if: ${{ always() }} needs: [job1, job2] 

En este ejemplo, job3 utiliza la expresión condicional always() para que siempre se ejecute después de que el job1 y el job2 se hayan completado, sin importar si tuvieron éxito o no. Para obtener más información, consulta la sección "Expresiones".

jobs.<job_id>.if

You can use the jobs.<job_id>.if conditional to prevent a job from running unless a condition is met. Puedes usar cualquier contexto y expresión admitidos para crear un condicional.

Podrías omitir la sintaxis de expresión cuando utilizas expresiones en un condicional if (${{ }}) ya que GitHub evalúa automáticamente el condicional if como una expresión. Para obtener más información, consulta la sección "Expresiones".

Example: Only run job for specific repository

This example uses if to control when the production-deploy job can run. It will only run if the repository is named octo-repo-prod and is within the octo-org organization. Otherwise, the job will be marked as skipped.

name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: '14' - run: npm install -g bats

jobs.<job_id>.runs-on

Use jobs.<job_id>.runs-on to define the type of machine to run the job on. Puedes proporcionar a runs-on como una secuencia simple o como un arreglo de secuencias. Si especificas un arreglo de secuencias, tu flujo de trabajo se ejecutará en un ejecutor auto-hospedado cuyas etiquetas empaten con todos los valores de runs-on que se hayan especificado, en caso de que estén disponibles. Si te gustaría ejecutar tu flujo de trabajo en máquinas múltiples, utiliza jobs.<job_id>.strategy.

Choosing GitHub-hosted runners

Si usas un ejecutor alojado GitHub, cada trabajo se ejecuta en una nueva instancia de un entorno virtual especificado por runs-on.

Los tipos de ejecutores alojados GitHub disponibles son:

Example: Specifying an operating system

runs-on: ubuntu-latest 

Para obtener más información, consulta "Entornos virtuales para ejecutores alojados de GitHub".

Choosing self-hosted runners

Para especificar un ejecutor auto-hospedado para tu trabajo, configura runs-on en tu archivo de flujo de trabajo con las etiquetas de dicho ejecutor.

Todos los ejecutores auto-hospedados tienen la etiqueta self-hosted. El utilizar únicamente esta etiqueta seleccionará cualquier ejecutor auto-hospedado. Para seleccionar los ejecutores que cumplen con ciertos criterios, tales como el sistema operativo o arquitectura, te recomendamos proporcionar un arreglo de etiquetas que comience con self-hosted (este se debe listar primero) y que luego incluya etiquetas adicionales conforme lo requieras. Cuando especifiques un arreglo de etiquetas, los jobs se pondrán en cola cuando se trate de ejecutores que tengan todas las etiquetas que especificas.

Aunque la etiqueta de self-hosted no se requiere, te recomendamos ampliamente especificarla cuando utilices ejecutores auto-hospedados para garantizar que tu trabajo no especifique algún ejecutor hospedado en GitHub futuro o actual por accidente.

Example: Using labels for runner selection

runs-on: [self-hosted, linux] 

Para obtener más información, consulta "Acerca de los ejecutores autoalojados" y "Usar ejecutores autoalojados en un flujo de trabajo".

jobs.<job_id>.outputs

You can use jobs.<job_id>.outputs to create a map of outputs for a job. Las salidas de un job se encuentran disponibles para todos los jobs descendentes que dependan de este job. Para obtener más información sobre la definición de dependencias, consulta jobs.<job_id>.needs.

Las salidas de un job son secuencias, y las salidas de un job que contienen expresiones se evalúan en el ejecutor al final de cada job. Las salidas que contienen secretos se redactan en el ejecutor y no se envían a GitHub Actions.

Para utilizar salidas de jobs en un job dependiente, puedes utilizar el contexto needs. Para obtener más información, consulta "Contextos".

Example: Defining outputs for a job

jobs: job1: runs-on: ubuntu-latest # Map a step output to a job output outputs: output1: ${{ steps.step1.outputs.test }} output2: ${{ steps.step2.outputs.test }} steps: - id: step1 run: echo "::set-output name=test::hello" - id: step2 run: echo "::set-output name=test::world" job2: runs-on: ubuntu-latest needs: job1 steps: - run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}} 

jobs.<job_id>.env

A map of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see env and jobs.<job_id>.steps[*].env.

Cuando se define más de una variable de ambiente con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de ambiente definida en un paso anulará aquellas de los jobs y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras ejecuta el job.

Example

jobs: job1: env: FIRST_NAME: Mona 

jobs.<job_id>.defaults

Use jobs.<job_id>.defaults to create a map of default settings that will apply to all steps in the job. También puedes configurar ajustes predeterminados para todo el flujo de trabajo. Para obtener más información, consulta defaults.

Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo.

jobs.<job_id>.defaults.run

Use jobs.<job_id>.defaults.run to provide default shell and working-directory to all run steps in the job. No se permiten las expresiones ni contexto en esta sección.

Puedes proporcionar opciones predeterminadas de shell y working-directory para todos los pasos de run en un job. También puedes configurar ajustes predeterminados para run para todo el flujo de trabajo. Para obtener más información, consulta jobs.defaults.run. No podrás utilizar contextos o expresiones en esta palabra clave.

Cuando se define más de una configuración predeterminada con el mismo nombre, GitHub utiliza la configuración predeterminada más específica. Por ejemplo, una configuración predeterminada definida en un job invalidará a aquella que tenga el mismo nombre definido en el flujo de trabajo.

Example: Setting default run step options for a job

jobs: job1: runs-on: ubuntu-latest defaults: run: shell: bash working-directory: scripts 

jobs.<job_id>.steps

A job contains a sequence of tasks called steps. Steps can run commands, run setup tasks, or run an action in your repository, a public repository, or an action published in a Docker registry. Not all steps run actions, but all actions run as a step. Each step runs in its own process in the runner environment and has access to the workspace and filesystem. Because steps run in their own process, changes to environment variables are not preserved between steps. GitHub provides built-in steps to set up and complete a job.

You can run an unlimited number of steps as long as you are within the workflow usage limits. For more information, see "Usage limits and billing" for GitHub-hosted runners and "About self-hosted runners" for self-hosted runner usage limits.

Example

name: Greeting from Mona on: push jobs: my-job: name: My Job runs-on: ubuntu-latest steps: - name: Print a greeting env: MY_VAR: Hi there! My name is FIRST_NAME: Mona MIDDLE_NAME: The LAST_NAME: Octocat run: | echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME. 

jobs.<job_id>.steps[*].id

A unique identifier for the step. You can use the id to reference the step in contexts. For more information, see "Contexts."

jobs.<job_id>.steps[*].if

You can use the if conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.

Podrías omitir la sintaxis de expresión cuando utilizas expresiones en un condicional if (${{ }}) ya que GitHub evalúa automáticamente el condicional if como una expresión. For more information, see "Expressions."

Example: Using contexts

This step only runs when the event type is a pull_request and the event action is unassigned.

steps: - name: My first step if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }} run: echo This event is a pull request that had an assignee removed. 

Example: Using status check functions

The my backup step only runs when the previous step of a job fails. For more information, see "Expressions."

steps: - name: My first step uses: octo-org/action-name@main - name: My backup step if: ${{ failure() }} uses: actions/heroku@1.0.0 

jobs.<job_id>.steps[*].name

A name for your step to display on GitHub.

jobs.<job_id>.steps[*].uses

Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a published Docker container image.

We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.

• Using the commit SHA of a released action version is the safest for stability and security.
• Using the specific major action version allows you to receive critical fixes and security patches while still maintaining compatibility. It also assures that your workflow should still work.
• Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.

Some actions require inputs that you must set using the with keyword. Review the action's README file to determine the inputs required.

Actions are either JavaScript files or Docker containers. If the action you're using is a Docker container you must run the job in a Linux environment. For more details, see runs-on.

Example: Using versioned actions

steps: # Reference a specific commit - uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675 # Reference the major version of a release - uses: actions/checkout@v2 # Reference a specific version - uses: actions/checkout@v2.2.0 # Reference a branch - uses: actions/checkout@main 

Example: Using a public action

{owner}/{repo}@{ref}

You can specify a branch, ref, or SHA in a public GitHub repository.

jobs: my_first_job: steps: - name: My first step # Uses the default branch of a public repository uses: actions/heroku@main - name: My second step # Uses a specific version tag of a public repository uses: actions/aws@v2.0.1 

Example: Using a public action in a subdirectory

{owner}/{repo}/{path}@{ref}

A subdirectory in a public GitHub repository at a specific branch, ref, or SHA.

jobs: my_first_job: steps: - name: My first step uses: actions/aws/ec2@main 

Example: Using an action in the same repository as the workflow

./path/to/dir

The path to the directory that contains the action in your workflow's repository. You must check out your repository before using the action.

jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v2 - name: Use local my-action uses: ./.github/actions/my-action 

Example: Using a Docker Hub action

docker://{image}:{tag}

A Docker image published on Docker Hub.

jobs: my_first_job: steps: - name: My first step uses: docker://alpine:3.8 

Example: Using a Docker public registry action

docker://{host}/{image}:{tag}

A Docker image in a public registry. This example uses the Google Container Registry at gcr.io.

jobs: my_first_job: steps: - name: My first step uses: docker://gcr.io/cloud-builders/gradle 

Example: Using an action inside a different private repository than the workflow

Your workflow must checkout the private repository and reference the action locally. Generate a personal access token and add the token as an encrypted secret. For more information, see "Creating a personal access token" and "Encrypted secrets."

Replace PERSONAL_ACCESS_TOKEN in the example with the name of your secret.

jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v2 with: repository: octocat/my-private-repo ref: v1.0 token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} path: ./.github/actions/my-private-repo - name: Run my action uses: ./.github/actions/my-private-repo/my-action 

jobs.<job_id>.steps[*].run

Runs command-line programs using the operating system's shell. If you do not provide a name, the step name will default to the text specified in the run command.

Commands run using non-login shells by default. You can choose a different shell and customize the shell used to run commands. For more information, see jobs.<job_id>.steps[*].shell.

Each run keyword represents a new process and shell in the runner environment. When you provide multi-line commands, each line runs in the same shell. For example:

• A single-line command:

  - name: Install Dependencies run: npm install 

• A multi-line command:

  - name: Clean install dependencies and build run: | npm ci npm run build 

Using the working-directory keyword, you can specify the working directory of where to run the command.

- name: Clean temp directory run: rm -rf * working-directory: ./temp 

jobs.<job_id>.steps[*].shell

You can override the default shell settings in the runner's operating system using the shell keyword. You can use built-in shell keywords, or you can define a custom set of shell options. The shell command that is run internally executes a temporary file that contains the commands specified in the run keyword.

Example: Running a script using bash

steps: - name: Display the path run: echo $PATH shell: bash 

Example: Running a script using Windows cmd

steps: - name: Display the path run: echo %PATH% shell: cmd 

Example: Running a script using PowerShell Core

steps: - name: Display the path run: echo ${env:PATH} shell: pwsh 

Example: Using PowerShell Desktop to run a script

steps: - name: Display the path run: echo ${env:PATH} shell: powershell 

Example: Running a python script

steps: - name: Display the path run: | import os print(os.environ['PATH'])  shell: python 

Custom shell

You can set the shell value to a template string using command […options] {0} [..more_options]. GitHub interprets the first whitespace-delimited word of the string as the command, and inserts the file name for the temporary script at {0}.

For example:

steps: - name: Display the environment variables and their values run: | print %ENV  shell: perl {0} 

The command used, perl in this example, must be installed on the runner.

Exit codes and error action preference

For built-in shell keywords, we provide the following defaults that are executed by GitHub-hosted runners. You should use these guidelines when running shell scripts.

• bash/sh:

  • Fail-fast behavior using set -eo pipefail: Default for bash and built-in shell. It is also the default when you don't provide an option on non-Windows platforms.
  • You can opt out of fail-fast and take full control by providing a template string to the shell options. For example, bash {0}.
  • sh-like shells exit with the exit code of the last command executed in a script, which is also the default behavior for actions. The runner will report the status of the step as fail/succeed based on this exit code.

• powershell/pwsh

  • Fail-fast behavior when possible. For pwsh and powershell built-in shell, we will prepend $ErrorActionPreference = 'stop' to script contents.
  • We append if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE } to powershell scripts so action statuses reflect the script's last exit code.
  • Users can always opt out by not using the built-in shell, and providing a custom shell option like: pwsh -File {0}, or powershell -Command "& '{0}'", depending on need.

• cmd

  • There doesn't seem to be a way to fully opt into fail-fast behavior other than writing your script to check each error code and respond accordingly. Because we can't actually provide that behavior by default, you need to write this behavior into your script.
  • cmd.exe will exit with the error level of the last program it executed, and it will return the error code to the runner. This behavior is internally consistent with the previous sh and pwsh default behavior and is the cmd.exe default, so this behavior remains intact.

jobs.<job_id>.steps[*].with

A map of the input parameters defined by the action. Each input parameter is a key/value pair. Input parameters are set as environment variables. The variable is prefixed with INPUT_ and converted to upper case.

Example

Defines the three input parameters (first_name, middle_name, and last_name) defined by the hello_world action. These input variables will be accessible to the hello-world action as INPUT_FIRST_NAME, INPUT_MIDDLE_NAME, and INPUT_LAST_NAME environment variables.

jobs: my_first_job: steps: - name: My first step uses: actions/hello_world@main with: first_name: Mona middle_name: The last_name: Octocat 

jobs.<job_id>.steps[*].with.args

A string that defines the inputs for a Docker container. GitHub passes the args to the container's ENTRYPOINT when the container starts up. An array of strings is not supported by this parameter.

Example

steps: - name: Explain why this job ran uses: octo-org/action-name@main with: entrypoint: /bin/echo args: The ${{ github.event_name }} event triggered this step. 

The args are used in place of the CMD instruction in a Dockerfile. If you use CMD in your Dockerfile, use the guidelines ordered by preference:

1. Document required arguments in the action's README and omit them from the CMD instruction.
2. Use defaults that allow using the action without specifying any args.
3. If the action exposes a --help flag, or something similar, use that as the default to make your action self-documenting.

jobs.<job_id>.steps[*].with.entrypoint

Overrides the Docker ENTRYPOINT in the Dockerfile, or sets it if one wasn't already specified. Unlike the Docker ENTRYPOINT instruction which has a shell and exec form, entrypoint keyword accepts only a single string defining the executable to be run.

Example

steps: - name: Run a custom command uses: octo-org/action-name@main with: entrypoint: /a/different/executable 

The entrypoint keyword is meant to be used with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.

jobs.<job_id>.steps[*].env

Sets environment variables for steps to use in the runner environment. You can also set environment variables for the entire workflow or a job. For more information, see env and jobs.<job_id>.env.

Cuando se define más de una variable de ambiente con el mismo nombre, GitHub utiliza la más específica. Por ejemplo, una variable de ambiente definida en un paso anulará aquellas de los jobs y flujos de trabajo con el mismo nombre, mientras ejecuta el paso. Una variable definida para un trabajo anulará aquella de un flujo de trabajo si tienen el mismo nombre, mientras ejecuta el job.

Public actions may specify expected environment variables in the README file. If you are setting a secret in an environment variable, you must set secrets using the secrets context. For more information, see "Using environment variables" and "Contexts."

Example

steps: - name: My first action env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} FIRST_NAME: Mona LAST_NAME: Octocat 

jobs.<job_id>.steps[*].continue-on-error

Prevents a job from failing when a step fails. Set to true to allow a job to pass when this step fails.

jobs.<job_id>.steps[*].timeout-minutes

The maximum number of minutes to run the step before killing the process.

jobs.<job_id>.timeout-minutes

The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360

If the timeout exceeds the job execution time limit for the runner, the job will be canceled when the execution time limit is met instead. For more information about job execution time limits, see "Usage limits and billing" for GitHub-hosted runners and "About self-hosted runners" for self-hosted runner usage limits.

jobs.<job_id>.strategy

Use jobs.<job_id>.strategy to create a build matrix for your jobs. Puedes definir variaciones diferentes para que ejecuten cada job.

jobs.<job_id>.strategy.matrix

Use jobs.<job_id>.strategy.matrix to define a matrix of different job configurations. Una matriz te permite crear múltiples trabajos realizando la sustitución de variables en una definición de trabajo único. Por ejemplo, puedes usar una matriz para crear trabajos para más de una versión compatible de un lenguaje de programación, sistema operativo o herramienta. Una matriz reutiliza la configuración del trabajo y crea un trabajo para cada matriz que configuras.

Una matriz de jobs puede generar un máximo de 256 jobs por ejecución de flujo de trabajo. Este límite también aplica para los ejecutores auto-hospedados.

Cada opción que definas en la matriz tiene una clave y un valor. Las claves que defines se convierten en propiedades en el contexto matriz y puedes hacer referencia a la propiedad en otras áreas de tu archivo de flujo de trabajo. Por ejemplo, si defines la clave os que contiene una matriz de sistemas operativos, puedes usar la propiedad matrix.os como el valor de la palabra clave runs-on para crear un trabajo para cada sistema operativo. Para obtener más información, consulta "Contextos".

El orden en que defines una matriz importa. La primera opción que definas será el primer trabajo que se ejecuta en tu flujo de trabajo.

Ejemplo: Ejecutando versiones múltiples de Node.js

Puedes especificar una matriz proporcionando una variedad de opciones de configuración. Por ejemplo, si el ejecutor admite las versiones 10, 12 y 14 de Node.js, puedes especificar una matriz de esas versiones en la matriz.

Este ejemplo crea una matriz de tres trabajos estableciendo la clave node para una matriz de tres versiones de Node.js. Para usar la matriz, el ejemplo establece la propiedad de contexto matrix.node como el valor del parámetro node-version de la entrada de la acción setup-node. Como resultado, se ejecutarán tres trabajos, cada uno usando una versión diferente de Node.js.

strategy: matrix: node: [10, 12, 14] steps: # Configures the node version used on GitHub-hosted runners - uses: actions/setup-node@v2 with: # The Node.js version to configure node-version: ${{ matrix.node }} 

La acción setup-node es la forma recomendada de configurar una versión de Node.js cuando se usan ejecutores alojados GitHub. Para obtener más información, consulta la acción setup-node.

Ejemplo: Ejecutando sistemas operativos múltiples

Puedes crear una matriz para ejecutar flujos de trabajo en más de un sistema operativo del ejecutor. También puedes especificar más de una configuración de matriz. Este ejemplo crea una matriz de 6 trabajos:

• 2 sistemas operativos especificados en la matriz os
• 3 versiones de Node.js especificadas en la matriz node

Cuando defines una matriz de sistemas operativos, debes modificar el valor de runs-on a la propiedad de contexto de matrix.os que definiste.

runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-18.04, ubuntu-20.04] node: [10, 12, 14] steps: - uses: actions/setup-node@v2 with: node-version: ${{ matrix.node }} 

Para encontrar las opciones de la configuración compatible para los ejecutores hospedados en GitHub, consulta la sección "Ambientes virtuales para los ejecutores hospedados en GitHub".

Example: Including additional values in combinations

Puedes agregar más opciones de configuración a un trabajo de una matriz de construcción ya existente. Por ejemplo, si quieres usar una versión específica de npm cuando se ejecuta el trabajo que usa windows-latest y la versión 8 de node, puedes usar incluir para especificar esa opción adicional.

runs-on: ${{ matrix.os }} strategy: matrix: os: [macos-latest, windows-latest, ubuntu-18.04] node: [8, 10, 12, 14] include: # includes a new variable of npm with a value of 6 # for the matrix leg matching the os and version - os: windows-latest node: 8 npm: 6 

Ejemplo: Incluyendo combinaciones nuevas

Puedes utilizar include para agregar jobs nuevos a una matriz de compilaciones. Cualquier configuración de "include" sin coincidencia exacta e agregará a la matriz. Por ejemplo, si quieres utilizar node versión 14 para compilar en varios sistemas operativos, pero quieres un job experimental extra que utilice node versión 15 en Ubintu, puedes utilizar include para especificar este job adicional.

runs-on: ${{ matrix.os }} strategy: matrix: node: [14] os: [macos-latest, windows-latest, ubuntu-18.04] include: - node: 15 os: ubuntu-18.04 experimental: true 

Ejemplo: Excluyendo las configuraciones de una matriz

Puedes eliminar una configuración específica definida en la matriz de construcción mediante la opción exclude. Si usas exclude, se elimina un puesto definido por la matriz de construcción. El número de puestos es el producto cruzado de la cantidad de sistemas operativos (os) incluidos en las matrices que brindas, menos todas las sustracciones (exclude).

runs-on: ${{ matrix.os }} strategy: matrix: os: [macos-latest, windows-latest, ubuntu-18.04] node: [8, 10, 12, 14] exclude: # excludes node 8 on macOS - os: macos-latest node: 8 

Utilizar variables de ambiente en una matriz

Puedes agregar variables de ambiente personalizadas para cada combinación de prueba si utilizas la clave include. Posteriormente, puedes referirte a las variables de ambiente personalizadas en un paso subsecuente.

En este ejemplo, las entradas de la matriz para node-version se configuran para que cada una utilice valores diferentes para las variables de ambiente site y datacenter. El paso Echo site details utiliza entonces env: ${{ matrix.env }} para referirse a las variables personalizadas:

name: Node.js CI on: [push] jobs: build: runs-on: ubuntu-latest strategy: matrix: include: - node-version: 10.x site: "prod" datacenter: "site-a" - node-version: 12.x site: "dev" datacenter: "site-b" steps: - name: Echo site details env: SITE: ${{ matrix.site }} DATACENTER: ${{ matrix.datacenter }} run: echo $SITE $DATACENTER 

jobs.<job_id>.strategy.fail-fast

When jobs.<job_id>.strategy.fail-fast is set to true, GitHub cancels all in-progress jobs if any matrix job fails. Predeterminado: true

jobs.<job_id>.strategy.max-parallel

Use jobs.<job_id>.strategy.max-parallel to set the maximum number of jobs that can run simultaneously when using a matrix job strategy. De manera predeterminada, GitHub maximizará el número de trabajos ejecutados en paralelo dependiendo de los ejecutadores disponibles en las máquinas virtuales alojadas en GitHub.

strategy: max-parallel: 2 

jobs.<job_id>.continue-on-error

Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.

Example: Preventing a specific failing matrix job from failing a workflow run

You can allow specific jobs in a job matrix to fail without failing the workflow run. For example, if you wanted to only allow an experimental job with node set to 15 to fail without failing the workflow run.

runs-on: ${{ matrix.os }} continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: false matrix: node: [13, 14] os: [macos-latest, ubuntu-18.04] experimental: [false] include: - node: 15 os: ubuntu-18.04 experimental: true 

jobs.<job_id>.container

Use jobs.<job_id>.container to create a container to run any steps in a job that don't already specify a container. Si tienes pasos que usan tanto acciones de script como de contenedor, las acciones de contenedor se ejecutarán como contenedores hermanos en la misma red con los mismos montajes de volumen.

Si no configuras un container, todos los pasos se ejecutan directamente en el host especificado por runs-on a menos que un paso se refiera a una acción configurada para ejecutarse en un contenedor.

Example: Running a job within a container

jobs: my_job: container: image: node:14.16 env: NODE_ENV: development ports: - 80 volumes: - my_docker_volume:/volume_mount options: --cpus 1 

Cuando solo especificas una imagen de contenedor, puedes omitir la palabra clave image.

jobs: my_job: container: node:14.16 

jobs.<job_id>.container.image

Use jobs.<job_id>.container.image to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.

jobs.<job_id>.container.credentials

Si el registro del contenedor de la imagen requiere autenticación para extraerla, puedes utilizar jobs.<job_id>.container.credentials para configurar un map del username y password. Las credenciales son los mismos valores que proporcionarías al comando de docker login.

Example: Defining credentials for a container registry

container: image: ghcr.io/owner/image credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} 

jobs.<job_id>.container.env

Use jobs.<job_id>.container.env to set a map of environment variables in the container.

jobs.<job_id>.container.ports

Use jobs.<job_id>.container.ports to set an array of ports to expose on the container.

jobs.<job_id>.container.volumes

Use jobs.<job_id>.container.volumes to set an array of volumes for the container to use. Puedes usar volúmenes para compartir datos entre servicios u otros pasos en un trabajo. Puedes especificar volúmenes Docker con nombre, volúmenes Docker anónimos o montajes de enlace en el host.

Para especificar un volumen, especifica la ruta de origen y destino:

<source>:<destinationPath>.

<source> es un nombre de volumen o una ruta absoluta en la máquina host, y <destinationPath> es una ruta absoluta en el contenedor.

Example: Mounting volumes in a container

volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory 

jobs.<job_id>.container.options

Use jobs.<job_id>.container.options to configure additional Docker container resource options. Para obtener una lista de opciones, consulta las opciones "crear docker".

jobs.<job_id>.services

Used to host service containers for a job in a workflow. Service containers are useful for creating databases or cache services like Redis. The runner automatically creates a Docker network and manages the life cycle of the service containers.

If you configure your job to run in a container, or your step uses container actions, you don't need to map ports to access the service or action. Docker automatically exposes all ports between containers on the same Docker user-defined bridge network. You can directly reference the service container by its hostname. The hostname is automatically mapped to the label name you configure for the service in the workflow.

If you configure the job to run directly on the runner machine and your step doesn't use a container action, you must map any required Docker service container ports to the Docker host (the runner machine). You can access the service container using localhost and the mapped port.

For more information about the differences between networking service containers, see "About service containers."

Example: Using localhost

This example creates two services: nginx and redis. When you specify the Docker host port but not the container port, the container port is randomly assigned to a free port. GitHub sets the assigned container port in the ${{job.services.<service_name>.ports}} context. In this example, you can access the service container ports using the ${{ job.services.nginx.ports['8080'] }} and ${{ job.services.redis.ports['6379'] }} contexts.

services: nginx: image: nginx # Map port 8080 on the Docker host to port 80 on the nginx container ports: - 8080:80 redis: image: redis # Map TCP port 6379 on Docker host to a random free port on the Redis container ports: - 6379/tcp 

jobs.<job_id>.services.<service_id>.image

The Docker image to use as the service container to run the action. The value can be the Docker Hub image name or a registry name.

jobs.<job_id>.services.<service_id>.credentials

Si el registro del contenedor de la imagen requiere autenticación para extraerla, puedes utilizar jobs.<job_id>.container.credentials para configurar un map del username y password. Las credenciales son los mismos valores que proporcionarías al comando de docker login.

Example

services: myservice1: image: ghcr.io/owner/myservice1 credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} myservice2: image: dockerhub_org/myservice2 credentials: username: ${{ secrets.DOCKER_USER }} password: ${{ secrets.DOCKER_PASSWORD }} 

jobs.<job_id>.services.<service_id>.env

Sets a map of environment variables in the service container.

jobs.<job_id>.services.<service_id>.ports

Sets an array of ports to expose on the service container.

jobs.<job_id>.services.<service_id>.volumes

Sets an array of volumes for the service container to use. You can use volumes to share data between services or other steps in a job. You can specify named Docker volumes, anonymous Docker volumes, or bind mounts on the host.

To specify a volume, you specify the source and destination path:

<source>:<destinationPath>.

The <source> is a volume name or an absolute path on the host machine, and <destinationPath> is an absolute path in the container.

Example

volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory 

jobs.<job_id>.services.<service_id>.options

Additional Docker container resource options. For a list of options, see "docker create options."

Filter pattern cheat sheet

You can use special characters in path, branch, and tag filters.

• *: Matches zero or more characters, but does not match the / character. For example, Octo* matches Octocat.
• **: Matches zero or more of any character.
• ?: Matches zero or one of the preceding character.
• +: Matches one or more of the preceding character.
• [] Matches one character listed in the brackets or included in ranges. Ranges can only include a-z, A-Z, and 0-9. For example, the range[0-9a-z] matches any digit or lowercase letter. For example, [CB]at matches Cat or Bat and [1-2]00 matches 100 and 200.
• !: At the start of a pattern makes it negate previous positive patterns. It has no special meaning if not the first character.

The characters *, [, and ! are special characters in YAML. If you start a pattern with *, [, or !, you must enclose the pattern in quotes.

# Valid - '**/README.md' # Invalid - creates a parse error that # prevents your workflow from running. - **/README.md 

For more information about branch, tag, and path filter syntax, see "on.<push>.<branches|tags>", "on.<pull_request>.<branches|tags>", and "on.<push|pull_request>.paths."

Patterns to match branches and tags

Patterns to match file paths

Path patterns must match the whole path, and start from the repository's root.