Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Sintaxis de flujo de trabajo para acciones de GitHub

Puedes agregar un archivo de flujo de trabajo a tu repositorio para crear procesos automatizados personalizados a fin de automatizar tu ciclo de vida de desarrollo de software.

Acciones de GitHub is available with GitHub gratis, GitHub Pro, Equipo de GitHub, and Nube de GitHub Enterprise. Acciones de GitHub is unavailable for per-repository plans, which are legacy billing plans. For more information, see "GitHub's products."

En este artículo

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 deseas conocer más, consulta "Aprender YAML en cinco minutos".

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

Límites de uso

Exceder los límites de uso puede ocasionar que los trabajos se pongan en cola, no se ejecuten o no se completen. Los límites están sujetos a cambios.

  • You can execute up to 20 workflows concurrently per repository.

  • Puedes ejecutar hasta 1000 solicitudes API en una hora en todas las acciones dentro de un repositorio.

  • Cada trabajo en un flujo de trabajo se puede ejecutar durante un máximo de 6 horas.

  • The number of jobs you can run concurrently across all repositories in your account depends on your GitHub plan.

    GitHub plan Total concurrent jobs Maximum concurrent macOS jobs
    Gratis 20 5
    Pro 40 5
    Equipo 60 5
    Empresa 180 15

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 este campo, GitHub asigna el name (nombre) al nombre de archivo del flujo de trabajo.

on

Obligatorio El nombre del evento GitHub que desencadena 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 con un solo evento

# Activa al subir
on: push

Ejemplo con una lista de eventos

# Activa el flujo de trabajo en la solicitud de inserción o extracción
on: [push, pull_request]

Example using multiple events with activity types or configuration

If you need to specify activity types or configuration for an event, you must configure each event separately. You must append a colon (:) to all events, including events without configuration.

on:
  # Trigger the workflow on push or pull request,
  # but only for the master branch
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  # 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 pull request 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. Si defines solo etiquetas o solo ramas, el flujo de trabajo no se ejecutará para los eventos que afecten la ref de Git no definida.

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

Ejemplo que incluye 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:    
      - master         # Push events on master branch
      - 'mona/octocat' # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**'  # Push events to branches matching refs/heads/releases/10
    # 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 de ignorar 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:
      - 'mona/octocat'      # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**-alpha' # Push events to branches matching refs/heads/releases/beta/3-alpha
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v1.*           # 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 de uso de 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 de ignorar rutas

Cada vez que un nombre de ruta coincida con paths-ignore, no se ejecutará el flujo de trabajo. 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 de incluir 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 de uso de 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

Nota: Si subes más de 1.000 confirmaciones, o si GitHub no genera la diferencia debido a una interrupción (diferencias que son diferencias demasiado grandes), siempre se ejecutará el flujo de trabajo.

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.

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

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. The shortest interval you can run scheduled workflows is once every 5 minutes.

This example triggers the workflow every 15 minutes:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '*/15 * * * *'

For more information about cron syntax, see "Events that trigger workflows."

env

Un mapa de las variables de entorno que están disponibles para todas las tareas y los pasos del flujo de trabajo. También puedes configurar variables de entorno que estén solo disponibles para una tarea o paso. Para obtener más información, consulta jobs.<job_id>.env y jobs.<job_id>.steps.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

jobs

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 trabajo se ejecuta en una nueva instancia del entorno virtual especificado por runs-on.

You can run an unlimited number of jobs as long as you are within the workflow usage limits. Para obtener más información, consulta "Límites de uso".

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 trabajo falla, todos los trabajos que lo necesiten estarán omitidos a menos que los trabajos usen una declaración condicional que haga que el trabajo continúe.

Ejemplo

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

jobs.<job_id>.runs-on

Required The type of machine to run the job on. The machine can be either a GitHub-hosted runner, or a self-hosted runner.

GitHub-hosted runners

If you use a GitHub-hosted runner, each job runs in a fresh instance of a virtual environment specified by runs-on.

Available GitHub-hosted runner types are:

Entorno virtual Etiqueta de flujo de trabajo YAML
Windows Server 2019 windows-latest
Ubuntu 18.04 ubuntu-latest o ubuntu-18.04
Ubuntu 16.04 ubuntu-16.04
macOS Catalina 10.15 macos-latest
Ejemplo
runs-on: ubuntu-latest

For more information, see "Virtual environments for GitHub-hosted runners."

Self-hosted runners

To specify a self-hosted runner for your job, configure runs-on in your workflow file with self-hosted runner labels.

All self-hosted runners have the self-hosted label, and you can select any self-hosted runner by providing only the self-hosted label. Alternatively, you can use self-hosted in an array with additional labels, such as labels for a specific operating system or system architecture, to select only the runner types you specify.

Ejemplo
runs-on: [self-hosted, linux]

