Actividad 2. API Spring Boot con GitHub Actions y AWS Elastic Beanstalk

5. FASE 3B: Creación del pipeline de Integración Continua con GitHub Actions

Configurar un pipeline de Integración Continua (CI) que se ejecute automáticamente en GitHub cada vez que se suben cambios al repositorio.

El pipeline debe:

  • descargar el código,

  • configurar el entorno,

  • compilar el proyecto,

  • ejecutar los tests.

A partir de este momento, cada push validará automáticamente el proyecto

1 Creación del archivo de workflow

GitHub Actions detecta los pipelines definidos en la ruta:

.github/workflows/

Desde el panel Project de IntelliJ (lado izquierdo):

  1. Clic derecho sobre el proyecto

  2. New → Directory

    • Nombre: .github

Dentro de .github:

  1. New → Directory

    • Nombre: workflows

Dentro de workflows:

  1. New → File

    • Nombre exacto: ci.yml

La ruta debe quedar exactamente así:

.github/workflows/ci.yml

2 Definición del pipeline de Integración Continua

En el archivo ci.yml se define el comportamiento del pipeline.

Contenido completo del archivo (copiar tal cual):

name: CI - Construcción con Maven

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-test:
    runs-on: ubuntu-latest

    steps:
      - name: Clonar repositorio
        uses: actions/checkout@v4

      - name: Configurar JDK 17
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"
          cache: maven

      - name: Compilar y ejecutar tests con Maven Wrapper
        run: ./mvnw -B clean test

Este archivo no ejecuta nada en local.

Define qué debe hacer GitHub cuando detecta cambios en el repositorio.

4 Subir el workflow y lanzar el pipeline

Una vez creado el archivo ci.yml, se incorpora al repositorio remoto para que GitHub pueda ejecutarlo.

Revisión del estado del repositorio

Antes de realizar el commit del workflow, se revisa el estado del repositorio para comprobar qué archivos han cambiado:

git status

Debe aparecer el archivo del workflow como pendiente de añadir:

damiansualdea@Mac-Studio-de-Damian-2 dam-ci-cd-api-001 % git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   .github/workflows/ci.yml

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   .github/workflows/ci.yml

Añadir el workflow al control de versiones

Una vez verificado el estado, se añade el archivo del pipeline al control de versiones:

git add .github/workflows/ci.yml

Se vuelve a comprobar el estado:

git status

Y se realiza el commit correspondiente:

git commit -m "Añadir pipeline de integración continua con GitHub Actions"

Finalmente, se suben los cambios al repositorio remoto:

git push

Tras el push, GitHub Actions detecta automáticamente el pipeline y lo ejecuta.

5 Ver el pipeline en acción

Desde GitHub:

  1. Acceder al repositorio

  2. Abrir la pestaña Actions

  3. Seleccionar el workflow CI - Construcción con Maven

Se comprueba:

  • Evento: push sobre la rama main

  • Estado: Success

  • Ejecución correcta de:

    • checkout del repositorio

    • configuración de Java

    • compilación y tests

7 Forzar un fallo del pipeline (CI en rojo)

Objetivo: Comprobar que el pipeline detecta errores y marca la ejecución como Failure.

Procedimiento

  1. Introducir un error de compilación en Main.java (por ejemplo, eliminar un ;).

  2. Verificar en local:

./mvnw test
  1. Subir el cambio:

git add src/main/java/com/dam/cicd/Main.java
git commit -m "Romper compilación para demostrar CI en rojo"
git push

El pipeline fallará automáticamente.

Volver a verde
  1. Corregir el error

  2. Commit y push:

git commit -am "Arreglar error de compilación y restaurar CI"
git push

El pipeline volverá a ejecutarse correctamente.

Conclusión

Con esta fase queda implementada una Integración Continua real, donde:

  • cada push valida el proyecto,

  • los errores se detectan automáticamente,

  • el entorno es reproducible y externo.

“A partir de ahora, cada push valida automáticamente el proyecto.”