Dependencias de Trabajos (Jobs) en GitHub Actions

Introducción

En los flujos de trabajo (workflows) de CI/CD del mundo real, rara vez son solo una lista única de pasos. A menudo se componen de múltiples "trabajos" (jobs) distintos que deben ejecutarse en un orden específico.

Por ejemplo, podrías tener un trabajo de Build (Compilación) que compila tu código y un trabajo de Deploy (Despliegue) que lo envía a un servidor. Definitivamente no querrás que el trabajo de Deploy se ejecute si el trabajo de Build falla, y no puedes ejecutarlos al mismo tiempo porque el despliegue necesita los artefactos compilados.

En este laboratorio, dividirás tu flujo de trabajo en dos trabajos separados y utilizarás la palabra clave needs para imponer una dependencia, asegurando que el trabajo de despliegue espere a que el trabajo de compilación se complete con éxito.

Este laboratorio se basa en el repositorio que creaste en los laboratorios anteriores. Trabajarás con el repositorio github-actions-demo.

Definir un trabajo de compilación (build job)

Primero, limpiaremos nuestro flujo de trabajo (workflow) existente para tener un trabajo de build enfocado. Simplificaremos la estrategia de matriz (matrix strategy) del laboratorio anterior para mayor claridad, volviendo a una única versión para mantener el foco en las dependencias de los trabajos.

1. En la página de tu repositorio de GitHub para github-actions-demo, haz clic en el botón verde Code.
2. Asegúrate de que la pestaña HTTPS esté seleccionada y copia la URL. Debería verse como https://github.com/your-username/github-actions-demo.git.
3. Abre la terminal en el entorno LabEx. La ruta predeterminada es ~/project.
4. Usa el comando git clone para descargar el repositorio. Reemplaza your-username con tu nombre de usuario real de GitHub.

cd ~/project
git clone https://github.com/your-username/github-actions-demo.git

Salida de Ejemplo:

Cloning into 'github-actions-demo'...
remote: Enumerating objects: X, done.
remote: Counting objects: 100% (X/X), done.
remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (X/X), done.

5. Navega al repositorio clonado:

cd ~/project/github-actions-demo

6. Crea un nuevo archivo de flujo de trabajo .github/workflows/job-dependencies.yml usando el editor WebIDE. Puedes encontrar el archivo en el explorador de archivos a la izquierda bajo project/github-actions-demo/.github/workflows/.

7. Comienza creando la estructura básica del flujo de trabajo. Agrega el nombre del flujo de trabajo y el disparador (trigger):

name: Job Dependencies

on: [push]

8. Agrega la sección de trabajos (jobs) y define el trabajo de compilación (build) con su ejecutor (runner):

jobs:
  build:
    runs-on: ubuntu-latest

9. Agrega la sección de pasos (steps). Primero, agrega el paso de checkout para obtener el código del repositorio:

steps:
  - uses: actions/checkout@v4

10. Agrega el paso de configuración de Node.js:

- name: Use Node.js
  uses: actions/setup-node@v4
  with:
    node-version: "20"

11. Agrega el paso para instalar dependencias:

- name: Install dependencies
  run: npm install

12. Agrega el paso para ejecutar pruebas:

- name: Run tests
  run: npm test

13. Agrega el paso de compilación que crea el directorio y el archivo de artefacto (artifact):

- name: Build project
  run: |
    mkdir dist
    echo "Build artifact created at $(date)" > dist/build.txt

14. Finalmente, agrega el paso de carga de artefacto (Upload artifact). Este paso es crucial porque guarda la salida de la compilación para que el siguiente trabajo pueda usarla:

- name: Upload build artifact
  uses: actions/upload-artifact@v4
  with:
    name: dist-files
    path: dist

Tu archivo completo debería verse ahora así:

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

Explicación

• Eliminamos la estrategia matrix por simplicidad.
• Mantuvimos el paso Upload build artifact. ¡Esto es crucial porque el siguiente trabajo necesitará estos archivos!

Guarda el archivo (Ctrl+S o Cmd+S) después de realizar los cambios.

Definir un trabajo de despliegue (deploy job) que depende de la compilación

Ahora añadiremos un segundo trabajo llamado deploy. Este trabajo solo debe ejecutarse si build tiene éxito. Lo logramos usando needs: build.

1. Añade el siguiente trabajo deploy a tu archivo .github/workflows/job-dependencies.yml. Asegúrate de que esté al mismo nivel de sangría que build.

2. Comienza añadiendo la definición del trabajo de despliegue con su runner y dependencia:

