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.

Configurar un flujo de trabajo

Puedes crear, ver o editar flujos de trabajo para un repositorio si tienes permisos de escritura o administración para el repositorio. Puedes personalizar tu configuración de flujo de trabajo según el tipo de acciones que incluyes en tu flujo de trabajo.

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 los flujos de trabajo

Los flujos de trabajo son procesos automatizados personalizados que puedes configurar en tu repositorio para crear, probar, empaquetar, lanzar o implementar cualquier proyecto en GitHub. Con los flujos de trabajo, puedes automatizar el ciclo de vida de tu desarrollo de software con una amplia gama de herramientas y servicios. Para obtener más información, consulta "Acerca de Acciones de GitHub".

Puedes crear más de un flujo de trabajo en un repositorio. Debes almacenar los flujos de trabajo en el directorio .github/workflows en la raíz de su repositorio.

Los flujos de trabajo deben tener al menos un trabajo, y los trabajos deben contener un conjunto de pasos que ejecuten tareas individuales. Los pasos pueden ejecutar comandos o utilizar una acción. Puedes crear tus propias acciones o usar acciones compartidas por la comunidad GitHub y personalizarlas según sea necesario.

Puedes configurar un flujo de trabajo para que comience cuando se produce un evento GitHub, en un horario o desde un evento externo.

Debes configurar los flujos de trabajo mediante la sintaxis YAML y guardarlos como archivos de flujo de trabajo en tus repositorios. Una vez que hayas creado con éxito un archivo de flujo de trabajo YAML y activado el flujo de trabajo, verás los registros de construcción, los resultados de las pruebas, los artefactos y los estados de cada paso de tu flujo de trabajo. Para obtener más información, consulta "Administrar una ejecución de flujo de trabajo".

Imagen de ejecución de flujo de trabajo anotado

También puedes recibir notificaciones de actualizaciones de estado del flujo de trabajo. Para obtener más información sobre las opciones de notificación, consulta "Elegir el método de envío para tus notificaciones".

Los límites de uso se aplican a los flujos de trabajo individuales. Para obtener más información, consulta "Límites de uso para flujos de trabajo".

Crear un archivo de flujo de trabajo

En un nivel alto, estos son los pasos para agregar un archivo de flujo de trabajo. Puedes encontrar ejemplos de configuración específicos en las secciones a continuación.

  1. En la raíz de tu repositorio, crea un directorio denominado .github/workflows para almacenar tus archivos de flujo de trabajo.

  2. En .github/workflows, agrega un archivo .yml o .yaml a tu flujo de trabajo. Por ejemplo, .github/workflows/continuous-integration-workflow.yml.

  3. Utiliza la documentación de referencia "Sintaxis de flujo de trabajo para Acciones de GitHub" para elegir eventos a fin de desencadenar una acción, agregar acciones y personalizar tu flujo de trabajo.

  4. Confirma tus cambios en el archivo de flujo de trabajo en la rama donde deseas que se ejecute tu flujo de trabajo.

Ejemplo de archivo de flujo de trabajo

nombre: Greet Everyone
# Este flujo de trabajo se desencadena en los envíos al repositorio.
on: [push]

jobs:
  build:
    # El nombre del archivo es Greeting
    name: Greeting
    # Este archivo se ejecuta en Linux
    runs-on: ubuntu-latest
    steps:
      # Este paso usa hello-world-javascript-action de GitHub: https://github.com/actions/hello-world-javascript-action
      - name: Hello world
        uses: actions/hello-world-javascript-action@v1
        with:
          who-to-greet: 'Mona the Octocat'
        id: hello
      # Este paso imprime un resultado (tiempo) desde la acción del paso anterior.
      - name: Echo the greeting's time
        run: echo 'The time was ${{ steps.hello.outputs.time }}.'

Activar un flujo de trabajo con eventos

Puedes configurar un flujo de trabajo para comenzar una vez:

  • Se produce un evento en GitHub, como cuando alguien envía una confirmación a un repositorio o cuando se crea una propuesta o una solicitud de extracción
  • Comienza un evento programado.
  • Se produce un evento externo.

Para activar un flujo de trabajo después de que ocurra un evento en GitHub, agrega on: y un valor de evento después del nombre del flujo de trabajo. Por ejemplo, este flujo de trabajo se activa cuando los cambios se envían a cualquier rama en el repositorio.

name: descriptive-workflow-name
on: push

Para programar un flujo de trabajo, puedes usar la sintaxis cron POSIX en tu archivo de flujo de trabajo. The shortest interval you can run scheduled workflows is once every 5 minutes. Por ejemplo, este flujo de trabajo se activa cada hora.

on:
  schedule:
    - cron:  '0 * * * *'