For more information, see "About self-hosted runners" and "Using self-hosted runners in a workflow."

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 env y jobs.<job_id>.steps.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

Ejemplo

jobs:
  job1:
    env:
      FIRST_NAME: Mona

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.

Las expresiones en un condicional if (si) no requieren la sintaxis {{ }}. Para obtener más información, consulta "Contextos y sintaxis de expresión para Acciones de GitHub".

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 virtual 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 "Límites de uso".

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 y sintaxis de expresión para Acciones de GitHub".

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.

Las expresiones en un condicional if (si) no requieren la sintaxis {{ }}. Para obtener más información, consulta "Contextos y sintaxis de expresión para Acciones de GitHub".

Ejemplos usando contextos

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

steps:
 - name: My first step
   if: github.event_name == 'pull_request' && github.event.action == 'unassigned'
   run: echo Este evento es una solicitud de extracción en la que se ha eliminado un asignatario.
Ejemplo usando 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. For more information, see "Contexts and expression syntax for Acciones de GitHub."

steps:
  - name: My first step
    # Usa una acción (`my-action`) en tu repositorio
    uses: ./.github/actions/my-action
  - name: My backup step
    if: failure()
    uses: actions/heroku@master

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.
  • Usar la rama principal de una acción puede ser conveniente, pero si alguien lanza una nueva versión principal con un cambio importante, tu flujo de trabajo podría romperse.

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 utilizando es un contenedor Docker, debes ejecutar el trabajo en un entorno virtual de Linux. Para obtener más detalles, consulta runs-on y "Entornos virtuales para Acciones de GitHub."

Ejemplo usando acciones versionadas
steps:    
  - uses: actions/setup-node@74bc508 # Referencia a una confirmación específica
  - uses: actions/setup-node@v1      # Referencia a la versión principal de una versión
  - uses: actions/setup-node@v1.2    # Referencia a una versión menor de un lanzamiento
  - uses: actions/setup-node@master  # Referencia a una rama
Ejemplo usando una acción pública

{owner}/{repo}@{ref}

Puedes usar ramas, ref o SHA específicos en un repositorio público GitHub.

jobs:
  my_first_job:
    steps:
      - name: My first step
      # Utiliza la rama principal de un repositorio público
        uses: actions/heroku@master
      # Utiliza una etiqueta de versión específica de un repositorio público
      - name: My second step
        uses: actions/aws@v2.0.1
Ejemplo usando 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@master
Ejemplo usando la 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.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: ./.github/actions/my-action
Ejemplo usando una acción 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 usando una acción de registro público de Docker

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

Una imagen de Docker en un registro público.

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

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 virtual. Puedes proporcionar comandos de varias líneas, y 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 de shell predeterminados en el sistema operativo del entorno virtual usando la palabra clave shell. Puedes usar palabras clave incorporadas de shell keywords, o puedes definir un conjunto personalizado de opciones de shell.

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 powershell Este es el shell predeterminado que se usa en Windows. El Desktop PowerShell. GitHub agrega la extensión .ps1 al nombre de tu script. powershell -command "& '{0}'".
Ejemplo de ejecución de un script mediante bash
pasos:
  - name: Display the path
    run: echo $PATH
    shell: bash
Ejemplo de ejecución de un script mediante cmd de Windows
steps:
  - name: Display the path
    run: echo %PATH%
    shell: cmd
Ejemplo de ejecución de un script mediante PowerShell Core
steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: pwsh
Ejemplo de ejecución de 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}.

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 -e o 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 ejecutador 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' al contenido 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 secuencia de comandos.
    • cmd.exe saldrá con el nivel de error del último programa que ejecutó, y devolverá el código de error al ejecutador. 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@master
        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 argsen 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: monacorp/action-name@master
    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: monacorp/action-name@master
    with:
      entrypoint: /a/different/executable

La palabra clave punto de entrada se usa con acciones del contenedor Docker, pero también puedes usarla con acciones JavaScript que no definen las entradas.

jobs.<job_id>.steps.env

Establece las variables de entorno de los pasos para usarlos en el entorno virtual. 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.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

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 "Entornos virtuales para Acciones de GitHub" y "Contextos y sintaxis de expresión para Acciones de GitHub."

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

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

jobs.<job_id>.strategy

Una estrategia crea una matriz de construcción para tus trabajos. Puedes definir diferentes variaciones de un entorno para ejecutar cada trabajo.

jobs.<job_id>.strategy.matrix

Una matriz de construcción es un conjunto de diferentes configuraciones del entorno virtual. Por ejemplo, podrías ejecutar un trabajo en más de una versión compatible de idioma, sistema operativo o herramienta. Cada configuración es una copia del trabajo que se ejecuta e informa un estado.

