Sintaxis de flujo de trabajo para acciones de GitHub

Acerca de la sintaxis de YAML para flujos de trabajo

Los archivos de flujo de trabajo usan la sintaxis YAML y deben tener una extensión de archivo .yml o .yaml. Si eres nuevo en YAML y quieres aprender más, consulta la guía "Aprende YAML en Y minutos".

Debes almacenar los archivos de flujos de trabajo en el directorio .github/workflows en tu repositorio.

name (nombre)

El nombre de tu flujo de trabajo. GitHub muestra los nombres de tus flujos de trabajo en la página de acciones de tu repositorio. Si omites nombre, GitHub lo establece en la ruta del archivo de flujo de trabajo en relación con la raíz del repositorio.

on

Requerido. El nombre del evento de GitHub que activa el flujo de trabajo. Puedes proporcionar una única cadena de eventos, matriz de eventos, matriz de tipos de eventos o mapa de configuración de eventos que programe un flujo de trabajo o restrinja la ejecución de un flujo de trabajo para archivos, etiquetas o cambios de rama específicos. Para obtener una lista de eventos disponibles, consulta "Eventos que desencadenan flujos de trabajo".

Ejemplo: utilizando un solo evento

# Triggered when code is pushed to any branch in a repository
on: push

Ejemplo: Utilizando una lista de eventos

# Triggers the workflow on push or pull request events
on: [push, pull_request]

Ejemplo: Utilizando eventos múltiples con tipos de actividad o configuración

Si necesitas especificar tipos de actividad o configuración para un evento, debes configurar cada evento por separado. Debes agregar dos puntos (:) a todos los eventos, incluyendo aquellos sin configuración.

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

on.<event_name>.types

Selecciona los tipos de actividad que desencadenarán una ejecución de flujo de trabajo. La mayoría de los eventos GitHub son desencadenados por más de un tipo de actividad. Por ejemplo, el evento para el recurso release (lanzamiento) se activa cuando se publica, se cancela la publicación, se crea, edita, elimina o lanza previamente una publicación. 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".

# Trigger the workflow on release activity
on:
  release:
    # Only use the types keyword to narrow down the activity types that will trigger your workflow.
    types: [published, created, edited]

on.<push|pull_request>.<branches|tags>

