Creamos nuestra cuenta en GitLab
Vamos a crear nuestra cuenta en GitLab, que va a ser la herramienta utilizada para llevar
a la práctica nuestros Pipelines.
Registración y preparación del entorno
1. En la pantalla inicial, nos dirigimos a “Register now”
2. Los datos que debemos completar son los siguientes, automáticamente nos
informará si el nombre de usuario o email seleccionado está en uso.
3. Recibiremos una confirmación y se nos informa que debemos ir a chequear nuestro
email; revisar correctamente tanto Inbox como carpetas de Spam.
1
4. Confirmamos nuestra cuenta, con lo cual ya estamos en condiciones de loguearnos.
5. En la pantalla inicial de bienvenida seleccionamos “Create Project”, luego “Create
blank Project” y finalmente, completamos el dato de “Project Name”; dejamos la
visibilidad de este en “Private”.
1) 2)
3)
6. Por defecto se nos crea un Repositorio Git en el cual podemos subir nuestros
archivos, en el mismo se incluye un [Link] con instrucciones básicas para
dicho fin. Si bien como en todo repositorio Git podemos subir nuestros archivos a
través de la interfaz Web, no es su uso habitual, así que ahora prepararemos nuestro
entorno para poder subir código desde nuestro equipo; nos llevara unos pasos en los
cuales debemos utilizar nuestra línea de comandos / consola
6.1. Abrimos en NUESTRO EQUIPO un Shell como Bash o la Terminal de Linux con el
propósito de generar una SSH Key, para ello ejecutamos:
ssh-keygen -t rsa
2
Nos preguntará por un nombre y un passphrase (opcional), dejamos todo por
defecto
Leemos el contenido del mismo con
cat ~/.ssh/id_rsa.pub
se nos mostrará un contenido tal como
cat ~/.ssh/id_rsa.pub
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABgQCmixQfacbczvWXZmkQJ6+UqNRYQuglycl+0qJ0gvsbX
gG8D9MjwClrQQPeKmmOpSSZPmog3anGMEv3CraRJD0nwjml+NSPRyrHSV+l7V9x++gxk+b52l
xKnQuHMzrgWt62uflABx8hi5pzgrC1SpF3fkyzG25sO7xNclJ9cKuAwzfHCJ1JEOCQQ1yUsu5
0+xEgGdo3AjaGpAn04Mqniq435CwmMbEDZqWpcWCqw7V0gwgonbPBYrrprTUIRpAu7az7RoW4
z1GUzMWEr9KICfpgvBBUgmfwULKxSaGuetHfRAa9NQenSc2emaMSURdxkkm8b+r2xyK7TJ6y+
140rVkfXKHm8jdEz9XJlyJBn3QoeYLShYp9TmSiGwTy9SCcuUljQO4K3eSA49Zbh+ZUjE0H2m
v9ws9TVYl88mww+oLxgj3z+AJN5f8DEaFm9mhx+CBgfmQzOKkXes+8jveUgjrLO8Zzg/rsTB9
h+h2dCPMWKcexhSvwqpHPIxpW6U7lrHs= mundose@mundose
6.2. Nos dirigimos al Gitlab, en la sección “SSH Keys” (SSH Keys · User Settings ·
GitLab ”
6.3. Copiamos todo el contenido que se mostró en el punto 6.1 con el comando cat (a
partir de que comienza con ssh-rsa inclusive) y lo pegamos en la sección “Key”, le
damos un nombre en “Title” y opcionalmente una fecha de expiración, luego de
ello en “Add Key”.
6.4. Una vez guardada la misma en GitLab, debemos verificar que podemos
conectarnos desde nuestro entorno, para ello volvemos a nuestro Shell y
ejecutamos
ssh -T git@[Link]
3
Si es satisfactorio, debemos recibir el mensaje “Welcome to GitLab, @MINOMBRE DE
USUARIO!”
Con lo cual podremos subir nuestro código al repositorio de Gitlab.
Subimos nuestro primer código
Como ejemplo, subiremos un código fuente hecho en Node, el mismo se puede
descargar desde aquí
[Link]
[Link]
1. Una vez descargado y descomprimido, nos dirigimos hacia la carpeta
“node-bulletin-board-master” en nuestro Shell. Una vez allí dentro, inicializamos el
repositorio con el comando
git init
2. Agregamos el origen remoto con el comando, teniendo en cuenta que en lugar de
“usuario” irá su nombre de usuario y en lugar de “proyecto”, el nombre de su proyecto
git remote add origin [Link]
3. Agregamos los archivos del proyecto con
git add .
4. Realizamos el commit con
git commit -m "First Commit"
5. Cambiamos al Branch de test (IMPORTANTE: por defecto GitLab protege al Branch
main, es por ello que usamos un Branch de test)
git branch -M feature-x
6. Finalmente hacemos push de nuestro código
git push -uf origin feature-x
7. Observamos en GitLab, en el Branch correspondiente que nuestro código ya está
subido.
4
Creamos nuestro primer pipeline
Ahora vamos a crear la definición de un pipeline en GitLab es el archivo .[Link], el
cual debe estar alojado en la raíz de nuestro proyecto.
Para ello, abrimos un Shell en nuestro equipo, nos dirigimos a la raíz de nuestro proyecto
y allí creamos con el editor de texto de nuestra preferencia el archivo .[Link]
1 - Configuramos la imagen
Vamos a definir qué imagen de Docker se va a utilizar para ejecutar los pasos del
pipeline
image: node:14
5
2 - Creamos los stages
La definición del pipeline se da en stage y jobs, estos pertenecen a los stages, es
decir, los primeros stages son los que están a mayor nivel jerárquico.
La ejecución de los stages es de acuerdo a como los definamos en nuestro archivo,
por convención para esta primer práctica, construiremos dos stages
● test
● build
Agregamos en nuestro archivo .[Link] las líneas, recordemos siempre respetar
el indentado
stages:
- test
- build
Si bien esta definición es correcta, básicamente este pipeline no hará nada ya que los
stages carecen de jobs, que es donde se ejecutan los trabajos.
3 - Agregamos los jobs
Los jobs se definen en el archivo y su pseudo estructura es
nombre_job
stage: “stage a la que pertenece”
script:
- “comandos a ejecutar en el job”
Nosotros en primer lugar vamos a definir un job para nuestro stage “test”, el cual
ejecutara los tests especificados para este código, con lo cual el comando será:
“npm run test”.
6
El codigo de nuestro .[Link] con el agregado del job deberá ser:
image: node:14
stages:
- test
- build
test_job:
stage: test
script:
- echo "NPM tests started..."
- npm run test
Hasta ahora, definimos el pipeline, pero aun GitLab no se ha enterado de los cambios, es
momento que lo haga y para ello debemos impactar estos cambios que aún están en
nuestro equipo en el repositorio, es por eso que debemos hacer push de este nuevo
archivo, ejecutando en nuestro equipo:
git add .
git commit -m “Added pipeline”
git push
GitLab, al recibir los cambios en el código, detecta automaticamente la presencia del
archivo .[Link] y si su estructura es válida, EJECUTA los pasos definidos en el, es
por ello que ahora si vamos a nuestro GitLab CI/CD Pipelines, observaremos el listado de
Pipelines ejecutados y alli estará el correspondiente al último commit:
7
Si ingresamos en el número del pipeline allí veremos los stages que se ejecutaron:
Aquí vemos que solo se ejecutó el stage BUILD, y su job “test_job”, si ingresamos en él
observaremos todo el detalle de la ejecución:
8
Detalles de la ejecución del “test_job”, en donde se observa el Job succeeded
Al estar vinculado con el repositorio de código, ante cualquier cambio en mi código
fuente (no solo en el .[Link]) el pipeline se volverá a ejecutar.
Si realizamos un cambio en algún archivo del código fuente (por ejemplo el mensaje
mostrado en [Link]) y al realizar el push observar el comportamiento del pipeline.
Al agregar el job de build al stage de Build el pipeline quedaría de esta manera:
image: node:14
stages:
- test
- build
test_job:
stage: test
script:
- echo "NPM tests started..."
- npm install
- npm run test
build_job:
stage: build
script:
- echo "NPM build started..."
- npm run build
9
Nuestro Pipeline se debió ejecutar de manera satisfactoria, con lo cual al ver los detalles
del mismos deberíamos verlo así (lo vemos en el menú CI/CD Pipelines # de pipeline)
Ahora lo que vamos a realizar son modificaciones en el archivo [Link] con el propósito
que fallen nuestras stages.
Cuando un Pipeline falla, en este ejemplo hicimos fallar el stage de test, vamos a ver en
nuestro resumen del Pipeline
Y es allí cuando debemos investigar porque sucedió, en este caso nos vamos a dirigir al
test_job y nos abrirá el verbose / debug de todo el proceso, desde que se genera el
entorno para las pruebas hasta el momento en que se prueba.
Lo importante, es que si un stage falla, el siguiente no se ejecutara cómo vemos a
continuación:
10
11