Puedes especificar una matriz proporcionando una variedad de opciones de configuración. Por ejemplo, si el entorno virtual de GitHub admite las versiones 6, 8 y 10 de Node.js, puedes especificar un conjunto de esas versiones en la matriz.

When you define a matrix of operating systems, you must set the required runs-on keyword to the operating system of the current job, rather than hard-coding the operating system name. To access the operating system name, you can use the matrix.os context parameter to set runs-on. Para obtener más información, consulta "Contextos y sintaxis de expresión para Acciones de GitHub".

You can run an unlimited number of jobs as long as you are within the workflow usage limits. Para obtener más información, consulta "Límites de uso".

Ejemplo

Este ejemplo crea una matriz de tres trabajos, estableciendo una variable de nodo a un valor diferente para cada uno y usando esa variable como entrada para la acción setup-node action. Como resultado, cada trabajo usará una versión de nodo diferente.

strategy:
  matrix:
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

También puedes ejecutar esos trabajos en dos versiones de Linux diferentes, mediante una variable de matriz como entrada para el especificador runs-on, a fin de crear un total de 6 trabajos (3 versiones de nodo x 2 versiones de Linux).

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

Para encontrar opciones de configuración compatibles para un entorno virtual de GitHub, consulta "Entornos virtuales para Acciones de GitHub".

Ejemplos que incluyen configuraciones en una matriz de construcción

Puedes agregar más opciones de configuración a un trabajo de una matriz de construcción ya existente. No puedes usar include para agregar nuevos trabajos a una matriz de construcción. For example, if you want to use a specific version of npm when the job that uses windows-latest and version 4 of node runs, you can use include to specify that additional option.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    node: [4, 6, 8, 10]
    include:
      # includes a new variable of npm with a value of 2 for the matrix leg matching the os and version
      - os: windows-latest
        node: 4
        npm: 2
Ejemplos que excluyen 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: [4, 6, 8, 10]
    exclude:
      # excludes node 4 on macOS
      - os: macos-latest
        node: 4

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: verdadero

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>.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:10.16-jessie
      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:10.16-jessie

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 de docker público.

jobs.<job_id>.container.env

Establece una matriz 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 "opciones de creación de docker."

jobs.<job_id>.services

Contenedores adicionales para servicios de alojamiento para un trabajo en un flujo de trabajo. Estos son útiles para crear bases de datos o servicios de caché como redis. El ejecutor en la máquina virtual creará automáticamente una red y administrará el ciclo de vida de los contenedores de servicio.

Cuando usas un contenedor de servicio para una tarea, o tu paso usa acciones del contenedor, no necesitas establecer información de puerto para acceder al servicio. Docker expone automáticamente todos los puertos entre los contenedores de la misma red.

Cuando la tarea y la acción se ejecutan en un contenedor, puedes referenciar directamente el contenedor con su nombre del host. El nombre del host se asigna automáticamente al nombre del servicio.

Cuando un paso no usa una acción de contenedor, tienes que acceder al servicio usando un host local y vincular los puertos.

Ejemplo de uso de host local

Este ejemplo crea dos servicios para nginx y redis. GitHub selecciona un puerto abierto en el host virtual para vincular el puerto predeterminado de redis. GitHub establece el puerto host enlazado en el ${{ job.services.<service_name>.ports[<port>] }} contexto de trabajo. Por ejemplo, el puerto redis se establecerá en la variable de entorno ${{ job.services.redis.ports['6379'] }}.

services:
  nginx:
    image: nginx
    ports:
      - 8080:80
    env:
      NGINX_PORT: 80
  redis:
    image: redis
    ports:
      - 6379/tcp

jobs.<job_id>.services.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 base de Docker o un Docker Hub o registro público.

jobs.<job_id>.services.env

Establece una matriz de variables de entorno en el contenedor de servicios.

jobs.<job_id>.services.ports

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

jobs.<job_id>.services.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.options

Opciones adicionales de recursos del contenedor Docker. Para obtener una lista de opciones, consulta "opciones de creación de docker."

Hoja de referencia de patrones de filtro

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

  • *: Encuentra cero o más caracteres, pero no Encuentra el caracter /. For example, Octo* matches Octocat.
  • **: Matches zero or more of any character.
  • ?: Matches zero or one single character. For example, Octoc?t matches Octocat.
  • +: Matches one or more of the proceeding 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-f] matches any digits 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. 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.

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

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
característica/* El comodín * encuentra cualquier caracter, pero no encuentra la barra (/). -feature/my-branch
-feature/your-branch
característica/** 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
-master
-releases/mona-the-octcat
Encuentra el nombre exacto de una rama o el nombre de etiqueta. -master
-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. -master
-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
'*característica' 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]+ Encuentra todas las etiquetas de versión semántica con las versiones principales 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

Pregunta a una persona

¿No puedes encontrar lo que estás buscando?

Contáctanos