Partie 1 · Bilan

Bilan

Reprenons le fil du cours : le développeur ne veut plus taper à la main les douze commandes de la leçon 1. Il décrit une fois la pipeline dans .gitlab-ci.yml, et GitLab exécute à chaque push les jobs, dans des conteneurs.

Question	Réponse du cours
Pourquoi le CI ?	détecter tôt, gagner du temps, tracer, collaborer
Pourquoi le CD ?	publier et déployer automatiquement (droits et validation fiables requis)
Qui exécute ?	pipeline > stages > jobs (dans un conteneur)
Que contrôle-t-on ?	tests unitaires, d'intégration, lint, SAST
Comment configure-t-on ?	.gitlab-ci.yml en YAML : stages, image, variables, jobs
Comment passer des fichiers ?	artifacts, needs, dependencies

Vérifie que tu as compris

Un job build produit un dossier de fichiers que le job test doit utiliser. Quelle combinaison est adaptée ?

Lire une pipeline

(Exemple ajouté.) Lis ce fichier : deux stages, trois jobs.

stages:
  - build
  - test

lint-job:
  stage: test
  script: black --check --diff

unit-job:
  stage: test
  script: pytest

package-job:
  stage: build
  script: docker build -t myapp:latest .

La pipeline lance d'abord le stage build (package-job), puis le stage test, où lint-job et unit-job sont dans le même stage.

Vérifie que tu as compris

Dans l'exemple ajouté, quels jobs appartiennent au stage test ?