Administration Système et Devops – TP 5

Prise en main de GitLab et sa CI

2025-2026

Responsable : Philippe SWARTVAGHER prenom.nom [at] enseirb-matmeca.fr
Intervenant : Tom CLAUDEL prenom.nom [at] u-bordeaux.fr

1. GitLab

Rendez-vous sur https://gitlab.bordeaux-inp.fr.
- Dans le formulaire “LDAP Bordeaux INP”, saisissez vos identifiants du CAS de Bordeaux INP. Votre compte sera automatiquement créé.
Configurez SSH :
- Créez une clé SSH en lui mettant une passphrase
- Ajoutez la clé publique créée au fichier $HOME/.ssh/authorized_keys.
- Pour éviter de dévoir saisir votre passphrase à chaque utilisation de votre clé, ajoutez votre clé à l’agent SSH :
```
# Commencer pas tester si l'agent est lancé :
ssh-add -l
# S'il se plaint qu'il n'a pas pu se connecter à l'agent :
eval "$(ssh-agent)"
# Ajoutez votre clé à l'agent :
ssh-add ~/.ssh/votre_cle_privee
```
- ssh ssh.enseirb-matmeca.fr doit fonctionner (quittez le shell obtenu)
- Configurez dans $HOME/.ssh/config un pont SSH, qui dit que lorsqu’on souhaite se connecter en SSH à gitlab.bordeaux-inp.fr, il faut faire passer la connexion par ssh.enseirb-matmeca.fr :
```
Host ssh.enseirb-matmeca.fr
   IdentityFile ~/.ssh/votre_cle_privee

Host gitlab.bordeaux-inp.fr
   ProxyJump ssh.enseirb-matmeca.fr
```
- Dans la configuration de votre compte GitLab, ajoutez votre clé SSH publique (le rond de votre profil tout en haut à droite, Préférences, Clés SSH, Ajouter une nouvelle clé).
En utilisant le bouton “+” en haut à droite, créez un “Nouveau projet/dépôt”.
- Créez un projet vide.
- Nommez le projet login-matrixeirb (en remplaçant login par votre login ; la présence du login dans le nom du projet nous aidera pour tard)
- Placez le projet dans votre groupe personnel.
- Laissez la visibilité du projet en “Interne”.
Clonez le dépôt avec SSH.
Remplacez le contenu initial du dépôt par les fichiers contenus dans cette archive.
Committez et pushez.
Depuis GitLab, créez un ticket pour demander de corriger le titre du fichier README.md par votre login.
Faites un commit qui corrige le titre en utilisant la syntaxe pour fermer automatiquement le ticket.
- Pushez, constatez que le ticket a été automatiquement marqué comme résolu.

2. Parenthèse sur la gestion des dépendances et les tests

Pas spécifique à Python : PHP, JavaScript, Java, Ruby, Rust, Go, … (mais pas universel non plus).

Utilisation d’un “environnement virtuel” pour installer les dépendances et ne pas polluer le système.
- Contenu de l’environnement virtuel à ne pas committer !
Les dépendances requises ainsi que leurs versions sont indiquées dans un fichier dédiées (requirements.txt en Python, Cargo.toml en Rust, package.json en JavaScript, Gemfile en Ruby, …).

En suivant les instructions dans le fichier README.md, créez l’environnement virtuel, installez les dépendances et exécutez le script d’exemple fourni.
Observez comment sont écrits les tests et lancez-les.

3. Contribution à un dépôt par des merge requests

À faire en binôme : A va contribuer au dépôt de B.

