Acerca de los flujos de trabajo

Acerca de los flujos de trabajo

Un flujo de trabajo es un proceso automatizado configurable que ejecutará uno o más trabajos. 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.

Los flujos de trabajo se definen en el directorio .github/workflows de un repositorio. Un repositorio puede tener varios flujos de trabajo, y cada uno puede realizar un conjunto diferente de tareas, como las siguientes:

• Compilar y probar de solicitudes de incorporación de cambios.
• Implementar la aplicación cada vez que se crea una versión.
• Agregar una etiqueta cada vez que se abre una incidencia nueva.

Conceptos básicos del flujo de trabajo

Un flujo de trabajo debe contener los siguientes componentes básicos:

1. Uno o varios eventos que desencadenarán el flujo de trabajo.
2. Uno o varios trabajos, cada uno de los cuales se ejecutará en una máquina del ejecutor y ejecutará uno o varios pasos.
3. Cada paso puede ejecutar un script que definas, o bien una acción, que es una extensión reutilizable que puede simplificar el flujo de trabajo.

Para obtener más información sobre estos componentes básicos, consulta "Entender las GitHub Actions".

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 se producen fuera de GitHub Enterprise Server y desencadenan un evento repository_dispatch en GitHub Enterprise Server
• 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.

Para más información, consulta "Activar un flujo de trabajo," y para ver la lista completa de eventos, consulta "Eventos que desencadenan flujos de trabajo".

Sintaxis de flujos de trabajo

Los flujos de trabajo se definen mediante YAML. Para obtener la referencia completa de la sintaxis de YAML para crear flujos de trabajo, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".

Para obtener más información sobre cómo administrar ejecuciones de flujo de trabajo (por ejemplo, volver a ejecutar, cancelar o eliminar una ejecución de flujo de trabajo), consulta "Administración de ejecuciones e implementaciones de flujo de trabajo".

Uso de plantillas de flujo de trabajo

GitHub proporciona plantillas de flujo de trabajo preconfigurados que puede usar tal cual o bien personalizar para crear un flujo de trabajo propio. GitHub Enterprise Server analiza el código y muestra plantillas de flujo de trabajo de CI que podrían ser útiles para el repositorio. Por ejemplo, si tu repositorio contiene un código Node.js, verás sugerencias para los proyectos de Node.js.

Estas plantillas de flujo de trabajo están diseñadas para ayudarle a ponerse en marcha rápidamente, y ofrecen una variedad de configuraciones como las siguientes:

• CI: flujos de trabajo de integración continua
• Implementaciones: flujos de trabajo de implementación
• Automatización: flujos de trabajo de Automatización
• Examen de código: flujos de trabajo de examen de código
• Páginas: flujos de trabajo de páginas

Puede utilizar plantillas de flujo de trabajo como punto de partida para crear el flujo de trabajo personalizado, o bien utilizarlas tal cual. Puede examinar la lista completa de plantillas de flujo de trabajo en el repositorio actions/starter-workflows. Para obtener más información, vea «Uso de plantillas de flujo de trabajo».

Características avanzadas de los flujos de trabajo

En esta sección se describen brevemente algunas de las características avanzadas de las GitHub Actions que te ayudan a crear flujos de trabajo más complejos.

Almacenamiento de secretos

Si los flujos de trabajo usan datos confidenciales como contraseñas o certificados, puede guardarlos en GitHub como secretos y luego usarlos en los flujos de trabajo como variables de entorno. Esto significa que podrás crear y compartir flujos de trabajo sin tener que insertar valores confidenciales directamente en el origen de YAML del flujo de trabajo.

Este trabajo de ejemplo muestra cómo hacer referencia a un secreto existente como una variable de entorno y enviarla como parámetro a un comando de ejemplo.

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, vea «Uso de secretos en Acciones de GitHub».

Crear jobs dependientes

Predeterminadamente, los jobs en tu flujo de trabajo se ejecutan todos en paralelo y al mismo tiempo. Si tienes un trabajo que solo se debe ejecutar después de que se complete otro, puedes usar la palabra clave needs para crear esta dependencia. Si se produce un error en uno de los trabajos, se omiten todos los trabajos dependientes; pero si necesitas que los trabajos continúen, puedes definir esto mediante la instrucción condicional if.

En este ejemplo, los trabajos setup, build y test ejecutan en serie, y build y test dependen de la finalización correcta del trabajo que los precede:

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, vea «Utilizar jobs en un flujo de trabajo».

Uso de una matriz

Una estrategia de matriz permite usar variables en una definición de trabajo para crear automáticamente varias ejecuciones de trabajos basadas en las combinaciones de las variables. Por ejemplo, puedes usar una estrategia de matriz para probar el código en varias versiones de un lenguaje o en varios sistemas operativos. La matriz se crea mediante la palabra clave strategy, que recibe las opciones de compilación como una matriz. Por ejemplo, esta matriz ejecutará el trabajo varias veces mediante el uso de versiones diferentes de Node.js:

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

Para obtener más información, vea «Ejecución de variaciones de trabajos en un flujo de trabajo».

Almacenar dependencias en caché

Si los trabajos reutilizan regularmente las dependencias, puedes considerar la posibilidad de almacenar en caché estos archivos para ayudar a mejorar el rendimiento. Una vez que se crea el caché, estará disponible para todos los flujos de trabajo en el mismo repositorio.

Este ejemplo se ilustra cómo almacenar el directorio ~/.npm en 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, vea «Almacenar en caché las dependencias para agilizar los flujos de trabajo».

Usar bases de datos y contenedores de servicio

Si el trabajo necesita una base de datos o un servicio de caché, puede usar la palabra clave services a fin de crear un contenedor efímero para hospedar el servicio; el contenedor resultante estará disponible para todos los pasos de ese trabajo y se quitará cuando se haya completado el trabajo. En este ejemplo se muestra cómo un trabajo puede usar services para crear un contenedor postgres y, después, usar node para conectarse al servicio.

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

Para obtener más información, vea «Utilizar servicios de contenedor».

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. Puede asignar etiquetas a un ejecutor autohospedado además de su etiqueta self-hosted predeterminada. A continuación, puedes hacer referencia a estas etiquetas en el flujo de trabajo de YAML, asegurándote de que el trabajo se enruta 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 la runs-on. El job irá preferencialmente a un ejecutor auto-hospedado inactivo con las etiquetas especificadas.

Para obtener más información sobre las etiquetas autoejecutables, consulta "Uso de etiquetas con ejecutores autohospedados".

Reutilización de flujos de trabajo

Puedes compartir flujos de trabajo con tu organización, privada o públicamente, si llamas 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, vea «Reutilización de flujos de trabajo».

Endurecimiento de seguridad para flujos de trabajo

GitHub proporciona características de seguridad que puede usar para aumentar la seguridad de los flujos de trabajo. Puede usar las características integradas de GitHub para asegurarse de que se le notifican las vulnerabilidades en las acciones que consume o para automatizar el proceso de mantener actualizadas las acciones de los flujos de trabajo. Para obtener más información, vea «Uso de las características de seguridad de GitHub para proteger el uso de Acciones de GitHub».

Utilizar ambientes

Puedes configurar entornos con reglas de protección y secretos para controlar la ejecución de trabajos en un flujo de trabajo. 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, vea «Administrar entornos para la implementación».