Série de TP progressifs

Avant de commencer, vérifiez que vous pouvez utiliser votre compte Gitlab avec une connection SSH

Voici les exercices que nous avons fait en direct que vous pouvez refaire. Ils peuvent être légèrement différents de ceux réalisés en direct.

Faire uniquement avec les shared runners GitLab (Linux). Chaque TP contient les objectifs, les fichiers à créer, le .gitlab-ci.yml, ce que l’on doit voir pour valider.

Démonstration avant les TP

Voici la création d’un Projet “premierPipeline” sur GitLab :

alt text

Maintenant, il faut créer votre fichier .gitlab-ci.yaml sur votre machine en local. Nous pourrions le faire directement sur GitLab mais nous allons faire un push depuis notre répertoire de pseudo projet vers notre repository GitLab.

stages:          # Liste des étapes (stages) avec les "jobs"
  - build
  - test
  - deploy

# Ce "job" est associé au stage "build", il est lancé en premier
build-job:
  stage: build
  script:
    - echo "Compilation du code..."
    - echo "Compilation complete."

# Ce "job" est associé au stage "test"
unit-test-job:
  stage: test    # Il démarre seulement lorsque le job du "build" est "successful" !
  script:
    - echo "Lancement des tests unitaires... ça prend 30 secondes, patientez"
    - sleep 30
    - echo "Code est couvert à 90%"

# Ce "job" est aussi associé au stage "test"
lint-test-job:   
  stage: test    # Il se lancera en même temps que le "unit-test-job" (en parallèle).
  script:
    - echo "Linter du code... amélioration du code (statique) avec une durée de 10 secondes"
    - sleep 10
    - echo "Pas de code à améliorer ;)"

# Ce "job" est associé au stage "deploy".
deploy-job:      
  stage: deploy  # Il sera lancé uniquement si les 2 jobs du stage "test" sont OK.
  environment: production
  script:
    - echo "Deploiement de l'application..."
    - echo "Votre application est déployée avec succès, youpi !"

Ensuite, vous allez pusher votre repo local vers votre projet/repo Gitlab

git init --initial-branch=main --object-format=sha1
git remote add origin git@gitlab.com:Phil75013/premierpipeline.git
git add .
git commit -m "Initial commit"
git push --set-upstream origin main

alt text

puis le push

alt text

On constate qu’il y a bien notre fichier yaml .gitlab-ci.ymlprésent dans notre repository GitLab.

alt text

il reste à l’exécuter soit depuis notre machine locale soit sur GitLab directement !

alt text

On constate que tout est ok le premier stage/job est passed

alt text

Dans “Jobs” on voit tous les jobs du pipeline en ordre décroissant, le plus récent étant le premier (deploy).

alt text

Si on va dans “Jobs”, on en sélectionne un, le premier par exemple, et l’on voit le processus complet relatif à notre fichier de pipeline :

alt text

Votre pipeline est terminé (Passed / Failed)

Le bouton “Retry” n’apparaît que si un ou plusieurs jobs ont échoué !