Cuando uses los eventos push y pull_request debes configurar un flujo de trabajo para ejecutarlo en ramas o etiquetas específicas. Para un evento pull_request, solo se evalúan las ramas y las etiquetas en la base. Si defines solo etiquetas o solo ramas, el flujo de trabajo no se ejecutará para los eventos que afecten a la ref de Git indefinida.

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, al definir el patrón mona/octocat en branches, se encontrará la ref de Git refs/heads/mona/octocat. El patrón releases/** encontrará la ref de Git refs/heads/releases/10.

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      # Push events on main branch
      - main
      # Push events to branches matching refs/heads/mona/octocat
      - 'mona/octocat'
      # Push events to branches matching refs/heads/releases/10
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:        
      - v1             # Push events to v1 tag
      - v1.*           # Push events to v1.0, v1.1, and v1.9 tags

Ejemplo: Ignorando ramas y etiquetas

Cada vez que un patrón coincida con el patrón branches-ignore o tags-ignore, no se ejecutará el flujo de trabajo. Los patrones definidos en branches-ignore y tags-ignore se evalúan con el nombre de ref de Git. Por ejemplo, al definir el patrón mona/octocat en branches, se encontrará la ref de Git refs/heads/mona/octocat. El patrón releases/**-alpha en branches encontrará la ref de Git refs/releases/beta/3-alpha.

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      # Do not push events to branches matching refs/heads/mona/octocat
      - 'mona/octocat'
      # Do not push events to branches matching refs/heads/releases/beta/3-alpha
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v1.*           # Do not push events to tags v1.0, v1.1, and v1.9

Excluir ramas y etiquetas

Puedes usar dos tipos de filtros para evitar que un flujo de trabajo se ejecute en las subidas y las solicitudes de extracción a las etiquetas y las ramas.

• branches o branches-ignore: no puedes usar ambos filtros branches y branches-ignore para el mismo evento de un flujo de trabajo. Usa el filtro branches cuando debas filtrar ramas de coincidencias positivas y para excluir ramas. Usa el filtro branches-ignore cuando solo debas excluir nombres de ramas.
• tags o tags-ignore: no puedes usar ambos filtros tags y tags-ignore para el mismo evento de un flujo de trabajo. Usa el filtro tags cuando debas filtrar etiquetas de coincidencias positivas y para excluir etiquetas. Usa el filtro tags-ignore cuando solo debas excluir nombres de etiquetas.

Ejemplo: utilizando patrones positivos y negativos

Puedes excluir etiquetas y ramas usando el caracter !. 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>.paths

Cuando uses los eventos push y pull_request, puedes configurar que se ejecute un flujo de trabajo cuando al menos un archivo no coincida con paths-ignore o al menos uno de los archivos modificados coincida con las rutas configuradas. Los filtros de ruta no se evalúan para las subidas a etiquetas.

Las palabras clave paths-ignore y paths aceptan los patrones globales que usan los caracteres comodines * y ** para encontrar más de un nombre de ruta. Para obtener más información, consulta "Hoja de referencia de patrones de filtro".

Ejemplo: Ignorando rutas

Cuando todos los nombres de ruta coincidan con los patrones en paths-ignore, el flujo de trabajo no se ejecutará. GitHub evalúa los patrones definidos en paths-ignore para compararlos con el nombre de ruta. 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/**'

Ejemplo: Incluyendo rutas

Si al menos una ruta coincide con un patrón del filtro de rutas, se ejecuta el flujo de trabajo. Para desencadenar una compilación cada vez que subes un archivo JavaScript, puedes usar un patrón comodín.

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

Excluir rutas

Puedes excluir rutas usando dos tipos de filtros. No puedes usar ambos filtros para el mismo evento de un flujo de trabajo.

• paths-ignore: usa el filtro paths-ignore cuando solo debas excluir nombres de ruta.
• paths: usa el filtro paths cuando debas filtrar rutas de coincidencias positivas y excluir rutas.

Ejemplo: utilizando patrones positivos y negativos

Puedes excluir rutas usando el caracter !. 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.workflow_dispatch.inputs

Cuando se utiliza el evento workflow_dispatch, puedes especificar opcionalmente entradas que se pasan al flujo de trabajo. Las entradas de envío de flujo de trabajo se especifican en el mismo formato que las entradas de acción. Para obtener más información sobre el formato, consulta la sección "Sintaxis de metadatos para las GitHub Actions".

on: 
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'
        required: false

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.schedule

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 ejecutar flujos de trabajo programados es una vez 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 * * *'

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

env

Un map de las variables de ambiente que se encuentran disponibles para los pasos de todos los jobs en el flujo de trabajo. También puedes configurar variables de ambiente que solo estén disponibles para los pasos en un solo job o en un solo paso. Para obtener más información, consulta jobs.<job_id>.env y 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.

Ejemplo

env:
  SERVER: production

defaults

Un map de configuración predeterminada que se aplicará a todos los jobs en el flujo de trabajo. 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 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

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

Trabajos

Una ejecución de flujo de trabajo está compuesta por uno o más trabajos. De forma predeterminada, los trabajos se ejecutan en paralelo. 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 la sección "Facturación y límites de uso" para los ejecutores hospedados en GitHub y la sección "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 trabajo que se ejecuta en una ejecución de flujo de trabajo, puedes usar el API GitHub. Para obtener más información, consulta la sección "Jobs de los Flujos de Trabajo".

jobs.<job_id>

Cada trabajo debe tener una identificación para vincularla con el trabajo. 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 _.

Ejemplo

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

jobs.<job_id>.name

El nombre del trabajo que se muestra en GitHub.

jobs.<job_id>.needs

Identifica los trabajos que se deben completar con éxito antes de que se ejecute este trabajo. 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.

Ejeemplo: Requerir que los jobs dependientes tengan éxito

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 que job1 y job2 se completen.

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

1. job1
2. job2
3. job3

Ejemplo: No requerir que los jobs dependientes tengan éxito

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>.runs-on

Requerido. El tipo de máquina en la cual se ejecutará el job. La máquina puede ser un ejecutor alojado GitHub o un ejecutor autoalojado.

Ejecutores alojados GitHub

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:

Entorno virtual	Etiqueta de flujo de trabajo YAML	Notas
Windows Server 2022[beta]	windows-2022	La etiqueta de windows-latest actualmente utiliza la imagen de ejecutor de Windows Server 2019.
Windows Server 2019	windows-latest o windows-2019
Windows Server 2016	windows-2016
Ubuntu 20.04	ubuntu-latest o ubuntu-20.04
Ubuntu 18.04	ubuntu-18.04
macOS Big Sur 11	macos-11	La etiqueta de macos-latest actualmente utiliza la imagen de ejecutor de macOS 10.15.
macOS Catalina 10.15	macos-latest or macos-10.15

Ejemplo

runs-on: ubuntu-latest

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

Ejecutores autoalojados

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, proporciona un arreglo de etiquetas que comience con self-hosted (este se debe listar primero) y que luego incluya etiquetas adicionales conforme lo requieras.

Ejemplo

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

Un map de salidas para un 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".

Ejemplo

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

Un mapa de las variables de entorno que están disponibles para todos los pasos de la tarea. También puedes establecer las variables de entorno para todo el flujo de trabajo o para un paso en particular. Para obtener más información, consulta la sección env y 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.

Ejemplo

jobs:
  job1:
    env:
      FIRST_NAME: Mona

jobs.<job_id>.defaults

Un map de configuración predeterminada que se aplicará a todos los pasos del 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

Proporciona shell y working-directory predeterminados a todos los pasos de run en el 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.

Ejemplo

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

jobs.<job_id>.if

Puedes usar el condicional if para impedir que se ejecute una tarea si no se cumple una condición. 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".

jobs.<job_id>.steps

Un trabajo contiene una secuencia de tareas llamadas pasos. Los pasos pueden ejecutar comandos, tareas de configuración o una acción en tu repositorio, un repositorio público o una acción publicada en un registro de Docker. Not all steps run actions, but all actions run as a step. Cada paso se ejecuta en su propio proceso en el entorno del ejecutor y tiene acceso al espacio de trabajo y al sistema de archivos. Debido a que los pasos se ejecutan en su propio proceso, los cambios en las variables de entorno no se conservan entre los pasos. GitHub proporciona pasos integrados para configurar y completar un trabajo.

Puedes ejecutar un número de pasos ilimitado siempre que estés dentro de los límites de uso del flujo de trabajo. Para obtener más información, consulta la sección "Facturación y límites de uso" para los ejecutores hospedados en GitHub y la sección "Acerca de los ejecutores auto-hospedados" para los límites de uso de los ejecutores auto-hospedados.

Ejemplo

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

Un identificador único para el paso. Puede usar el id para hacer referencia al paso en contextos. Para obtener más información, consulta "Contextos".

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

Puedes usar el condiciona if para impedir que se ejecute un paso si no se cumple una condición. 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".

Ejemplo: Utilizando contextos

Este paso solo se ejecuta cuando el tipo de evento es una pull_request y la acción del evento está unassigned (sin asignar).

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.

Ejemplo: Utilizando funciones de verificación de estado

El paso mi copia de seguridad solo se ejecuta cuando se produce un error en el paso anterior de un trabajo. Para obtener más información, consulta la sección "Expresiones".

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

Un nombre para que tu paso se muestre en GitHub.

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

Selecciona una acción para ejecutar como parte de un paso en tu trabajo. Una acción es una unidad de código reutilizable. Puedes usar una acción definida en el mismo repositorio que el flujo de trabajo, un repositorio público o en una imagen del contenedor Docker publicada.

Te recomendamos encarecidamente que incluyas la versión de la acción que estás utilizando y especifiques un número de etiqueta de Git ref, SHA o Docker. Si no especificas una versión, podrías interrumpir tus flujos de trabajo o provocar un comportamiento inesperado cuando el propietario de la acción publique una actualización.

• El uso del SHA de confirmación de una versión de acción lanzada es lo más seguro para la estabilidad y la seguridad.
• Usar la versión de acción principal específica te permite recibir correcciones críticas y parches de seguridad y al mismo tiempo mantener la compatibilidad. También asegura que tu flujo de trabajo aún debería funcionar.
• Puede ser conveniente utilizar la rama predeterminada de una acciòn, pero si alguien lanza una versiòn principal nueva con un cambio importante, tu flujo de trabajo podrìa fallar.

Algunas acciones requieren entradas que se deben establecer usando la palabra clave with (con). Revisa el archivo README de la acción para determinar las entradas requeridas.

Las acciones son archivos JavaScript o contenedores Docker. Si la acción que estás usando es un contenedor Docker, debes ejecutar el trabajo en un entorno Linux. Para obtener más detalles, consulta runs-on.

Ejemplo: Utilizando acciones versionadas

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

Ejemplo: Utilizando una acción pública

{owner}/{repo}@{ref}

Puedes especificar una rema, ref, o SHA en un repositorio público de GitHub.

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

Ejemplo: Utilizando una acción pública en un subdirectorio

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

Un subdirectorio en un repositorio público de GitHub en una rama específica, ref o SHA.

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

Ejemplo: Utilizando una acción en el mismo repositorio que el flujo de trabajo

./path/to/dir

La ruta al directorio que contiene la acción en el repositorio de tu flujo de trabajo. Debes revisar tu repositorio antes de usar la acción.

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

Ejemplo: Utilizando una acción de Docker Hub

docker://{image}:{tag}

Una imagen de Docker publicada en Docker Hub.

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

Ejemplo: Utilizando una acción del registro público de Docker

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

Una imagen de Docker en un registro público. Este ejemplo utiliza el Registro del Contenedor de Google en gcr.io.

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

Ejemplo: Utilizando una acción dentro de un repositorio privado diferente al del flujo de trabajo

Tu flujo de trabajo debe registrar el repositorio privado y referenciar la acción de forma local. Genera un token de acceso personal y agrega el token como un secreto cifrado. Para obtener más información, consulta las secciones "Crear un token de acceso personal" y "Secretos cifrados".

Reemplaza a PERSONAL_ACCESS_TOKEN en el ejemplo con el nombre de tu secreto.

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

Ejecuta programas de la línea de comandos usando el shell del sistema operativo. Si no proporcionas un nombre, el paso de establecimiento de nombre se completará por defecto con el texto especificado en el comando run.

Por defecto, los comandos se ejecutan utilizando shells sin inicio de sesión. Puedes elegir un shell diferente y personalizar el shell utilizado para ejecutar los comandos. Para obtener más información, consulta "Usar un shell específico".

Cada palabra clave run representa un nuevo proceso y shell en el entorno del ejecutor. Cuando proporcionas comandos de varias líneas, cada línea se ejecuta en el mismo shell. Por ejemplo:

• Comando de una sola línea:

  - name: Install Dependencies
    run: npm install
  

• Comando de varias líneas:

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

Usando la palabra clave working-directory, puedes especificar el directorio de trabajo de dónde ejecutar el comando.

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

Uso de un shell específico

Puedes anular los parámetros predeterminados del shell en el sistema operativo del ejecutor utilizando la palabra clave shell. Puedes usar palabras clave incorporadas de shell keywords, o puedes definir un conjunto personalizado de opciones de shell. El comando de shell que se ejecuta internamente ejecuta un archivo temporal que contiene los comandos que se especifican en la palabra clave run.

Plataforma compatible	parámetro shell	Descripción	Comando ejecutado interamente
Todas	bash	El shell predeterminado en plataformas que no son de Windows con una reserva para sh. Al especificar un bash shell en Windows, se usa el bash shell incluido con Git para Windows.	bash --noprofile --norc -eo pipefail {0}
Todas	pwsh	Powershell Core. GitHub agrega la extensión .ps1 al nombre de tu script.	pwsh -command ". '{0}'"
Todas	python	Ejecuta el comando python.	python {0}
Linux / macOS	sh	El comportamiento de reserva para plataformas que no son Windows si no se proporciona un shell y bash no se encuentra en la ruta.	sh -e {0}
Windows	cmd	GitHub agrega la extensión .cmd a tu nombre de script y la sustituye por {0}.	%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"".
Windows	pwsh	Este es el shell predeterminado que se usa en Windows. Powershell Core. GitHub agrega la extensión .ps1 al nombre de tu script. Si tu ejecutor auto-hospedado de Windows no tiene instalado PowerShell Core, entonces se utilizará PowerShell Desktop en su lugar.	pwsh -command ". '{0}'".
Windows	powershell	El PowerShell Desktop. GitHub agrega la extensión .ps1 al nombre de tu script.	powershell -command ". '{0}'".

Ejemplo: Ejecutando un script utilizando bash

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

Ejemplo: Ejecutando un script utilizando el cmd de Windows

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

Ejemplo: Ejecutando un script utilizando PowerShell Core

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

Ejemplo: Utilizar PowerShell Desktop para ejecutar un script

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

Ejemplo: Ejecutando un script de python

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

Shell personalizado

Puede establecer el valor shell en una cadena de plantilla utilizando el comando command […options] {0} [..more_options]. GitHub interpreta la primera palabra delimitada por espacios en blanco de la cadena como el comando, e inserta el nombre del archivo para el script temporal en {0}.

Por ejemplo:

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

El comando que se utiliza, (en este ejemplo, perl) debe instalarse en el ejecutor.

Para obtener más información sobre el software que se incluye en los ejecutores hospedados en GitHub, consulta la sección "Especificaciones para los ejecutores hospedados en GitHub".

Códigos de salida y preferencia de acción de error

Para palabras clave shell incorporadas, brindamos los siguientes valores predeterminados accionados por los ejecutadores alojados por GitHub. Deberías usar estos lineamientos al ejecutar scripts shell.

• bash/sh:

  • Comportamiento a prueba de fallos utilizando set -eo pipefail: Valor predeterminado para bash y shell incorporado. También es el valor predeterminado cuando no proporcionas una opción en plataformas que no son de Windows.
  • Puedes excluir la función de falla rápida y tomar el control total al proporcionar una cadena de plantilla a las opciones del shell. Por ejemplo, bash {0}.
  • Los shells tipo sh salen con el código de salida del último comando ejecutado en un script, que también es el comportamiento predeterminado para las acciones. El ejecutor informará el estado del paso como fallido o exitoso según este código de salida.

• powershell/pwsh

  • Comportamiento de falla rápida cuando sea posible. Para el shell incorporado pwsh y powershell, vamos a anteponer $ErrorActionPreference = 'stop' a los contenidos del script.
  • Añadimos if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE } a los scripts de powershell para que los estados de acción reflejen el último código de salida del script.
  • Los usuarios siempre pueden optar por no usar el shell incorporado y proporcionar una opción de shell personalizada como: pwsh -File {0}, o powershell -Command "& '{0}'", según la necesidad.

• cmd

  • No parece haber una manera de optar por completo por un comportamiento de falla rápida que no sea escribir tu script para verificar cada código de error y responder en consecuencia. Debido a que en realidad no podemos proporcionar ese comportamiento por defecto, debes escribir este comportamiento en tu script.
  • cmd.exe saldrá con el nivel de error del último programa que ejecutó y devolverá el código de error al ejecutor. Este comportamiento es internamente coherente con el comportamiento predeterminado anterior sh y pwsh y es el valor predeterminado cmd.exe, por lo que este comportamiento permanece intacto.

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

Un mapa de los parámetros de entrada definidos por la acción. Cada parámetro de entrada es un par clave/valor. Los parámetros de entrada se establecen como variables del entorno. La variable tiene el prefijo INPUT_ y se convierte en mayúsculas.

Ejemplo

Define los tres parámetros de entrada (first_name, middle_name, and last_name) definidos por la acción hello_world. Es posible acceder a estas variables de entrada con la acción hello-world como INPUT_FIRST_NAME, INPUT_MIDDLE_NAME y las variables de entorno INPUT_LAST_NAME.

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

Una cadena que define las entradas para un contenedor Docker. GitHub comunica los args en el ENTRYPOINT del contenedor cuando se inicia el contenedor. Una matriz de cadenas no es compatible para este parámetro.

Ejemplo

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.

Los args se usan en el lugar de la instrucción CMD en un Dockerfile. Si usas CMD en tu Dockerfile, usa los lineamientos ordenados por preferencia:

1. Los documentos requerían argumentos en el README de las acciones y las omiten desde la instrucción CMD.
2. Usa los valores predeterminados que permiten usar la acción sin especificar ningún args.
3. Si la acción expone un indicador --help o algo similar, usa ese como el valor predeterminado para que la acción se documente automáticamente.

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

Anula el Docker ENTRYPOINT en el Dockerfile o lo establece si es que no tiene uno especificado. A diferencia de la instrucción Docker ENTRYPOINT que tiene un shell y formulario de ejecución, la palabra clave entrypoint acepta solo una cadena que define el ejecutable que se ejecutará.

Ejemplo

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

Se pretende que la palabra clave entrypoint se utilice con acciones de contenedor de Docker, pero también puedes utilizarla con acciones de JavaScript que no definan ninguna entrada.

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

Establece variables de entorno para los pasos a utilizar en el entorno del ejecutor. También puedes establecer las variables de entorno para todo el flujo de trabajo o para una tarea. Para obtener más información, consulta env y 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.

Es posible que las acciones públicas especifiquen las variables de entorno esperadas en el archivo README. Si estás estableciendo un secreto en una variable de entorno, debes establecer secretos usando el contexto secretos. Para obtener más información, consulta las secciones "Utilizar variables de ambiente" y "Contextos".

Ejemplo

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

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

Impide que un trabajo falle cuando falla un paso. Se lo debe establecer en true para permitir que un trabajo pase cuando falla este paso.

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

El número máximo de minutos para ejecutar el paso antes de terminar el proceso.

jobs.<job_id>.timeout-minutes

La cantidad máxima de minutos para permitir que un trabajo se ejecute antes que GitHub lo cancele automáticamente. Predeterminado: 360

Si el tiempo de espera excede el límite de tiempo de ejecución del job para el ejecutor, dicho job se cancelará cuando se llegue al límite de tiempo de ejecución. Para obtener más información sobre los límites de tiempo de ejecución de los jobs, consulta la sección "Límites de uso, facturación y administración".

jobs.<job_id>.strategy

Una estrategia crea una matriz de construcción para tus trabajos. Puedes definir variaciones diferentes para que ejecuten cada job.

jobs.<job_id>.strategy.matrix

Puedes definir una matriz de diferentes configuraciones de trabajo. 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".

Ejemplo: Incluyendo valores adicionales en combinaciones

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

Cuando se establece en verdadero, GitHub cancela todos los trabajos en curso si falla cualquier trabajo de matriz. Predeterminado: true

jobs.<job_id>.strategy.max-parallel

La cantidad máxima de trabajos que se pueden ejecutar de manera simultánea cuando se utiliza una estrategia de trabajo matrix. 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

Previene que una ejecución de flujo de trabajo falle cuando un job falle. Configúralo como true para permitir que la ejecución del flujo de trabajo pase cuando este job falle.

Ejemplo: Previniendo un job de matriz específico que falle desde una ejecución de flujo de trabajo que también falle

Puedes permitir que ciertos jobs en una matriz de jobs fallen sin que la ejecución de flujo de trabajo falle. Por ejemplo, si querías permitir que fallara únicamente un job experimental con el node configurado en 15 sin que fallara la ejecución del flujo de trabajo.

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

Un contenedor para ejecutar todos los pasos de un trabajo que aún no especifica un contenedor. 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.

Ejemplo

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

La imagen de Docker para usar como el contenedor para ejecutar la acción. El valor puede ser el nombre de la imagen de Docker Hub o un nombre de registro público .

jobs.<job_id>.container.env

Establece una mapa de variables de entorno en el contenedor.

jobs.<job_id>.container.ports

Establece una matriz de puertos para exponer en el contenedor.

jobs.<job_id>.container.volumes

Establece una matriz de volúmenes para que el contenedor los 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.

Ejemplo

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

jobs.<job_id>.container.options

Opciones adicionales de recursos del contenedor Docker. Para obtener una lista de opciones, consulta las opciones "docker create".

jobs.<job_id>.services

Se usa para hospedar contenedores de servicio para un trabajo en un flujo de trabajo. Los contenedores de servicio son útiles para crear bases de datos o servicios de caché como Redis. El ejecutor crea automáticamente una red Docker y administra el ciclo de vida de los contenedores de servicio.

Si configuras tu trabajo para que se ejecute en un contenedor, o si tu paso usa acciones del contenedor, no necesitas asignar puertos para acceder al servicio o a la acción. Docker expone automáticamente todos los puertos entre contenedores en la misma red de puente definida por el usuario de Docker. Puedes hacer referencia directamente al contenedor de servicio por su nombre de host. El nombre del host se correlaciona automáticamente con el nombre de la etiqueta que configuraste para el servicio en el flujo de trabajo.

Si configuras el trabajo para que se ejecute directamente en la máquina del ejecutor y tu paso no usa una acción de contenedor, debes asignar cualquier puerto del contenedor de servicio Docker que sea necesario para el host Docker (la máquina del ejecutor). Puedes acceder al contenedor de servicio utilizando host local y el puerto asignado.

Para obtener más información acerca de las diferencias entre los contenedores de servicios de red, consulta "Acerca de los contenedores de servicio".

Ejemplo: Utilizando al host local

Este ejemplo crea dos servicios: nginx y Redis. Cuando especificas el puerto del host de Docker pero no el puerto del contenedor, el puerto del contenedor se asigna aleatoriamente a un puerto gratuito. GitHub establece el puerto del contenedor asignado en el contexto $ {{job.services.<service_name>.ports}}. En este ejemplo, puedes acceder a los puertos del contenedor de servicio utilizando los contextos ${{ job.services.nginx.ports['8080'] }} y ${{ job.services.redis.ports['6379'] }}.

services:
  nginx:
    image: nginx
    # Asignar puerto 8080 en el host de Docker al puerto 80 en el contenedor nginx
    ports:
      - 8080:80
  redis:
    image: redis
    # Asignar puerto TCP 6379 en el host de Docker a un puerto gratuito aleatorio en el contenedor Redis
    ports:
      - 6379/tcp

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

La imagen de Docker para usar como el contenedor de servicios para ejecutar la acción. El valor puede ser el nombre de la imagen de Docker Hub o un nombre de registro público .

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

Establece un mapa de variables de entorno en el contenedor de servicio.

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

Establece una matriz de puertos para exponer en el contenedor de servicios.

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

Establece una matriz de volúmenes para que el contenedor de servicios los 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.

Ejemplo

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

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

Opciones adicionales de recursos del contenedor Docker. Para obtener una lista de opciones, consulta las opciones "docker create".

Hoja de referencia de patrones de filtro

Puedes usar caracteres especiales en los filtros de ruta, de rama y de etiqueta.

• *: Coincide con cero o más caracteres, pero no coincide con el caracter /. Por ejemplo, Octo* coincide con Octocat.
• **: Coincide con cero o más de cualquier caracter.
• ?: Empata con cero o con uno de los caracteres antesesores.
• +: Empata con uno o más de los caracteres precedentes.
• [] Coincide con un caracter que aparece en los corchetes o que se incluye en los rangos. Los rangos solo pueden incluir a-z, A-Z y 0-9. Por ejemplo, el rango[0-9a-z] empata con cualquier dígito o letra en minúscula. Por ejemplo, [CB]at coincide con Cat o Bat y [1-2]00 coincide con 100 y 200.
• !: Al comienzo de un patrón hace que niegue los patrones positivos previos. No tiene ningún significado especial si no es el primer caracter.

Los caracteres *, [ y ! son caracteres especiales en YAML. Si comienzas un patrón con *, [ o !, tienes que encerrar el patrón entre comillas.

# Valid
- '**/README.md'

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