Para activar un flujo de trabajo después de que se produce un evento externo, puedes invocar un evento de webhook repository_dispatch llamando al punto final API REST "Create a repository dispatch event" (Crear un evento de despacho de repositorio). Para obtener más información, consulta "Crear un evento de despacho de repositorio" en la documentación del programador de GitHub.

Para obtener más información y ejemplos, consulta "Eventos que desencadenan flujos de trabajo".

Filtrar por ramas, etiquetas y rutas específicas

Puedes configurar tu flujo de trabajo para que se ejecute solo en ciertas ramas.

Por ejemplo, este flujo de trabajo se ejecuta cuando una subida que incluye archivos en el directorio test se realiza en la rama master o sube a la etiqueta v1.

on:
  push:
    branches:
      - master
    tags:
      - v1
    # file paths to consider in the event. Opcional; por defecto a todos.
    paths:
      - 'test/*'

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

Choosing a runner

You can run workflows on GitHub-hosted runners or self-hosted runners. Jobs can run directly on the machine or in a Docker container.

You can specify the runner for each job in a workflow using runs-on. For more information about runs-on, see "Workflow syntax for Acciones de GitHub."

Using a GitHub-hosted runner

Puedes seleccionar entre diferentes tipos y versiones de máquinas host virtuales, incluidos Linux, Windows y macOS. Each job in a workflow executes in a fresh instance of the virtual environment, and steps within a job can share information using the filesystem. For more information, see "Virtual environments for Acciones de GitHub-hosted runners."

For example, you can use ubuntu-latest to specify the latest version of an Ubuntu GitHub-hosted runner.

runs-on: ubuntu-latest

Using a self-hosted runner

If you've added self-hosted runners to your repository, you can specify a self-hosted runner using labels. All self-hosted runners get the self-hosted label and each self-hosted runner has labels for its operating system and system architecture. For more information, see "Using self-hosted runners in a workflow."

For example, if you added a self-hosted runner with a Linux operating system and ARM32 architecture, you can select that runner using the self-hosted, linux, and ARM32 labels.

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

Configurar una matriz de construcción

Para probar en múltiples sistemas operativos, plataformas y versiones de idiomas al mismo tiempo, puedes configurar una matriz de construcción.

Una matriz de construcción proporciona diferentes configuraciones para que el entorno virtual las pruebe. Por ejemplo, un flujo de trabajo puede ejecutar un trabajo para más de una versión compatible de idioma, sistema operativo o herramienta. Para cada configuración, se ejecuta una copia del trabajo y se informa un estado.

Puedes especificar una matriz de construcción en tu archivo de flujo de trabajo con una matriz que enumere las opciones de configuración en estrategia:. Por ejemplo, esta matriz de construcción ejecutará un trabajo con diferentes versiones de Node.js y Ubuntu, un sistema operativo Linux.

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

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]

Para obtener más información, consulta Sintaxis de flujo de trabajo para Acciones de GitHub.

Usar la acción de control

Existen varias acciones estándar que puedes utilizar en tu flujo de trabajo. La acción de control es una acción estándar que debes incluir en tu flujo de trabajo antes que otras acciones cuando:

  • Tu flujo de trabajo requiere una copia del código de tu repositorio, como cuando estás construyendo y probando tu repositorio, o usando una integración continua.
  • Hay al menos una acción en tu flujo de trabajo que se define en el mismo repositorio. Para obtener más información, consulta "Hacer referencia a acciones en tu flujo de trabajo".

Para usar la acción de control estándar sin más especificaciones, incluye este paso:

- uses: actions/checkout@v1

Si usas v1 en este ejemplo te aseguras de estar usando una versión estable de la acción de control.

Para clonar superficialmente tu repositorio, o copiar solo la versión más reciente de tu repositorio, establece fetch-depth con la sintaxis with:

- uses: actions/checkout@v1
  with:
    fetch-depth: 1

Para obtener más información, consulta la acción de control.

Elegir el tipo de acciones para tu flujo de trabajo

Existen diferentes tipos de acciones que puedes usar en tu flujo de trabajo para satisfacer las necesidades de tu proyecto:

  • Acciones del contenedor Docker
  • Acciones de JavaScript

Para obtener más información, consulta "Acerca de acciones."

Cuando elijas el tipo de acciones para utilizar en tu flujo de trabajo, te recomendamos que explores las acciones existentes en los repositorios públicos o en Docker Hub y puedas personalizar estas acciones para tu proyecto.

Puedes explorar y usar acciones creadas por GitHub en la organización de github.com/actions. Para visitar Docker Hub, consulta "Docker Hub" en el sitio de Docker.

Hacer referencia a acciones en tu flujo de trabajo

Para hacer referencia a acciones en tu archivo de flujo de trabajo con la sintaxis correcta, debes tener en cuentas dónde se define la acción.

