Que se passe-t-il après que GitLab a téléchargé le code?

Après que GitLab télécharge le code du dépôt dans le répertoire de travail, l'exécution du pipeline CI/CD défini dans le fichier .gitlab-ci.yml commence.

1. Analyse de .gitlab-ci.yml : GitLab Runner (ou GitLab lui-même, si CI intégré) lit la configuration depuis .gitlab-ci.yml. Ce fichier décrit les étapes (stages) et les tâches (jobs) du pipeline.
2. Initialisation du Runner : Un GitLab Runner disponible est assigné pour exécuter le pipeline. Le Runner obtient des informations sur le dépôt, le commit, la branche et la configuration de .gitlab-ci.yml.
3. Création de l'environnement d'exécution : Le Runner prépare un environnement pour exécuter les tâches. Cela peut être :
   • Machine virtuelle
   • Conteneur (Docker, Kubernetes)
   • Serveur dédié
   • Shell
4. Exécution des étapes (stages) : Le pipeline s'exécute séquentiellement par étapes, définies dans .gitlab-ci.yml. Les tâches dans une même étape peuvent s'exécuter en parallèle.
5. Exécution des tâches (jobs) : À l'intérieur de chaque étape, les tâches configurées sont exécutées. La tâche inclut :
   • Définition de l'image ou de l'exécuteur (executor), si non défini au niveau du pipeline ou de la section variables.
   • Clonage du dépôt (déjà effectué par GitLab, mais le Runner peut effectuer git fetch ou git checkout pour l'état nécessaire).
   • Restauration du cache (si configuré) pour accélérer la compilation (par exemple, chargement des dépendances).
   • Exécution des scripts (script) : C'est le contenu principal de la tâche, où sont exécutées des commandes de compilation, test, analyse ou déploiement.
   • Chargement des artefacts (si configuré) : Les résultats de la tâche (par exemple, binaires compilés, rapports) sont sauvegardés pour une utilisation ou un téléchargement ultérieur.
   • Sauvegarde du cache (si configuré) : Pour accélérer les exécutions futures.
6. Rapport de statut : Le Runner envoie le statut de chaque tâche (succès, erreur, annulation) de retour à GitLab. L'utilisateur voit la progression et les résultats sur la page du pipeline.
7. Passage à l'étape suivante : Si toutes les tâches de l'étape en cours se terminent avec succès (ou si allow_failure est configuré), la prochaine étape commence. Si une tâche se termine par une erreur et que allow_failure n'est pas défini, tout le pipeline est interrompu.
8. Fin du pipeline : Après l'exécution de toutes les étapes (ou en cas d'erreur), le pipeline se termine. Les résultats et artefacts sont accessibles via l'interface web de GitLab.

Exemple de structure de /.gitlab-ci.yml` :

// Définition des étapes du pipeline
stages:
  - build
  - test
  - deploy

// Tâche de build dans l'étape build
build_job:
  stage: build
  image: docker:latest // Utilisation d'une image Docker
  script:
    - echo "Construction de l'application..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Construction de l'image Docker
  artifacts:
    paths:
      - myapp.tar // Sauvegarde de l'artefact de build

// Tâche de test dans l'étape test
test_job:
  stage: test
  image: python:3.9 // Utilisation d'une image Python
  script:
    - echo "Exécution des tests..."
    - pip install -r requirements.txt
    - pytest // Exécution des tests
  needs: ["build_job"] // Dépend du succès de build_job

// Tâche de déploiement dans l'étape deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // Utilisation d'une image Ubuntu
  script:
    - echo "Déploiement de l'application..."
    - echo "Script de déploiement ici..." // Script de déploiement
  only: // Exécution uniquement pour les commits sur master ou tags
    - master
    - tags
  needs: ["test_job"] // Dépend du succès de test_job

Ainsi, le téléchargement du code n'est que la première étape, suivie d'un processus complexe de compilation, test et déploiement automatisés, basé sur la configuration .gitlab-ci.yml.