Gitlab

17/11/20 danny

Gitlab


Premier dépôt

YAML: YAML Ain’t Markup Language

Création du fichier .gitlab-ci.yml

Ce fichier indique au GitLab Runner ce qu'il doit faire.
3 types de stages

  • build
  • test
  • deploy

Le fichier ne doit contenir que des espaces pas de Tabs


Les principes

Principes

Pour que la CI/CD sur GitLab fonctionne

  • il faut un manifeste .gitlab-ci.yml à la racine de votre projet.
    Dans ce manifeste vous allez pouvoir définir des stages, des jobs, des variables, des anchors,
     
  • Nombre illimité de jobs, avec des contraintes indiquant quand ils doivent être exécutés ou non.
     
  • BEFORE_SCRIPT ET AFTER_SCRIPT
    Ces déclarations permettront d’exécuter des actions avant et après votre script principal

Les pipelines

Un pipeline est un élément assez simple, ayant un status : in progress, pending, passed et (je ne vous le souhaite pas) failed.

En consultant un pipeline, nous pouvons voir sa structuration, il est constitué de 1 ou plusieurs jobs, organisés dans différentes colonnes. Tout cela se configure dans le fameux fichier .gitlab-ci.yml.

Je vous entend déjà raler en voyant l’extension yml, mais rassurez vous, . Utile pour éviter de voir vos pipelines planter car le yaml est invalide ! Il est disponible dans la page des pipelines :

GitLab a mis un outil CI Lint qui vous permet de valider vos pipelines

Le fichier .gitlab-ci.yml commence généralement par les définitions de nos “colonnes”. Il s’agit de stage. Un pipeline peut contenir autant de stage qu’il nous semble utile. Les différents traitements se feront de manière séquentielle. Dans cet exemple il y a 5 étapes dans la construction de notre projet :

Ci dessous comment s'execute un pipeline
En fonction de la branche indiquée

Dans cet exemple, dès qu’un push est effectué sur la branche dev et master, le pipeline définit va s’exécuter.

only:
    - dev
    - master

Les jobs

La déclaration script est donc la seule obligatoire dans un job.

Un job est ce qui va permettre de réaliser une ou plusieurs tâches. Le job le plus simple doit être composé d’une action dans une partie script :

Faire un test on obtient le message

  • jobs myjob:01 config should implement a script: or a trigger: keyword

Afin d’optimiser le temps de traitement de notre pipeline, il est possible (voire conseillé) de paralléliser les traitements. Pour cela plusieurs jobs peuvent être associés à un stage. Dans cet exemple, tous les jobs de build de composants sont réalisés en parallèle.

# Déclaration d'un job
myjob:
  script: echo 'premier script du job myjob'
ou

myjob:
  script : 
     - echo 'premier script du job myjob'


# Déclaration de Deux jobs (Méthode 1)
myjob1:
  script: echo 'premier script du job myjob1'

myjob2:
  script: echo 'premier script du job myjob2'  



# Déclaration de Deux jobs (Méthode 2)
myjob:1:
  script: echo 'premier script du job myjob1'

myjob:2:
  script: echo 'premier script du job myjob2'  
Before_script et after_script
# Exécution d'une commande avant chaque `job`
before_script: 
  - echo 'execution avant chaque job'

# Exécution d'une commande après chaque `job`
after_script: 
  - echo 'execution après chaque job'

# Déclaration du job 1
myjob1:
  script: echo 'premier script du job myjob1'

# Déclaration du job 2
myjob2:
  script: echo 'premier script du job myjob2'  

Utilisation des images docker

Cette déclaration est simplement l’image docker qui sera utilisée lors d’un job ou lors de tous les jobs
 

Il y a ensuite le mot clé image. Il permet d’effectuer une action à l’aide d’image docker. Il peut être positionné pour l’ensemble des jobs dans la première ligne du fichier .gitlab-ci.yml, ou pour chaque job.

Commun à tous les jobs :

image: alpine # Image utilisée par tous les `jobs`, ce sera l'image par défaut

myjob-avec-node: # Job utilisant l'image node
  image: node
  script: npm install

myjob-avec-alpine: # Job utilisant l'image par défaut
  script: echo $USER
image: alpine

job1:
  stage: first_stage
  script : 
     - echo "Voici mon premier job"
job2:
  stage: second_stage
  script : 
     - echo "Voici mon second job"


##### deuxieme solution

job1:
  image: alpine
  stage: first_stage
  script : 
     - echo "Voici mon premier job"
job2:
  image: alpine
  stage: second_stage
  script : 
     - echo "Voici mon second job"

Les stages ou étapes

Cette déclaration permet de grouper des jobs en étapes. Par exemple on peut faire une étape de build, de codestyling, de test, de code coverage, de deployment, ….

 

Afin d’optimiser le temps de traitement de notre pipeline, il est possible (voire conseillé) de paralléliser les traitements. Pour cela plusieurs jobs peuvent être associés à un stage. Dans cet exemple, tous les jobs de build de composants sont réalisés en parallèle.

Ces stages sont lancés séquentiellement et sont composées de jobs. Une étape doit contenir au moins un job, ces derniers étant exécutés en parallèle par défaut. Voici la structure de la pipeline que nous allons mettre en place, libre à vous de l'adapter :

stages:
  - build

front:
  stage: build
  script: echo 'execute front'

api_go:
  stage: build
  script: echo 'execute api_go'

node:
  stage: build         
  script: echo 'execute node'
stages: # Ici on déclare toutes nos étapes
  - mybuild
  - mytest
  - mydeploy

myjob-build:
  stage: mybuild # On déclare que ce `job` fait partie de l'étape build
  script: echo 'make build'

myjob-test-unit:
  stage: mytest # On déclare que ce `job` fait partie de l'étape test
  script: echo 'unit'

myjob-test-functional:
  stage: mytest # On déclare que ce `job` fait partie de l'étape test
  script: echo 'make test-functional'

myjob-deploy:
  stage: mydeploy # On déclare que ce `job` fait partie de l'étape deploy
  script: echo 'make deploy'

La commande only

  only:
    - master


 only:
    - dev
    - master


 only:
    - features*

Les notifications

Si vous souhaitez être notifié sur Slack, Discord ou autre application du statut de vos pipelines lors d'un push, vous pouvez vous rendre sur GitLab et naviguer dans Settings > Integrations et activer les notifications correspondantes.