Skip to main content
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.

Acerca de los flujos de trabajo

Get a high level overview GitHub Actions workflows, including triggers, syntax, and advanced features.

Acerca de los flujos de trabajo

Un flujo de trabajo es un proceso automatizado configurable que ejecutará uno o más jobs. Los flujos de trabajo se definen mediante un archivo de YAML que se verifica en tu repositorio y se ejecutará cuando lo active un evento dentro de este o puede activarse manualmente o en una programación definida.

Workflows are defined in the .github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. Por ejemplo, puedes tener un flujo de trabajo para crear y probar las solicitudes de cambio, otro para desplegar tu aplicación cada que se cree un lanzamiento y todavía otro más que agregue una etiqueta cada que alguien abra una propuesta nueva.

Workflow basics

A workflow must contain the following basic components:

  1. One or more events that will trigger the workflow.
  2. One or more jobs, each of which will execute on a runner machine and run a series of one or more steps.
  3. Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

For more information on these basic components, see "Understanding GitHub Actions."

Resumen del flujo de trabajo

Activar un flujo de trabajo

Los activadores de los flujos de trabajo son eventos que ocasionan que se ejecute un flujo de trabajo. Estos eventos pueden ser:

  • Eventos que ocurren en el repositorio de tu flujo de trabajo
  • Eventos que ocurren fuera de GitHub y activan un evento de repository_dispatch en GitHub
  • Tiempos programados
  • Manual

Por ejemplo, puedes configurar tu flujo de trabajo para que se ejecute cuando se realiza una subida a la rama predeterminada de tu repositorio, cuando se crea un lanzamiento o cuando se abre una propuesta.

For more information, see "Triggering a workflow", and for a full list of events, see "Events that trigger workflows."

Sintaxis de flujos de trabajo

Workflow are defined using YAML. For the full reference of the YAML syntax for authoring workflows, see "Workflow syntax for GitHub Actions."

Crear un flujo de trabajo de ejemplo

Las GitHub Actions utilizan la sintaxis de YAML para definir el flujo de trabajo. Each workflow is stored as a separate YAML file in your code repository, in a directory named .github/workflows.

Puedes crear un flujo de trabajo de ejemplo en tu repositorio que active automáticamente una serie de comandos cada que se suba código. In this workflow, GitHub Actions checks out the pushed code, installs the bats testing framework, and runs a basic command to output the bats version: bats -v.

  1. En tu repositorio, crea el directorio .github/workflows/ para almacenar tus archivos de flujo de trabajo.

  2. En el directorio .github/workflows/, crea un archivo nuevo que se llame learn-github-actions.yml y agrega el siguiente código.

    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - uses: actions/setup-node@v3
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
    
  3. Confirma estos cambios y cárgalos a tu repositorio de GitHub.

Tu archivo de flujo de trabajo de GitHub Actions nuevo estará ahora instalado en tu repositorio y se ejecutará automáticamente cada que alguien suba un cambio a éste. To see the details about a workflow's execution history, see "Viewing the activity for a workflow run."

Entender el archivo de flujo de trabajo

Para ayudarte a entender cómo se utiliza la sintaxis de YAML para crear un flujo de trabajo, esta sección explica cada línea del ejemplo de la introducción:

name: learn-github-actions
Opcional - El nombre del flujo de trabajo ta como aparece en la pestaña de Acciones del repositorio de GitHub.
on: [push]
Especifica el activador de este flujo de trabajo. Este ejemplo utiliza el evento push, así que una ejecución de flujo de trabajo se activa cada que alguien sube un cambio al repositorio o fusiona una solicitud de cambios. Esto se activa mediante una subida a cada rama; para encontrar ejemplos de la sintaxis que solo se ejecuta en subidas a ramas específicas, rutas o etiquetas, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".
jobs:
Agrupa los jobs que se ejecutan en el flujo de trabajo learn-github-actions.
check-bats-version:
Define un job que se llame check-bats-version. Las llaves hijas definirán las propiedades del job.
  runs-on: ubuntu-latest
Configura el job para que se ejecute en la versión más reciente de un ejecutor Ubuntu Linux. Esto significa que el job se ejecutará en una máquina virtual nueva que se hospede en GitHub. For syntax examples using other runners, see "Workflow syntax for GitHub Actions."
  steps:
Agrupa todos los pasos que se ejecutan en el job check-bats-version. Cada elemento anidado debajo de esta sección es una acción o script de shell por separado.
    - uses: actions/checkout@v3
The uses keyword specifies that this step will run v3 of the actions/checkout action. Esta es una acción que comprueba tu repositorio en el ejecutor, lo cual te permite ejecutar scripts u otras acciones contra tu código (tales como herramientas de compilación y prueba). Debes utilizar la acción de verificación en cualquier momento en el que tu flujo de trabajo se ejecute contra el código del repositorio.
    - uses: actions/setup-node@v3
      with:
        node-version: '14'
This step uses the actions/setup-node@v3 action to install the specified version of the Node.js (this example uses v14). Esto pone a los comandos node y npm en tu PATH.
    - run: npm install -g bats
La palabra clave run le dice al job que ejecute un comando en el ejecutor. Ene ste caso, estás utilizando npm para instalar el paquete de pruebas del software bats.
    - run: bats -v
Finalmente, ejecutarás el comando bats con un parámetro que producirá la versión del software.

Visualizar el archivo de flujo de trabajo

En este diagrama, puedes ver el archivo de flujo de trabajo que acabas de crear, así como la forma en que los componentes de GitHub Actions se organizan en una jerarquía. Cada paso ejecuta una acción o script de shell simples. Los pasos 1 y 2 ejecutan acciones, mientras que los pasos 3 y 4 ejecutan scripts de shell. Para encontrar más acciones preconstruidas para tus flujos de trabajo, consulta la sección "Encontrar y personalizar acciones".