deploy:
  runs-on: ubuntu-latest
  needs: build

La línea needs: build es crucial: le indica a GitHub Actions que este trabajo depende de la finalización exitosa del trabajo build.

3. Añade la sección de pasos (steps). Primero, añade el paso para descargar el artefacto (artifact):

steps:
  - name: Download artifact
    uses: actions/download-artifact@v4
    with:
      name: dist-files
      path: dist

Esto descarga el artefacto que se subió en el trabajo build. El name debe coincidir con el nombre utilizado en el paso de subida (upload step).

4. Añade el paso de despliegue (deploy step):

- name: Deploy project
  run: |
    echo "Deploying project..."
    ls -R dist
    echo "Deployment successful!"

Este paso simula un despliegue listando los archivos descargados.

2. La estructura completa de tu archivo debería verse así:

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v4
        with:
          name: dist-files
          path: dist
      - name: Deploy project
        run: |
          echo "Deploying project..."
          ls -R dist
          echo "Deployment successful!"

Explicación

• needs: build: Esta es la línea clave. Indica a GitHub Actions que este trabajo depende de la finalización exitosa del trabajo build.
• uses: actions/download-artifact@v4: Dado que los trabajos se ejecutan en diferentes máquinas virtuales (virtual machines), no comparten sistemas de archivos. Para obtener la carpeta dist creada en el trabajo build, debemos descargar el artefacto que subimos anteriormente.
• name: dist-files: Debe coincidir con el nombre utilizado en el paso de subida (upload step).

Guarda el archivo (Ctrl+S o Cmd+S).

Confirmar (Commit), subir (Push) y verificar la ejecución secuencial

Ahora vamos a verificar que los trabajos (jobs) se ejecutan en el orden correcto.

1. Asegúrate de estar en el directorio del repositorio:

cd ~/project/github-actions-demo

2. Prepara los cambios (Stage the changes):

git add .

3. Confirma los cambios (Commit the changes):

git commit -m "Add deploy job with dependency on build"

4. Envía los cambios al repositorio remoto en GitHub:

git push

Nota sobre la Autenticación: Cuando ejecutes git push, el WebIDE te pedirá automáticamente que te autentiques. Sigue estos pasos detallados:

1. Aparecerá una ventana emergente con el mensaje: "The extension 'GitHub' wants to sign in using GitHub." Haz clic en Allow.
2. Aparecerá una nueva notificación. Haz clic en "Copy&Continue to GitHub", y luego haz clic en "Open" en el siguiente aviso.
3. Inicia sesión en tu cuenta de GitHub en la ventana del navegador que se abre e introduce el código de autorización que se copió. Después de confirmar la autorización, la página se cerrará automáticamente.
4. Espera unos segundos y verás que la terminal completa la operación de push con éxito.

Nota de Privacidad: El WebIDE solicitará acceso completo a tu cuenta de GitHub con fines de autenticación. No tienes que preocuparte por problemas de privacidad: la VM de LabEx se destruirá inmediatamente después de completar el laboratorio actual, y tus credenciales e información de autorización no se conservarán.

Este proceso de autenticación no requiere la configuración manual de nombre de usuario o Personal Access Token.

Verificar en GitHub

1. Visita tu repositorio en GitHub en un navegador web.
2. Haz clic en la pestaña Actions.
3. Haz clic en la ejecución de flujo de trabajo (workflow run) más reciente.
4. Observa el gráfico de visualización. Deberías ver dos círculos (jobs) conectados por una línea.
   • El trabajo build estará a la izquierda.
   • El trabajo deploy estará a la derecha.
5. Observa el progreso. Notarás que deploy permanece en estado "Pending" o "Waiting" hasta que build se ponga verde (Success).
6. Una vez que build finalice, deploy comenzará.
7. Haz clic en los registros (logs) del trabajo deploy para ver el mensaje "Deploying project..." y la lista de archivos del artefacto descargado.

Resumen

En este laboratorio, aprendiste a orquestar flujos de trabajo (workflows) de múltiples trabajos (jobs) en GitHub Actions. Tú:

1. Creaste trabajos separados de build y deploy.
2. Usaste la palabra clave needs para definir una dependencia, asegurando que deploy se ejecute solo después de build.
3. Usaste upload-artifact y download-artifact para pasar datos (archivos) entre estos trabajos separados.

Este patrón es fundamental para construir pipelines de CI/CD robustos donde deseas compilar una vez y luego desplegar en múltiples entornos (staging, production) solo si los pasos anteriores tienen éxito.