A clone le dépôt de B.
Depuis l’interface web, A forke le dépôt de B
- Sur la page du dépôt de B, bouton “Créer une bifurcation” en haut à droite.
A ajoute comme remote à son dépôt cloné le fork réalisé à l’étape précédente.
- cf le cours pour la commande à utiliser
A crée une branche (et bascule dessus) pour ajouter la multiplication de matrice par un scalaire :
- A ajoute dans matrixeirb.py la fonction pour multiplier la matrice par un scalaire en faisant une typo à un endroit (et sans ajouter de test, si jamais cette – bonne – idée vous traverserait l’esprit).
- A committe cet ajout.
- A pushe la nouvelle branche vers son fork.
Depuis l’interface web, A crée maintenant une Merge Request vers le dépôt de B.
- En rechargeant l’interface web, un bandeau le suggère directement.
B passe en revue la merge request et laisse un commentaire (sur le code) pour demander la modification de la typo.
A corrige la typo. Deux possibilités :
- Faire un nouveau commit, il suffit de le pusher (plus besoin de préciser vers quel remote).
- Corriger le commit précédent (git commit --amend), mais dans ce cas il faut forcer le push (pourquoi ? git push -f ; plus besoin de préciser vers quel remote).
Pendant ce temps, B pushe un commit vers son dépôt qui modifie le fichier README.md.
La branche de A n’est donc plus à jour : elle a comme point de départ un ancien commit. Deux possibilités :
- Faire un commit de fusion lors de la fusion de la merge request.
- Faire repartir la branche du dernier commit de la branche main du dépôt upstream en faisant un rebase. Attention, cela modifie forcément les commits (pourquoi ?) et nécessite donc un force-push.
- Dans tous les cas, il faut commencer par revenir sur la branche main, la mettre à jour avec le dépôt upstream et ensuite mettre à jour la branche selon la méthode choisie.
B accepte la merge request de A.
- A et B mettent à jour leur dépôt cloné.

Note : une autre façon de contribuer à un dépôt et que le propriétaire du dépôt nous ajoute comme membre du dépôt.

4. Mise en place de la CI

Individuellement sur son propre dépôt :

Ajoutez le fichier .gitlab-ci.yml à la racine de votre dépôt avec le contenu suivant :
```
tests:
  image: python:3.14

  script:
    - python -V
    - pip install -r requirements.txt # pas besoin d'environnement virtuel ici
    - # à completer pour exécuter les tests
```
- Le fichier doit s’appeler .gitlab-ci.yml.
- Quelles sont les instructions données dans ce script ? La documentation des mots-clés est ici.
- Complétez le script pour exécuter les tests.
Committez, pushez : explorez dans l’interface web comment la CI est exécutée.
Faites un commit qui casse les tests, committez, pushez : observez comment la CI échoue.

On reprend en binôme :

A fait une merge request pour réparer le dépôt.
- Ne pas oublier de commencer par mettre à jour son clone avec upstream (pour récupérer le dernier commit, celui qui casse les tests).
- Observez comment la CI est exécutée sur la merge request.
B accepte la merge request.

5. Un pipeline de CI avec plusieurs jobs

Individuellement sur son propre dépôt :

Mettez en place Black pour votre projet pour faire respecter le style de code.
Ajoutez à la CI un job qui exécute black. Ce job sera différent du job qui exécute les tests.
Committez, pushez : observez comment la CI exécute ce pipeline avec deux jobs.

6. Génération de la documentation sous forme de site web

Mettez en place Sphinx pour générer la documentation de votre projet :

sphinx-quickstart doc
> Séparer les répertoires source et de sortie (y/n) [n]: y
> Nom du projet: MatrixEirb
> Nom(s) de(s) l'auteur(s): Toto
> Version du projet []: 0.0.1
> Langue du projet [en]: fr

Construisez la documentation :

sphinx-build -M html doc/source/ doc/build/

Ajoutez des docstrings aux deux fonctions du fichier matrixeirb.py.
Ajoutez à la fin du fichier doc/source/index.rst (fichier au format reStructuredText) :
```
.. automodule:: matrixeirb
   :members:
```

Modifiez le fichier doc/source/conf.py pour qu’il contienne :

import sys
from pathlib import Path

sys.path.insert(0, str(Path(__file__).resolve().parents[2]))  # indique où trouver les modules à documenter

extensions = ['sphinx.ext.autosummary']  # permet de lister automatiquement les fonctions et modules à documenter

Reconstruisez la documentation et affichez-la.

Ajoutez un job à la CI pour générer la documentation et la rendre disponible à l’adresse https://login.pages.bordeaux-inp.fr/login-pymatrix/
- GitLab déploie comme site web ce qui se trouve dans le dossier public/ de l’artefact du job. On va donc dire qu’il faut conserver comme artefact le contenu de ce dossier :
```
 artifacts:
    paths:
       - public
```

7. Mesure du taux de couverture des tests

Mettez en place coveragepy pour mesurer le taux de couverture des test.
Modifiez la CI pour que le taux de couverture y soit mesuré et que GitLab puisse récupérer cette valeur (cherchez la clé coverage).
Ajoutez à votre README le badge qui indique l’état de la CI et le taux de couverture.
Ajoutez un test qui couvre la fonction que vous avez rajouté, et constatez que votre taux de couverture augmente.