Para obtener más información acerca de la sintaxis de filtro de ramas, de etiquetas y de rutas, consulta "on.<push|pull_request>.<branches|tags>" y "on.<push|pull_request>.paths."

Patrones para encontrar ramas y etiquetas

Patrón	Descripción	Ejemplo de coincidencias
feature/*	El comodín * encuentra cualquier caracter, pero no encuentra la barra (/).	feature/my-branch feature/your-branch
feature/**	El comodín ** encuentra cualquier caracter, incluida la barra (/) en los nombres de ramas y etiquetas.	feature/beta-a/my-branch feature/your-branch feature/mona/the/octocat
main releases/mona-the-octocat	Encuentra el nombre exacto de una rama o el nombre de etiqueta.	main releases/mona-the-octocat
'*'	Encuentra todos los nombres de rama o de etiqueta que no contienen barra (/). El caracter * es un caracter especial en YAML. Cuando comiences un patrón con *, debes usar comillas.	main releases
'**'	Encuentra todos los nombres de rama y de etiqueta. Este es el comportamiento predeterminado cuando no usas un filtro de ramas o etiquetas.	all/the/branches every/tag
'*feature'	El caracter * es un caracter especial en YAML. Cuando comiences un patrón con *, debes usar comillas.	mona-feature feature ver-10-feature
v2*	Encuentra los nombres de rama y de etiqueta que comienzan con v2.	v2 v2.0 v2.9
v[12].[0-9]+.[0-9]+	Coincide con todas las etiquetas y ramas de versionamiento semántico con una versión principal 1 o 2	v1.10.1 v2.0.0

Patrones para encontrar rutas de archivos

Los patrones de ruta deben coincidir con toda la ruta y comenzar desde la raíz del repositorio.

Patrón	Descripción de coincidencias	Ejemplo de coincidencias
'*'	El comodín * encuentra cualquier caracter, pero no encuentra la barra (/). El caracter * es un caracter especial en YAML. Cuando comiences un patrón con *, debes usar comillas.	README.md server.rb
'*.jsx?'	El caracter ? encuentra cero o uno de los caracteres de procedimiento.	page.js page.jsx
'**'	El comodín * encuentra cualquier caracter, incluida la barra (/). Este es el comportamiento predeterminado cuando no usas un filtro de rutas.	all/the/files.md
'*.js'	El comodín * encuentra cualquier caracter, pero no encuentra la barra (/). Encuentra todos los archivos .js en la raíz del repositorio.	app.js index.js
'**.js'	Encuentra todos los archivos .js en el repositorio.	index.js js/index.js src/js/app.js
docs/*	Todos los archivos dentro de la raíz del directorio docs en la raíz del repositorio.	docs/README.md docs/file.txt
docs/**	Todos los archivos en el directorio docs en la raíz del repositorio.	docs/README.md docs/mona/octocat.txt
docs/**/*.md	Un archivo con un sufijo .md en cualquier parte del directorio docs.	docs/README.md docs/mona/hello-world.md docs/a/markdown/file.md
'**/docs/**'	Cualquier archivo en un directorio docs en cualquier parte del repositorio.	docs/hello.md dir/docs/my-file.txt space/docs/plan/space.doc
'**/README.md'	Un archivo README.md en cualquier parte del repositorio.	README.md js/README.md
'**/*src/**'	Cualquier archivo en una carpeta con un sufijo src en cualquier parte del repositorio.	a/src/app.js my-src/code/js/app.js
'**/*-post.md'	Un archivo con el sufijo -post.md en cualquier parte del repositorio.	my-post.md path/their-post.md
'**/migrate-*.sql'	Un archivo con el prefijo migrate- y el sufijo .sql en cualquier parte del repositorio.	migrate-10909.sql db/migrate-v1.0.sql db/sept/migrate-v1.sql
*.md !README.md	Usar un signo de exclamación (!) frente a un patrón lo niega. Cuando un archivo coincida con un patrón y también coincida con un patrón negativo definido más adelante en el archivo, no se incluirá el archivo.	hello.md Does not match README.md docs/hello.md
*.md !README.md README*	Los patrones se marcan de forma secuencial. Un patrón que niega un patrón previo volverá a incluir las rutas del archivo.	hello.md README.md README.doc