Si tout ce passe bien (tous les jobs sont verts (Passed), GitLab n’ajoute pas de bouton pour relancer le Pipeline depuis l’interface GitLab.

Voici une manière de le relancer :

Aller dans CI/CD –> Pipelines –> New pipeline pour le relancer manuellement.

Relancer le pipeline complet (même s’il est vert) : “Build –> Pipelines –> New pipeline”

La branche main Puis cliquer sur Run pipeline, c’est exactement le même effet qu’un Retry All.

alt text

démo 2 : BadPipeline

alt text

Lancer depuis votre répertoire de votre projet sur votre machine :

git init --initial-branch=main --object-format=sha1
git remote add origin git@gitlab.com:Phil/badpipeline.git
git add .
git commit -m "Initial commit"
git push --set-upstream origin main

Quelques explications des commandes si vous n’avez pas l’habitude :

git init --initial-branch=main --object-format=sha1 :

Élément	Rôle
`git init`	Initialise un nouveau dépôt Git local (crée un dossier `.git/`).
`--initial-branch=main`	Donne le nom de la première branche : ici main (et non `master` par défaut).
`--object-format=sha1`	Définit le format des objets Git (anciens dépôts = SHA-1, les plus récents peuvent être SHA-256).

Certains serveurs GitLab/GitHub refusent encore le format SHA-256, donc il faut préciser –object-format=sha1 pour des questions de compatibilité.
Cela crée la structure interne de Git (fichiers .git/config, HEAD, etc.).

git remote add origin git@gitlab.com:Philippe/badpipeline.git :

Élément	Rôle
`git remote add`	Ajoute une connexion distante (remote) vers un dépôt GitLab.
`origin`	Nom par convention du dépôt distant principal.
`git@gitlab.com:Philippe/badpipeline.git`	URL SSH du dépôt GitLab cible.

Permet de pousser vos commits vers le dépôt distant appelé origin

Ici, c’est juste pour voir les URLs de fetch et push :

git remote -v

git add . :

Élément	Rôle
`git add`	Sélectionne des fichiers à inclure dans le prochain commit (“staging area”).
`.`	Ajoute tous les fichiers modifiés ou nouveaux du dossier courant.

Git ne versionne pas automatiquement les fichiers.
git add . permet de préparer les fichiers avant de valider les changements.

puis l’habituel git commit -m "Initial commit"

et notre git push :

git push --set-upstream origin main :

Élément	Rôle
`git push`	Envoie les commits locaux vers le dépôt distant.
`--set-upstream origin main`	Lie la branche locale `main` à la branche distante `origin/main`.

Crée la branche main sur GitLab (si elle n’existe pas encore).
Configure le lien de suivi : les futurs git push / git pull sauront où aller automatiquement.

Résultat attendu :

Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.24 KiB | 1.24 MiB/s, done.
Branch 'main' set up to track remote branch 'main' from 'origin'.

Après avoir écrit votre fichier gitlab-ci.yml dans le répertoire de votre projet :

Il y a volontairement une erreur dans les commandes du unit-test-job pour provoquer un arrêt du pipeline

stages:          # Liste des étapes (stages) avec les "jobs"
  - build
  - test
  - deploy

# Ce "job" est associé au stage "build", il est lancé en premier
build-job:
  stage: build
  script:
    - echo "Compilation du code..."
    - echo "Compilation complete."

# Ce "job" est associé au stage "test"
unit-test-job:
  stage: test    # Il démarre seulement lorsque le job du "build" est "successful" !
  script:
    - echos "Lancement des tests unitaires... ça prend 30 secondes, patientez"
    - sleep 30
    - echos "Code est couvert à 90%"

# Ce "job" est aussi associé au stage "test"
lint-test-job:   
  stage: test    # Il se lancera en même temps que le "unit-test-job" (en parallèle).
  script:
    - echo "Linter du code... amélioration du code (statique) avec une durée de 10 secondes"
    - sleep 10
    - echo "Pas de code à améliorer ;)"

# Ce "job" est associé au stage "deploy".
deploy-job:      
  stage: deploy  # Il sera lancé uniquement si les 2 jobs du stage "test" sont OK.
  environment: production
  script:
    - echo "Deploiement de l'application..."
    - echo "Votre application est déployée avec succès, youpi !"

Voici notre pipeline en cours d’éxécution :

alt text

Vous constatez bien un arrêt du processus sur le unit-test-job qui est Failed jobsdu stage test

alt text

Il vous suffit de cliquer sur le job concerné pour arriver sur les logs d’exécution et constater d’où vient l’erreur :

alt text

Vous allez sur “Pipeline editor”

alt text

et vous corrigez les 2 erreurs dans les commandes :

alt text

Vous faites un commit et le pipeline est relancé ! Et voyons le résultat :

alt text

Tout est OK ! Pensez à faire un git pull depuis votre machine.

TP Bonus — Salut CI (bash)

But : déclencher un pipeline et voir les logs.

Fichiers .gitlab-ci.yml

stages:
  - salut

hello-message:
  stage: salut
  script:
    - echo "Salut depuis GitLab CI"
    - uname -a
    - ls -la

Validation : pipeline vert, logs avec “Salut depuis GitLab CI” et Linux.

Bonus : ajouter rules: pour ne lancer que sur un push.

rules:
  - if: '$CI_PIPELINE_SOURCE == "push"'

Pour les Rules et les Tags, on verra cela dans un autre cours/tp.