GitLab CI: configuración, stages y variables para automatización
Contenido del curso
David Behar
Cristian Córdova
Miguel Alexander Mejía
Nathaly Stefani Riaño Bejarano
Nathaly Stefani Riaño Bejarano
Anderson Gil Petit
Juan Diego Silva Garcia
Jhoan Franco
Jhoan Franco
Jorge David Duque Agudelo
Alvaro Alvarez
Wilmer Ariel Moina Rivera
Pablo Aquino
Massimo Di Berardino
Pablo Aquino
Jorge David Duque Agudelo
Gustavo Saldivia
Julian Gomez
Walter Renzo Talaverano Cruz
Kevin Morales
アルマ レボ
Aaron Santiago Loyo Zabala
Nathaly Stefani Riaño Bejarano
Gonzalo Amador Hernández
Otro Chino
Oscar Téllez
Anderson Gil Petit
Daniel Alfredo García Serna
Éstos son los servicios de Gitlab para CI y CD
Maquina! Muchas gracias por el aporte! :D
Les dejo un gitlab-ci.yml funcional para SpringBoot que mide:
coverage (jacoco) mutation (pitest) Construye la imagen docker y la publica en el registry de gitlab.
image: docker:latest services: - docker:dind variables: DOCKER_DRIVER: overlay stages: - coverage - mutation - build - package gradle-build: image: gradle:alpine stage: build variables: GRADLE_OPTS: "-Dorg.gradle.daemon=false" before_script: - export GRADLE_USER_HOME=`pwd`/.gradle script: gradle bootJar artifacts: paths: - build/libs/*.jar expire_in: 1 week gradle-test: image: gradle:alpine stage: coverage script: gradle test jacocoTestCoverageVerification gradle-mutation: image: gradle:alpine stage: mutation script: gradle pitest docker-build: stage: package script: - docker build -t registry.gitlab.com/msgoon6-scholar/schollar-service . - docker login -u msgoon6-************ -p ******************** registry.gitlab.com - docker push registry.gitlab.com/msgoon6-scholar/schollar-service
Variables .
Trigger Variables: Son variables automatizadas cuando se detona un nuevo build. Project Variables (y Protected Variables): Son variables que se pueden definir para que sean expuestas únicamente en un proyecto específico o algunas ramas específicas.
Group Variables: Son variables que se pueden definir para que estén expuestas en un grupo específico.
YAML Job Level Variables and YAML Global Variables: Son variables que se pueden incluir en el archivo de configuración yaml.
Deployment Variables: Son variables enfocadas a almacenar información o credenciales para la integración con servicios externos, por ejemplo kubernetes, para hacer el deploy del proyecto.
Pre Defined Variables: Son variables predefinidas que se exponen por parte de GitLab en cada uno de los trabajos de automatización.
.gitlab-ci.yml . El archivo de configuración de GitLab CI funciona a traves de keywords. Cada una de estas keywords nos permiten configurar los trabajos.
Es un tipo de código declarativo, es decir que no necesitamos generar mucha lógica en el archivo, si se necesita incluir lógica adicional en el archivo, lo más conveniente es pasar esa lógica a otros archivos, de tal manera que gitlab-ci.yml nos especifique cuales son los trabajos de alto nivel. .
Image: GitLab CI trabaja por medio de contenedores. Se debe declarar un contenedor al principio para poder definir el ambiente global en el cual vamos a trabajar, por ejemplo, si tenemos el proyecto bajo Angular el ambiente a escoger sería el de Node, pero si tenemos el proyecto en Flask el ambiente a escoger sería el de Python.
Stages: Son los pasos o fases específicos por los cuales va a pasar nuestro proceso de integración continua. Por lo general, se establecen 3 fases: build, test y deploy, pero se pueden incluir pasos adicionales como documentación.
Jobs: Se pueden nombrar los jobs como se considere. Cada Job va a pertenecer a un Stage, se le puede definir las Variables y los Scripts que es donde nosotros automatizamos.
Otro que investigue, y que me pareció muy util fue : -merge_requests
Este sirve para especificar (por medio de only),que job correrá al momento de solicitar un merge, lo veo muy útil para ambiente de pruebas QA o de perfomance,de resto no se me ocurre para qué, de momento.
Ejemplo:
<code> test: stage:QA script: ./QA only: -merge_requests
en este caso el job test correrá solo al solicitar un merge
Es posible configurar el gitlab-ci.yml dentro de un directorio .gitlab-ci? parecido a como se maneja en circle ci
/gitlab-ci/git-lab-ci.yml
acabo de encontrar la forma. Para el que lo necesite solo debe ingresar a la configuración del repo en gitlab e ingresar a las settings del CI/CD.
General pipelines -> Custom CI config path
En esa parte pueden configurar la ruta donde se encuentra el .gitlab-ci.yml de su repo
Excelente, gracias por el dato.
si están probando con una app de RubyOnRails les comparto el pipeline que hice para correr los test unitarios con rspec.
stages: - test .base: image: ruby:2.7.0 cache: paths: - apt-cache/ - vendor/ruby policy: pull before_script: - gem install bundler --no-document - bundle install --jobs $(nproc) "${FLAGS[@]}" test:rspec: stage: test extends: .base script: - bundle exec rspec
GitLab CI, sólo funciona con contenedores o también puede funcionar con aplicativos que no están en contenedores?
Hola @pcaa3000. No, tienes varios métodos de integración, te comparto la documentación para que los veas
Gracias @massimokris, revisaré la documenación.
Según lo que encontré acerca de before_script, es que es utilizado para cuando varios jobs comparten un mismo script, para esto se agrupan esos comandos en común dentro de esta etiqueta, como por ejemplo:
Y el keyword de after_script es la agrupación de scripts que se ejecutaría despues de cada job definido, incluso si fallan, particularmente lo vería con algo de utilizad para generar algún reporte, o notificar el resultado a algún administrador, pero tengo mis dudas aún.
Documentación: https://docs.gitlab.com/ee/user/project/pages/getting_started_part_four.html#before-script
https://docs.gitlab.com/ee/ci/yaml/#before_script-and-after_script
Profe quiero ser como usted cuando sea grande!
Hola, en algunos equipos de trabajo, no contamos con Tests, por diferentes motivos, sin embargo, nos interesa implementar el resto, es posible saltar el paso de Test y solo hacer Build con Gitlab CI?
Pregunta, cual es la diferencia entre Gitlab CI y jenkins?
Ambos hacen básicamente lo mismo. Jenkins es más fácil de aprender y usar, tiene muchísimos plugins y puede ser tanto beneficioso como caótico, Jenkins tiene una interfaz gráfica.
Yo escogería Jenkins por encima de Gitlab CI, pero si ya tienes el repostiorio en Gitlab y estas envuelto en su ciclo, mejor usar el de Gitlab.
No entendí nada salu2
XD
Documentacion de Variables en GitLab CI:
Hola!, tengo una duda acerca del comando 'image', cuando David menciona que se pueden seleccionar entre miles de imágenes, de dónde las obtiene? Gitlab tiene su propio repositorio de imágenes algo parecido a Dockerhub?
Asi es, por defecto va por las imagenes en Dockehub. Te dejo lo que pone en la documentación:
By default, the executor will only pull images from Docker Hub, however this can be configured in the gitlab-runner/config.toml by setting the Docker pull policy to allow using local images.
Leí acerca de refs , la cual dice que es una simplificación de only y except. por ejemplo:
<code> - test: only: -master -test
/esto quiere decir que el job "test" correrá solo si es ejecutado desde la rama master o test del repositorio, por lo que esta implícito que en el resto de ramas NO lo hará./
📚 Nombre de la clase
GitLab CI: configuración de stages y variables
🎯 Idea principal
GitLab CI permite definir pipelines estructurados mediante stages (etapas) y variables (configuración reutilizable). Los stages organizan el flujo de ejecución, mientras que las variables permiten flexibilidad y seguridad. Esta configuración hace que los pipelines sean ordenados, escalables y fáciles de mantener. El objetivo es construir procesos automatizados claros y reutilizables.
⚡ Síntesis en 10 segundos
🔑 Puntos clave
🧠 Conceptos importantes
.gitlab-ci.yml)🧩 Modelo mental de la clase
Stages → Jobs → Variables → Ejecución → Resultado
Idea clave: Orden + configuración flexible = automatización eficiente.
🚀 Acciones inmediatas
💼 Aplicación profesional
Impacto real: pipelines más organizados, seguros y eficientes.
🔥 Hacks para la comunidad
📝 Reflexión estratégica
La automatización sin estructura se vuelve caótica. Stages y variables convierten pipelines en sistemas organizados y escalables.
Los equipos que estructuran bien su CI/CD construyen sistemas confiables a largo plazo.