Los flujos de trabajo pueden usar acciones definidas en:

  • Un repositorio público
  • El mismo repositorio donde tu archivo de flujo de trabajo hace referencia a las acciones
  • Una imagen del contenedor Docker publicada en Docker Hub

Para usar una acción definida en un repositorio privado, tanto el archivo de flujo de trabajo como la acción deben estar en el mismo repositorio. Tu flujo de trabajo no puede utilizar acciones definidas en otros repositorios privados, incluso si el otro repositorio privado está en la misma organización.

Para mantener estable tu flujo de trabajo, incluso cuando se actualiza una acción, puedes hacer referencia a la versión de la acción que estás utilizando y especificar un número de etiqueta de Git ref o Docker en tu archivo de flujo de trabajo. Para ver ejemplos, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".

Para obtener opciones de configuración más detalladas, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".

Hacer referencia a una acción desde un repositorio público

Si una acción se define en un repositorio público, debes hacer referencia a la acción utilizando la sintaxis {owner}/{repo}@{ref} o {owner}/{repo}/{path}@{ref}.

jobs:
  my_first_job:
    name: My Job Name
      steps:
        - uses: actions/setup-node@v1
          with:
            node-version: 10.x

Para ver un ejemplo de flujo de trabajo completo, consulta el repositorio de plantillas del nodo de configuración.

Hacer referencia a una acción en el mismo repositorio en el que un archivo de flujo de trabajo usa la acción

Si se define una acción en el mismo repositorio en el que tu archivo de flujo de trabajo usa la acción, puedes hacer referencia a la acción con ‌{owner}/{repo}@{ref} o la sintaxis ./path/to/dir en tu archivo de flujo de trabajo.

Ejemplo de estructura de archivo de repositorio:

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

Ejemplo de archivo de flujo de trabajo:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Este paso revisa una copia de tu repositorio.
      - uses: actions/checkout@v1
    # Este paso hace referencia al directorio que contiene la acción.
      - uses: ./.github/actions/hello-world-action

Hacer referencia a un contenedor en Docker Hub

Si se define una acción en una imagen de contenedor Docker publicada en Docker Hub, debes hacer referencia a la acción con la sintaxis docker://{image}:{tag} en tu archivo de flujo de trabajo. Para proteger tu código y tus datos, te recomendamos que verifiques la integridad de la imagen del contenedor Docker de Docker Hub antes de usarla en tu flujo de trabajo.

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

Para ver algunos ejemplos de acciones de Docker, consulta el flujo de trabajo Docker-image.yml y "Crear una acción de contenedor Docker".

Para obtener más información, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".

Agregar una credencial de estado de flujo de trabajo a tu repositorio

Status badges show whether a workflow is currently failing or passing. A common place to add a status badge is in the README.md file of your repository, but you can add it to any web page you'd like. By default, badges display the status of your default branch (usually master). You can also display the status of a workflow run for a specific branch or event using the branch and event query parameters in the URL.

Si el flujo de trabajo usa la palabra clave name, puedes hacer referencia al flujo de trabajo por nombre. Si el nombre de tu flujo de trabajo contiene un espacio en blanco, deberás reemplazar el espacio con la cadena que codifica la URL %20. Para obtener más información sobre la palabra clave name (nombre), consulta "Sintaxis de flujo de trabajo para Acciones de GitHub".

https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg

Si tu flujo de trabajo no tiene un nombre, puedes hacer referencia al archivo del flujo de trabajo mediante la ruta de archivo relacionada con el directorio de la raíz del repositorio.

https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_FILE_PATH>/badge.svg

Ejemplo de cómo usar un nombre de flujo de trabajo

Este ejemplo de Markdown agrega una credencial de estado para un flujo de trabajo con el nombre "Greet Everyone". El PROPIETARIO del repositorio es la organización actions y el nombre del REPOSITORIO es hello-world.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg)

Ejemplo de cómo usar una ruta de archivo de flujo de trabajo

Este ejemplo de Markdown agrega una credencial de estado para un flujo de trabajo con la ruta de archivo .github/workflows/main.yml. El PROPIETARIO del repositorio es la organización actions y el nombre del REPOSITORIO es hello-world.

![](https://github.com/actions/hello-world/workflows/.github/workflows/main.yml/badge.svg)

Ejemplo con el parámetro rama

Este ejemplo de Markdown añade una insignia de estado para una rama con el nombre feature-1.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?branch=feature-1)

Ejemplo con el parámetro event

Este ejemplo de Markdown agrega una insignia que muestra el estado de las ejecuciones de flujo de trabajo activadas por el evento pull_request.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?event=pull_request)

Leer más

Pregunta a una persona

¿No puedes encontrar lo que estás buscando?

Contáctanos