Resumen del flujo de trabajo

Viewing the activity for a workflow run

When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run's progress and view each step's activity on GitHub.

  1. En GitHub.com, visita la página principal del repositorio.

  2. Debajo del nombre de tu repositorio, da clic en Acciones.

    Navegar al repositorio

  3. En la barra lateral izquierda, da clic en el flujo de trabajo que quieres ver.

    Impresión de pantalla de los resultados del flujo de trabajo

  4. Debajo de "Ejecuciones de flujo de trabajo", da clic en el nombre de la ejecución que quieres ver.

    Impresión de pantalla de las ejecuciones del flujo de trabajo

  5. Debajo de Jobs o en la gráfica de visualización, da clic en el job que quieras ver.

    Seleccionar job

  6. View the results of each step.

    Impresión de pantalla de los detalles de la ejecución del flujo de trabajo

For more on managing workflow runs, such as re-running, cancelling, or deleting a workflow run, see "Managing workflow runs."

Utilizar flujos de trabajo iniciales

GitHub Proporciona un flujo de trabajo preconfigurado que puedes personalizar para crear tu propio flujo de trabajo de integración contínua. GitHub analiza tu código y te muestra el flujo de trabajo inicial de IC que podría ser útil para tu repositorio. Por ejemplo, si tu repositorio contiene un código Node.js, verás sugerencias para los proyectos de Node.js. Puedes utilizar el flujo de trabajo inicial como un lugar para comenzar a crear tu flujo de trabajo personalizado o utilizarlo tal cual.

Puedes buscar la lista completa de flujos de trabajo iniciales en el repositorio actions/starter-workflows.

For more information on using and creating starter workflows, see "Using starter workflows" and "Creating starter workflows for your organization."

Características avanzadas de los flujos de trabajo

This section briefly describes some of the advanced features of GitHub Actions that help you create more complex workflows.

Almacenar secretos

Si tus flujos de trabajo utilizan datos sensibles tales como contraseñas o certificados, puedes guardarlos en GitHub como secretos y luego usarlos en tus flujos de trabajo como variables de ambiente. This means that you will be able to create and share workflows without having to embed sensitive values directly in the workflow's YAML source.

This example job demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

Para obtener más información, consulta la sección "Secretos cifrados".

Crear jobs dependientes

Predeterminadamente, los jobs en tu flujo de trabajo se ejecutan todos en paralelo y al mismo tiempo. If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement.

En este ejemplo, los jobs de setup, build, y test se ejecutan en serie, y build y test son dependientes de que el job que las precede se complete con éxito:

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

Para obtener más información, consulta la sección "Definir los jobs de prerrequisito".

Utilizar una matriz

A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based the combinations of the variables. For example, you can use a matrix strategy to test your code in multiple versions of a language or on multiple operating systems. The matrix is created using the strategy keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of Node.js:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [12, 14, 16]
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}

Para obtener más información, consulta la sección "Utilizar una matriz para tus jobs".

Almacenar dependencias en caché

If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Una vez que se crea el caché, estará disponible para todos los flujos de trabajo en el mismo repositorio.

Este ejemplo ilustra cómo almacenar el directorio ~/.npm en el caché:

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v3
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

Para obtener más información, consulta la sección "Almacenar las dependencias en caché para agilizar los flujos de trabajo".

Usar bases de datos y contenedores de servicio

Si tu job requiere de un servicio de caché o de base de datos, puedes utilizar la palabra clave services para crear un contenedor efímero para almacenar el servicio; el contenedor resultante estará entonces disponible para todos los pasos de ese job y se eliminará cuando el job se haya completado. Este ejemplo ilustra como un job puede utilizar services para crear un contenedor de postgres y luego utilizar a node para conectarse al servicio.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

For more information, see "Using containerized services."

Utilizar etiquetas para enrutar los flujos de trabajo

Si quieres asegurarte de que un tipo específico de ejecutor procesará tu job, puedes utilizar etiquetas para controlar donde se ejecutan los jobs. Puedes asignar etiquetas a un ejecutor auto-hospedado adicionalmente a su etiqueta predeterminada de self-hosted. Entonces, puedes referirte a estas etiquetas en tu flujo de trabajo de YAML, garantizando que el job se enrute de forma predecible.Los ejecutores hospedados en GitHub tienen asignadas etiquetas predefinidas.

Este ejemplo muestra como un flujo de trabajo puede utilizar etiquetas para especificar el ejecutor requerido:

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

Un flujo de trabajo solo se ejecutará en un ejecutor que tenga todas las etiquetas en el arreglo runs-on. El job irá preferencialmente a un ejecutor auto-hospedado inactivo con las etiquetas especificadas. If none are available and a GitHub-hosted runner with the specified labels exists, the job will go to a GitHub-hosted runner.

To learn more about self-hosted runner labels, see "Using labels with self-hosted runners."

To learn more about GitHub-hosted runner labels, see "Supported runners and hardware resources."

Reutilizar flujos de trabajo

Puedes llamar a un flujo de trabajo desde dentro de otro. Esto te permite reutilizar flujos de trabajo, evitando la duplicación y haciendo que tus flujos se puedan mantener mejor. Para obtener más información, consulta la sección "Reutilizar flujos de trabajo".

Utilizar ambientes

You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Cad job en un flujo de trabajo puede referenciar un solo ambiente. Cualquier regla de protección que se configure para el ambiente debe pasar antes de que un job que referencia al ambiente se envíe a un ejecutor. Para obtener más información, consulta la sección "Utilizar ambientes para despliegue".