¿Qué sucede después de que GitLab descarga el código?

Después de que GitLab descarga el código del repositorio en el directorio de trabajo, comienza la ejecución del pipeline de CI/CD definido en el archivo .gitlab-ci.yml.

1. Análisis de .gitlab-ci.yml: GitLab Runner (o GitLab en sí, si se usa CI integrado) lee la configuración desde .gitlab-ci.yml. Este archivo describe las etapas (stages) y tareas (jobs) del pipeline.
2. Inicialización del Runner: Se asigna un GitLab Runner disponible para ejecutar el pipeline. El Runner obtiene información sobre el repositorio, el commit, la rama y la configuración de .gitlab-ci.yml.
3. Creación del entorno de ejecución: El Runner prepara un entorno para ejecutar las tareas. Esto puede ser:
   • Máquina virtual
   • Contenedor (Docker, Kubernetes)
   • Servidor dedicado
   • Shell
4. Ejecución de las etapas (stages): El pipeline se ejecuta secuencialmente por etapas, definidas en .gitlab-ci.yml. Las tareas en una misma etapa pueden ejecutarse en paralelo.
5. Ejecución de las tareas (jobs): Dentro de cada etapa, se ejecutan las tareas configuradas. La tarea incluye:
   • Definición de la imagen o ejecutor (executor), si no está definido a nivel de pipeline o sección variables.
   • Clonación del repositorio (ya hecho por GitLab, pero el Runner puede realizar git fetch o git checkout para el estado necesario).
   • Restauración de la caché (si está configurada) para acelerar la compilación (por ejemplo, carga de dependencias).
   • Ejecución de scripts (script): Es el contenido principal de la tarea, donde se ejecutan comandos de compilación, prueba, análisis o despliegue.
   • Carga de artefactos (si está configurado): Los resultados de la tarea (por ejemplo, binarios compilados, informes) se almacenan para su uso o descarga posterior.
   • Guardado de la caché (si está configurado) para acelerar ejecuciones futuras.
6. Informe de estado: El Runner envía el estado de cada tarea (éxito, error, cancelación) de vuelta a GitLab. El usuario ve el progreso y los resultados en la página del pipeline.
7. Pasar a la siguiente etapa: Si todas las tareas en la etapa actual finalizan con éxito (o se ha configurado allow_failure), comienza la siguiente etapa. Si una tarea termina con error y allow_failure no está establecido, se interrumpe todo el pipeline.
8. Finalización del pipeline: Después de ejecutar todas las etapas (o en caso de error), el pipeline termina. Los resultados y artefactos están disponibles a través de la interfaz web de GitLab.

Ejemplo de estructura de /.gitlab-ci.yml`:

// Definimos las etapas de ejecución del pipeline
stages:
  - build
  - test
  - deploy

// Tarea de construcción en la etapa build
build_job:
  stage: build
  image: docker:latest // Usamos una imagen Docker
  script:
    - echo "Construyendo la aplicación..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Construimos la imagen Docker
  artifacts:
    paths:
      - myapp.tar // Guardamos el artefacto de construcción

// Tarea de prueba en la etapa test
test_job:
  stage: test
  image: python:3.9 // Usamos una imagen Python
  script:
    - echo "Ejecutando pruebas..."
    - pip install -r requirements.txt
    - pytest // Ejecutamos las pruebas
  needs: ["build_job"] // Depende de la finalización exitosa de build_job

// Tarea de despliegue en la etapa deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // Usamos una imagen Ubuntu
  script:
    - echo "Desplegando la aplicación..."
    - echo "Aquí va el script de despliegue..." // Script de despliegue
  only: // Ejecutar solo en commits en master o tags
    - master
    - tags
  needs: ["test_job"] // Depende de la finalización exitosa de test_job

Por lo tanto, la descarga del código es solo el primer paso, seguido de un proceso complejo de construcción, prueba y despliegue automatizado, basado en la configuración de .gitlab-ci.yml.