Le savoir n'a guère d'intérêt s'il n'est pas partagé.

J'utilise depuis un bon moment les CI Gitlab, très pratique pour lancer des tests unitaires, des builds, ou encore fournir un livrable. Je voulais simplement dans cet article, vous fournir mes astuces avec le fichier .gitlab-ci.yml que vous avez forcémment déjà vu si vous avez déjà utilisé les CI ! 😎

U're ready ?? 😁

Utiliser extends pour éviter les répétitions!😁

La directive extends est un excellent moyen de réutiliser certaines parties de YAML à plusieurs endroits (une sorte de 'template'), par exemple:

.go_image_template:
  image:
    name: go:latest

test:
  extends: .go_image_template
  script:
    - echo "Testing"

deploy:
  extends: .go_image_template
  script:
    - echo "Deploying"
.gitlab-ci.yml

Dans l'exemple, je créé une clé cachée (car elle commence par un .) et haut de mon fichier que je peux ensuite appeler à travers les différentes étapes (test, deploy).

Bien sûr on peut étendre les fonctionnalités afin d'obtenir des choses bien plus complexes et de réduire la complexité et de rendre la pipeline plus lisible. 😍

Utiliser include pour "templatiser" vos projets...😉

Bon, pour éviter de se répéter, on peut inclure un template (un fichier YAML) grâce à la directive include dans notre pipeline actuelle.

Le fichier peut être soit local, soit distant dans un autre dépôt. 🐱‍🏍

On pourrait très bien créer un dépôt qui contient uniquement nos templates pour tous nos projets. Ce qui est très pratique si on souhaite partir sur une pratique DevSecOps où l'équpe sécu pourrait founir des templates ayant les prérequis sécu! 😊

Pour l'exemple (fichier dans le repo templates):

stages:
  - test

variables:
  ENV: "none"

test:
  script:
    - echo "Testing in ${ENV}"
base-testing.yml

Et dans notre fichier gitlab-ci.yml:

include: 'https://gitlab.com/templates/raw/master/base-testing.yml'

variables:
  ENV: "dev"

gitlab-ci.yml

Nous pourrons ainsi réutiliser le fichier base-testing.yml défini dans notre dépôt nommé templates de modèles de CI, et nous écraserons simplement toutes les variables avec leur valeur du fichier de base. C'est plutôt propre, non?? 😎

Utiliser les anchors !

C'est une astuce qui n'est pas souvent utilisée mais qu'il est tellement pratique!

Vous pouvez ainsi déclarer de la configuration et l'appeler un plusieurs fois, génial pour éviter de se répéter! 🐱‍👤

.job_template: &job_definition
  image: ruby:2.6
  services:
    - postgres
    - redis

test1:
  <<: *job_definition
  script:
    - test1 project

test2:
  <<: *job_definition
  script:
    - test2 project

gitlab-ci.yml

Ainsi le code:

  image: ruby:2.6
  services:
    - postgres
    - redis
   

Sera appelé à l'identique pour test1 et test2. Magique!

Attention tout de même, cette fonction a ses limites, en effet, il n'est pas possible d'utiliser les anchors sur plusieurs fichiers lorsque vous utilisez la directive include.

Les anchors ne sont valables que dans le fichiers dans lequel elles ont été définies.

Eviter les "-" pour déclarer des commandes shell ! 😜

Une astuce vraiment très cool quand on la connait, plutôt que de s'amuser à positionner un - devant chaque commande, on va plutôt placer la chose suivante: script: |.

Par exemple (parce que c'est plus parlant avec un exemple):

  script:
    - GOOS=linux GOARCH=amd64 go build -o builds/${PROJECT_NAME} src/main.go
    - ./builds/${PROJECT_NAME}
Avant! 😉

Puis ensuite:

  script: |
  	GOOS=linux GOARCH=amd64 go build -o builds/${PROJECT_NAME} src/main.go
	./builds/${PROJECT_NAME}
Après! 😁

C'est beau, n'est-ce pas! (Désolé d'avance pour les chats!)

Inclure des fonctions shell 💥

Alors ça, ça peut vraiment vite devenir très pratique! Il est possible de déclarer des fonctions shell directement dans le fichier .gitlab-ci.yml.

Pour ce faire:

.tools: &tools |

	function say_hello() {
		echo "Hello $1"
    	}
    
	function addition() {
		echo "$(($1 + $2))"
	}

before_script: # Appeler "tools" avant d'exécuter le script!
	- *tools
.gitlab-ci.yml

Pour aller encore plus loin on peut les inclure dans notre fichier template et les appeler avec la directive include (appelé le fichier que les détient).

Pour les appeler:

stages: 
	- hello
    
use_the_function:
	stage: hello
    	tags: 
    		- shell
        
	script: |
    	say_hello "Coucou Gitlab!"
        addition 1 2 # retourne ainsi 3 ^^
        
  
.gitlab-ci.yml

Toujours dans une démarche pour éviter les répétitions, ont voit là, toutes les possibilités avec ce fichier qui sont énormes!

Enfin voilà quelques astuces plutôt pratiques que j'utilise très régulièrement et qui je pense pourraient vous être utile. 😎