Primer Pipeline

Vamos a crear nuestro primer pipeline, pero antes vamos a hacer la siguiente configuración. Edita el runner que configuraste anteriormente y desmarca la opción untagged jobs. Si estás siguiendo el estudio, mantén las mismas etiquetas pues será importante más adelante.

La opción untagged jobs quiere decir que solamente trabajos que tengan las etiquetas general o debian utilizarán el runner que creamos anteriormente. Si la etiqueta no es pasada serán utilizados los runners shared. Vamos a hacer esa experiencia.

Creando proyecto dentro del grupo. Usa el blank project.

Clona tu repositorio y vamos a crear el .gitlab-ci.yml vacío.

❯ git clone [email protected]:puziol/first-pipeline.git

Cloning into 'first-pipeline'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.

❯ cd first-pipeline

❯ ls
README.md

touch .gitlab-ci.yml

Atención: No se acepta gitlab-ci.yml ni .gitlab-ci.yaml. TIENE QUE SER .gitlab-ci.yml y necesita estar en la raíz del proyecto.

Trabaja en VSCode o en tu IDE favorito. Lo que nos interesa es sólo hablar del .gitlab-ci.yml por ahora. Todavía no es el momento de entender qué es qué y sí de entender quién va a ejecutar.

# .gitlab-ci.yml
test:
  script: "echo Hello World"

Guarda y añade todo en la rama predeterminada misma, sube el código y vamos a ver qué pasa.

❯ git add .gitlab-ci.yml

❯ git cm "add gitlab-ci"
[main bae0760] add gitlab-ci
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitlab-ci.yml

❯ git push origin main

Verificando el repositorio tenemos el pipeline ejecutándose.

Y después completado.

Ahora la pregunta es, ¿quién ejecutó? En build > Pipelines tenemos la ejecución.

Haciendo clic dentro del stage y después en test podemos ver el log de esa ejecución.

Fue usada una imagen que no es la del runner que definimos y el hecho de tener "blue-4.saas-linux-small-amd64" indica que es un runner SaaS de GitLab "runners-manager.gitlab.com" confirma que es gestionado por el propio GitLab.

Pero ahora yo quiero que se ejecute en el runner autohospedado que nosotros creamos.

Altera vamos a alterar el .gitlab-ci.yml.

# Todos los trabajos tendrán esta lista de etiquetas si no se define.
default:
  tags:
    - general

test:
  # Podemos definir las etiquetas cuando queramos trabajo por trabajo.
  # tags:
  #   - debian
  script: "echo Hello World"

❯ git add .gitlab-ci.yml

❯ git cm "add gitlab-ci"
[main bae0760] add gitlab-ci
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitlab-ci.yml

❯ git push origin main

¿Quién ejecutó el trabajo ahora? Sí, nuestro runner.

Pero ejecutó con la imagen predeterminada, pues no definimos una imagen.

Del mismo modo que hicimos con las etiquetas, podríamos definir una imagen predeterminada que sería utilizada por todos los trabajos o podemos definir una imagen diferente por trabajo. Vamos a sustituir la imagen solamente en el trabajo.

# .gitlab-ci.yml
default:
  tags:
    - fake # No existe

test:
  tags:
    - debian # Sustituyendo la etiqueta para probar
  image: alpine
  script: "echo Hello World Alpine"

Subiendo todo.

❯ git add .gitlab-ci.yml
❯ git commit -m "test cicd con alpine"
❯ git push origin main

Y tenemos el siguiente log.

Vamos a hacer dos cosas ahora al mismo tiempo. Edita nuevamente el pipeline y marca untagged para ese pipeline.

Otra cosa que haremos será crear dos variables de nivel de grupo. Ve a Settings > CI/CD > Variables.

La primera variable será VAR1 con el valor variable1 y vamos a dejarla como visible.

En VAR2 vamos a dejar como masked.

Ya en VAR3 vamos a dejar como masked y Hidden.

Ve que tenemos diferencias en cómo son mostradas en la GUI.

Ahora vamos al proyecto y veremos qué tenemos de variables. Podemos observar que tenemos las variables heredadas del grupo. Esta es una de las ventajas de utilizar grupos y subgrupos. Podemos declarar variables en cada grupo diferentes e ir acumulando variables declaradas.

¿Qué pasa si declaramos la misma variable? Vamos a hacer eso para VAR1 declarando nuevamente VAR1 a nivel de proyecto con el valor variable1new.

Observa que no podemos editar ninguna variable heredada de un grupo en el proyecto. Solamente tendremos permiso de lectura.

# No vamos a poner la etiqueta para ver qué pasa con el untagged
test:
  script:
  - echo $VAR1
  - echo $VAR2
  - echo $VAR3

❯ git add .gitlab-ci.yml
❯ git commit -m "test variables and untagged"
❯ git push origin main

Podemos observar que fue utilizado un shared runner de GitLab SaaS. Y las variables masked fueron respetadas, siendo la única diferencia del hidden a nivel de presentación en el proyecto. La misma variable a nivel de proyecto sobrescribe la variable de grupo.

Ahora la pregunta es... ¿Por qué nuestro runner no fue utilizado? En realidad podría haber sido utilizado, pero fue una cuestión de sorteo.

Vamos a ver qué tengo de runner en ese proyecto disponible.

Si deshabilitamos los runners de GitLab en el proyecto nuestro runner actuará, pero no necesitamos hacer eso en un proyecto, podemos hacer eso a nivel de grupo.

Una cosa interesante es observar por qué GitLab nos está entregando imágenes de ruby como predeterminadas. Los shared runners de GitLab.com se ejecutan en entornos gestionados por ellos — y muchos vienen con la imagen base ruby por defecto, porque GitLab está hecho en Ruby y asumen compatibilidad con muchos proyectos.

Incluso que tu proyecto no tenga nada de Ruby, si no especificas una image: en el .gitlab-ci.yml, GitLab puede usar una imagen predeterminada — que frecuentemente es algo tipo ruby:2.x en los runners compartidos.

Buena Práctica sobre Runners

1. Siempre declara la imagen base. Incluso que sepas cuál es la predeterminada, especifica en el .gitlab-ci.yml. Esto evita sorpresas si el predeterminado cambia en el futuro. Pon en el topo del archivo.

2. Usa etiquetas específicas para forzar el runner. Así, incluso que los shared runners de GitLab estén disponibles, tu runner será priorizado.

3. Usa una imagen personalizada con todo lo que necesitas. Si tienes libertad para elegir la imagen, monta una con todas las dependencias. Esto evita instalaciones innecesarias y acelera el pipeline, haremos esto más adelante cuando hablemos de rendimiento.

4. Organiza bien tus variables. Las variables de GitLab son pasadas como variables de entorno para los runners. Pon las que son comunes en los grupos y sólo mantén las específicas en el proyecto. Así, si necesitas cambiar algo global, no vas a tener que editar proyecto por proyecto.

Otros consejos vendrán con nuestro aprendizaje.

Hosted GitLab Runner

Como vimos antes, podemos también utilizar los shared runners, pero podemos elegir runners en GitLab si no queremos el nuestro.