flowchart github[(Remote)] dev1[(Local 1)] dev2[(Local 2)] github <--> dev1 github <--> dev2
Git TP
Les consignes de ce TP sont données pour une utilisation de GitHub.
Il est possible de réaliser ce TP avec GitLab dont l’interface est très ressemblante.
⚠️ Il y a tout de même quelques différences, par exemple : GitHub Repository = GitLab Projet
À faire à la maison
-
- GitHub > Sign up
- ou avec ce lien direct
Lors de la création de compte, si vous utilisez votre adresse mail ENSAI, nous vous conseillons d’ajouter un mail personnel :
- GitHub > Settings ⚙️ > Email (lien direct)
Comme vous ne serez pas étudiant toute votre vie, cela vous évitera de perdre votre accès par la suite.
Introduction
Git est un formidable outil de versionnage de fichiers qui va vous permettre de conserver efficacement l’historique de votre code aussi bien si vous travaillez seul mais également quand vous travaillez à plusieurs.
Cet historique est conservé dans ce que l’on appelle un dépôt git.
Sa conception décentralisée fait qu’il est quasi impossible de perdre une donnée définitivement avec git. En particulier, la perte totale d’un ordinateur hébergeant votre code ne représentera qu’une perte minime de code si vous utilisez git correctement.
En outre, de nombreux outils de CI/CD (Continuous Intégration / Continuous Deployment) qui rendent possible l’automatisation de l’intégration et du déploiement de votre code s’appuient sur un dépôt git.
Concepts Clés
Comme tout logiciel, git demande un peu d’apprentissage, et de la pratique.
Pour commencer, nous aurons besoin de certains concepts essentiels pour une utilisation efficace. Par sa conception décentralisée, un dépôt git peut exister en plusieurs endroits en même temps :
- sur notre machine
- sur chaque machine des membre du projet
- ou sur un serveur hébergeant le projet
Nous parlerons de la copie distante (remote en anglais) du dépôt dans le cas du serveur distant. En général, une seule copie distante est utilisée, mais par sa nature décentralisée, plusieurs copies distantes sont possibles (possibilité non incluse dans ce TP).
La copie sur notre machine est la copie locale (local en anglais). Il s’agit de toutes les informations du dépôt concernant l’historique de ses fichiers, et les métadonnées du dépôt. Une distinction subtile est alors faite entre la copie locale et la copie de travail (working copy en anglais) : nos modifications sur les fichiers du dépôt n’intégrerons la copie locale qu’à notre demande explicite. Cette intégration sera alors effectuée par l’ajout d’une entrée à l’historique du dépôt.
Programme
Dans ce TP, nous allons créer un dépôt distant et deux dépôt locaux. Ensuite nous allons les faire évoluer et les synchroniser.
Pour utiliser git, donc pour gérer un dépôt, nous avons accès à de nombreuses commandes. Pour ce TP de découverte, les commandes suivantes suffiront :
Commande | Description |
---|---|
git clone <url> |
Créer un dépôt local sur son poste |
git status |
Voir où l’on en est |
git add <file> |
Ajouter pour le prochain commit |
git commit -m "<msg>" |
Créer un point de sauvegarde |
git pull |
dépôt local ➡️ dépôt distant |
git push |
dépôt local ⬅️ dépôt distant |
1 Environnement de travail
Les commandes seront saisies dans un terminal Git Bash.
Vous allez utiliser un service Vscode-python du datalab. Celui-ci inclus Git Bash.
-
- https://onyxia.lab.groupe-genes.fr/
- https://datalab.sspcloud.fr/ (create an account using
firstname.lastname@eleve.ensai.fr
)
Durant ce TP, vous allez transférer du code entre votre dépôt local (service VSCode) et votre dépôt distant (sur GitHub). Pour valider ces transfert un processus d’authentification est naturellement requis.
1.1 Génération d’un Token
Ce paramétrage n’est à faire qu’une seule fois, jusqu’à expiration du jeton.
- Générer un jeton sur GitHub
- Déclarer ce jeton sur le datalab
Ainsi, à chaque fois que vous lancerez un service du datalab :
- Le jeton sera injecté dans une variable d’environnement
- vous pourrez donc le récupérer et l’utiliser pour communiquer avec GitHub de manière sécurisée
-
- pour créer un nouveau token classic
- Note: for ENSAI datalabs
- Expiration: 30/06/2026
- cochez repo and workflow
Attention sa valeur ne sera affichée qu’une seule fois. En cas de perte, il faut le supprimer et en recréer un nouveau.
Nous allons maintenant déclarer ce jeton sur votre compte du datalab.
1.2 Déclaration du Token au Datalab
Ce jeton est maintenant accessible dans la plupart des services du datalab (VSCode, Jupyter, RStudio…) Vous pourrez alors l’utiliser pour communiquer avec vos dépôts GitHub.
Aujourd’hui nous allons utiliser un service VSCode. Ce logiciel sera utilisé pour la majorité des cours d’informatique de l’ENSAI.
C’est un IDE (Integrated Development Environment) i.e. une application qui offre des outils complets pour le développement logiciel (éditeur de Code, compilateur / interpréteur, gestionnaire de projet, terminal Intégré, nombreuses extensions…)
N’oubliez pas de supprimer votre service !
Rappel sur le principe des datalabs :
- Des ressources sont à disposition de tous
- Un service lancé = des ressources réservées (cpu, ram, Go…)
Une fois votre travail terminé :
- sauvegardez votre code : envoi au remote avec git
- exportez vos résultats : par exemple en utilisant le stockage S3
- libérez ces ressources : supprimez vos service
-
- 3 petits traits horizontaux > Terminal > New
- ou CTRL + ù
2 Git Bash et Unix
Avant de nous lancer avec git, prenons quelques minutes pour découvrir le terminal Git Bash et les principales commandes Unix.
En tant qu’ingénieur, cela vous sera sans doute utile un jour.
Pour vous aider, voici la liste des commandes principales.
2.1 Un terminal ?
Un terminal est une interface texte qui permet de donner des commandes à l’ordinateur.
C’est une alternative à la souris pour naviguer, créer des fichiers, lancer des programmes.
Git Bash est un terminal qui :
- émule un environnement type Linux/Unix
- inclus les commandes Git
Le terminal, c’est sobre, c’est rapide, c’est efficace.
Le terminal reste un outil très utilisé en informatique, même à l’ère du tout clic-bouton. Il permet d’aller droit au but sans passer par des menus parfois longs et compliqués.
Rapide et léger, il s’adapte aussi bien aux petites tâches qu’aux opérations plus techniques.
Les développeurs et administrateurs l’utilisent au quotidien pour automatiser et gagner du temps.
2.2 Démystifions la bête
Dans le terminal, vous avez :
- un prompt (username, host, folder)
- vous êtes connecté avec l’utilisateur onyxia sur la machine virutelle vscode-python-345194-0
- vous êtes positionné dans le dossier
~/work
(~ est le dossier personnel de l’utilisateur) - il se termine par un
$
- à côté, vous pouvez écrire une commande
- en dessous, vous avez le résultat de la commande
- à droite, vous avez vos terminaux (c’est possible d’en ouvrir plusieurs)
2.3 Premières commandes
Commençons par quelques commandes simples :
2.4 Fichiers
Faisons maintenant quelques manipulations sur des fichiers :
-
- env : liste des variables d’environnement
env > a.txt
-
cat b.txt | grep GIT
Vous devriez retrouver ici votre token. Les variables d’environnement sont un système clé-valeur, pour récupérer votre jeton :
- Les flèches ⬆️ et ⬇️ pour naviguer dans l’historique des dernières commandes et éviter de retaper 10 fois la même commande
- TAB pour l’autocomplétion
- Tapez
cat b
, puis appuyez sur la touche TAB - Il n’y a qu’un seul fichier commençant par b donc l’autocomplétion s’effectue
- La touche TAB se situe à gauche du clavier dessous
²
et dessus 🔒
- Tapez
3 Dépôts Git
Passons maintenant au thème central de ce TP : Git et la synchronisation des dépôts.
Avant de se lancer, exécutez ces deux commandes qui vous éviterons peut-être d’être bloqué par la suite :
git config --global core.editor "code-server --wait"
Cette commande définit l’éditeur de texte que Git utilisera par défaut pour les opérations nécessitant l’édition d’un message, comme les commits, les tags ou la résolution de conflits de fusion (merge).
git config
: La commande de base pour obtenir et définir les options de configuration de Git.--global
: Indique que le paramètre est appliqué à tous les dépôts Git de l’utilisateur sur la machine actuelle. La configuration est stockée dans le fichier~/.gitconfig
.core.editor
: La variable de configuration spécifique qui détermine l’éditeur."code-server --wait"
: La valeur définie pour l’éditeur.code-server
: C’est une version de Visual Studio Code (VS Code) fonctionnant dans un navigateur sur un serveur distant, ce qui est souvent utilisé dans les environnements de développement cloud.--wait
: Cet argument est crucial. Il indique à Git de patienter jusqu’à ce que l’éditeur (code-server
) soit fermé avant de continuer l’opération Git. Par exemple, lorsque vous faites ungit commit
, VS Code s’ouvre, vous éditez le message, vous fermez l’éditeur, et seulement à ce moment-là Git finalise le commit.
Elle configure VS Code comme l’éditeur par défaut pour Git à la place de Nano.
git config --global core.mergeoptions --no-edit
Cette commande modifie les options par défaut utilisées lors de la fusion de branches (git merge
).
git config
: La commande de base de configuration.--global
: Applique le paramètre à tous les dépôts de l’utilisateur.core.mergeoptions
: La variable de configuration qui permet de définir des options par défaut pour la commandegit merge
.--no-edit
: L’option ajoutée.- Lors d’une fusion réussie (sans conflit), Git génère un message de commit de fusion par défaut. Normalement, Git ouvre l’éditeur (
core.editor
) pour vous permettre de modifier ce message. - L’option
--no-edit
désactive l’ouverture automatique de l’éditeur pour la modification du message de commit de fusion. Git utilisera le message de commit de fusion par défaut sans intervention de l’utilisateur.
- Lors d’une fusion réussie (sans conflit), Git génère un message de commit de fusion par défaut. Normalement, Git ouvre l’éditeur (
Elle configure Git pour qu’il n’ouvre pas l’éditeur de texte lors d’une fusion réussie, utilisant directement le message de commit de fusion par défaut.
Commençons par créer un remote sur GitHub.
3.1 Créez un dépôt distant
-
- GitHub > Repositories >
- Repository name : tp-git
- Visibility Level : Private
- Cochez Add a README file
- Add .gitignore : Python
- Choose a license : MIT Licence
- Cliquez sur
Votre remote est maintenant créé.
Dans le cadre de ce TP, il est interdit d’éditer des fichiers directement sur GitHub. Ce n’est pas une bonne pratique.
Toutes les modifications doivent être faites sur votre clone local et ensuite envoyées vers GitHub.
3.2 Privé, public ?
Vous avez déclaré votre dépôt Privé. C’est adapté dans ce cas, car nous sommes dans le cadre d’un exercice où l’idée n’est pas de faire du code propre mais de pratiquer.
À l’inverse, n’hésitez pas à déclarer public vos travaux aboutis, non confidentiels.
Critère | Dépôt Public | Dépôt Privé |
---|---|---|
Visibilité | Tout le monde peut voir | Uniquement les personnes invitées |
Collaboration externe | Ouvertes (issues, forks, PR) | Restreinte à l’équipe |
Confidentialité | Aucune, tout est visible | Sécurisé, accès contrôlé |
Usage typique | Projets Open Source, propres, aboutis | Travaux privés, sandbox |
Que le dépôt soit public ou privé, vous devez faire parti des collaborateurs pour y contribuer. Dépôt public signifie que tout le monde peut le voir mais pas le modifier directement.
Pour autoriser des personnes à écrire sur votre dépôt vous devez les inviter :
- Sur la page du repo > Settings > Collaborators > Add people
3.3 Créez un dépôt local
Vous allez maintenant créer une copie locale du remote en le clonant.
Sur la page GitHub de votre repo :
Vous obtenez une url de ce type : https://github.com/<username>/tp-git.git
-
https://$GIT_PERSONAL_ACCESS_TOKEN@github.com/<username>/tp-git.git
Dans le terminal Git Bash de VSCode :
-
git clone <url ci-dessus>
-
- Normalement, le dossier tp-git est apparu
- C’est le clone du repo que vous venez de créer
Vous êtes maintenant dans un repo git, vous pouvez donc exécuter des commandes git !
-
git remote -v
- Vous devez voir ici votre token et l’url du remote
4 Premiers pas
Dans ce dépôt local, vous allez commencer par créer de nouveaux dossiers et fichiers sur votre dépôt local.
-
touch src/voiture.py
voiture.py
class Voiture:
"""Classe représentant une voiture.
Attributes
----------
nom : str
le nom de la voiture.
couleur : str
la couleur de la voiture.
vitesse : int
la vitesse de la voiture (initalisée à 0).
"""
def __init__(self, nom, couleur):
"""Constructeur"""
self.nom = nom
self.couleur = couleur
self.vitesse = 0
def __str__(self):
return f"La voiture {self.nom} de couleur {self.couleur} roule à {self.vitesse} km/h."
Vous venez de créez quelques nouveaux éléments sur votre clone, envoyons-les maintenant au remote.
4.1 Add, Commit et Push
C’est l’enchainement de commandes qu’il faut connaitre ! (avec une pincée de status si besoin)
Avant de commencer, vérifiez dans votre terminal que vous êtes bien positionné à la racine de votre dépôt i.e. votre dossier courant est tp-git.
Dans le terminal Git Bash, exécutez les commandes suivantes :
-
- différences entre la version de travail du code et le commit le plus récent
- le dossier src apparait dans Untracked files
- cela signifie que Git a repéré ce dossier mais qu’il ne le versionnera pas
-
- pour faire reconnaitre ce dossier et le placer la zone de transit
- ce dossier et ses fichiers seront versionnés dans le prochain commit
-
- Changes to be committed : new file: src/voiture.py
- le fichier est maintenant reconnu par Git
Nous allons maintenant créer un point de sauvegarde :
-
- entre les guillemets, mettez un message court et explicite. Ce message est obligatoire !
-
- Your branch is ahead of ‘origin/main’ by 1 commit
- i.e. votre dépôt local est en avance d’un commit par rapport au remote
Enfin, nous souhaitons envoyer notre commit vers le remote.
-
- pousse vos commits vers le dépôt distant.
- ⚠️ si vous avez modifié des fichiers qui ne sont pas dans un commit, ces modifications n’apparaitront pas sur le dépôt distant
Allez sur la page GitHub de votre repo et vérifiez que vos fichiers sont bien arrivés.
Vous avez tout bien fait mais votre fichier voiture.py n’est pas à jour sur GitHub. 😕
- est-ce que votre fichier voiture.py a bien été enregistré ?
- sinon recommencez (Add, Commit, Pull et Push). 😩
- Est-ce que vous êtes bien connecté au remote avec votre token ?
git remote -v
pour vérifiergit remote set-url origin https://$GIT_PERSONAL_ACCESS_TOKEN@github.com/<username>/tp-git.git
Pour résumer voilà ce que vous avez fait :
sequenceDiagram Workspace ->> Staging index: add Staging index ->> Local repository: commit Local repository ->> Remote repository: push Remote repository ->> Workspace: pull
Retournez sur VSCode :
voiture.py
def accelere(self, increment):
"""Augmente la vitesse de la voiture.
L'incrément maximal est de 10 km/h.
La Vitesse maximale est de 130 km/h.
Parameters
----------
increment : int
la valeur de l'accélération demandée (limité à 10)
"""
if increment > 10:
= 10
increment self.vitesse = min(130, self.vitesse + increment)
Dans le terminal Git Bash :
-
- le fichier voiture.py a été modifié
-
- q pour quitter
4.2 Historique du dépôt
Pour accéder à l’historique d’un repo :
-
- en cliquant sur Commit (en dessous du bouton )
- historique d’un fichier en ouvrant ce fichier et en cliquant sur History
-
- ce n’est pas aisément lisible
- heureusement il est possible d’améliorer cette commande
git log --pretty=format:'%C(yellow)%h %C(green)%ad %C(blue)%an%C(green)%d %Creset%s' --date=relative
- chaque ligne représente un commit
- la première colonne correspond au numéro court de commit
- vous remarquez un décalage entre HEAD et origin/HEAD (entre dépôt local et distant)
- HEAD : pointeur qui représente la version actuelle du code dans votre espace de travail
- main (ou master) : nom de la branche principale par défaut
- origin : désigne le dépôt distant
- q pour quitter
Ce n’est pas évident de se souvenir de commandes aussi longues.
Une solution est de créer un alias :
-
git config --global alias.blog "log --pretty=format:'%C(yellow)%h %C(green)%ad %C(blue)%an%C(green)%d %Creset%s' --date=relative"
-
- les 2 dépôts sont de nouveau synchronisés
4.3 Exercice d’application
C’est le moment d’appliquer ce que nous venons de voir, à vous :
test_voiture.py
from voiture import Voiture
class TestVoiture:
def test_accelere_incremente_vitesse():
# GIVEN
= Voiture("4L", "verte")
v
# WHEN
5)
v.accelere(
# THEN
assert v.vitesse == 5
def test_accelere_limite_increment():
# GIVEN
= Voiture("4L", "verte")
v
# WHEN
20)
v.accelere(
# THEN
assert v.vitesse == 10
-
- c’est le nom standard du fichier qui liste les packages python nécessaires au projet
requirements.txt
pylint pytest
4.4 Le fichier .gitignore
Certains fichiers ont vocation à rester seulement sur votre dépôt local, par exemple :
- fichiers de données
- fichiers contenant des mots de passe
- fichiers de logs
Grâce au .gitignore, vous pouvez dire à Git d’ignorer certains fichiers.
joueuses.csv
id_joueuse,nom,prenom,date_naissance,pays
1,Sebag,Marie,1986-10-15,France
2,Polgar,Judit,1976-07-23,Hongrie
3,Hou,Yifan,1994-02-27,Chine
4,Kosteniuk,Alexandra,1984-04-23,Suisse 5,Ju,Wenjun,1991-01-31,Chine
-
- le dossier data apparait dans les Untracked files
-
- le dossier data n’apparait plus, car maintenant Git ignore ce dossier et son contenu
- il est bien présent dans votre dépôt local mais il n’arrivera donc jamais sur le dépôt distant
Autre exemple : lors du projet info de 2e année, votre application python se connectera à une base de données. Or les infos de connexions à cette bdd ne devront pas atterrir sur GitHub !
5 Simulation de travail en groupe
Pour les questions suivantes, vous allez avoir besoin de 2 dépôts locaux branchés sur un même dépôt distant. Il y a 2 possibilités :
- soit vous travaillez en bînome (vous avez chacun votre dépôt local)
- soit vous faîtes seul (mais vous gérez 2 dépôts locaux différents)
5.1 Mise en place des clones
Un des deux membres va créer un dépôt local à partir du dépôt distant de l’autre.
-
- page GitHub du repo > Settings > Collaborators
-
cd /home/onyxia/work/clone2
git clone https://$GIT_PERSONAL_ACCESS_TOKEN@github.com/<username_frog>/tp-git.git
cd tp-git
pour entrer dans le dépôt Git
-
- n’oubliez pas d’inclure votre token
Vous allez ainsi avoir deux clones dans votre service VSCode. Une autre alternative pour l’exercice serait de lancer un autre service VSCode-python et d’y créer un clone.
💡 Pour ne pas vous-y perdre, n’hésitez pas à renommer vos dossiers et vos terminaux.
5.2 Synchronisation des dépôts
Ici, un membre va coder et l’autre va devoir récupérer son code.
moto.py
class Moto:
def __init__(self, nom, couleur):
self.couleur = couleur
self.nom = nom
self.vitesse = 0
def accelere(self, increment):
if increment > 15:
= 15
increment self.vitesse = min(150, self.vitesse + increment)
-
- il récupére le fichier moto.py dans son dépôt local
-
- 🐱 crée un fichier velo.py et le pousse
- 🐸 le récupère
Nous allons maintenant illustrer le fait que votre dépôt local doit être impérativement à jour pour pousser du code.
5.3 Coder en équipe
Maintenant les deux membres vont coder en même temps mais sur des fichiers différents.
Attention : 1, 2, 3, partez 🏁
state-diag.md
```mermaid
stateDiagram
login : Se connecter
menu_joueur : Menu Joueur
logon : Créer un compte *] --> Accueil
[
Accueil --> login
login --> menu_joueur
Accueil --> logon
Accueil --> quitter*]
quitter --> [```
-
git add .
git commit -m "<complétez>"
git push
Pour 🐸 qui a poussé son code en premier ➡️ tout s’est bien passé
Pour 🐱, il a du recevoir ce genre de message lors du push
! [rejected] main -> dev (fetch first) error: failed to push some refs to 'git@github.com:ludo2ne/tp-git.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Si vous lisez le message, c’est assez clair :
- votre dépôt local est en retard de version par rapport au dépôt distant
- vous devez donc mettre à jour votre dépôt local avant de pousser
- il faut commencer par pull
Nous allons ajouter l’option rebase pour placer les commits locaux “par-dessus” ceux du remote pour obtenir un historique linéaire, clair et facile à suivre, tout en évitant les commits de fusion superflus.
Maintenant c’est 🐸 qui a son dépôt local en retard.
Exercice d’application :
5.4 Un premier conflit
Pour le moment vous avez travaillé sur des fichiers différents, donc git arrive à gérer la situation.
Maintenant, que se passe-t-il si vous modifiez tous les deux le même fichier ?
Vous allez tous les 2 travailler sur le fichier voiture.py
. Dans la méthode accelere() :
Si vous avez bien compris, vous savez que le push ne va pas fonctionner.
-
- Et là c’est le conflit…
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 1015 bytes | 8.00 KiB/s, done.
From github.com:ludo2ne/tp-git
c27c708..05380ea main -> origin/main
Auto-merging src/voiture.py
CONFLICT (content): Merge conflict in src/voiture.py Automatic merge failed; fix conflicts and then commit the result.
Git vous prévient qu’il n’est pas arrivé à fusionner les commits automatiquement
Un conflit est généré quand les mêmes lignes d’un fichier sont modifiés par 2 commits de manière différente. Il doit être géré sur un dépôt local.
Votre code ressemble à cela désormais à :
def accelere(self, increment) -> None:
if increment > 10:
= 10
increment <<<<<<< HEAD
self.vitesse = min(110, self.vitesse + increment)
=======
self.vitesse = min(150, self.vitesse + increment)
>>>>>>> 05380ea70dbd5d4e49371af8da7c0ac1df13a010
- La première partie (entre
<<<<<<< HEAD
et=======
) correspond au code en que vous aviez dans votre copie de travail - La seconde partie est le code provenant du dépôt distant
Plusieurs choix s’offrent à vous :
- Imposer votre version (110)
- Accepter la version de 🐱 (150)
- Choisir une toute autre version (par exemple 120)
Résolvons ce conflit :
-
- et supprime toutes les autres lignes de
<<<<<<<
à>>>>>>>
- autre possibilité offerte par VSCode, cliquer sur Accept Current Change
- et supprime toutes les autres lignes de
Avoir un conflit, ce n’est pas grave !
Avoir un conflit, ce n’est pas grave !
Avoir un conflit, ce n’est pas grave !
Avoir un conflit, ce n’est pas grave !
Avoir un conflit, ce n’est pas grave !
Conflit ≠ Erreur
Cela arrive simplement quand Git rencontre deux versions et il n’a pas de 🔮, ni de 🎲 pour choisir laquelle est la bonne.
- Essayez de ne pas coder en même temps sur les mêmes fichiers
- Faites des pull et push réguliers
Plus le code de votre dépôt local sera “proche” de celui du dépôt distant, moins vous en aurez.
En effet, si vous codez pendant 5 jours sans jamais pousser votre code, vous prenez le risque que d’autres personnes modifient les mêmes fichiers et poussent avant leur code.
5.5 Exercice d’application
Dans le constructeur de la classe Voiture :
-
voiture.py
def __init__(self, nom, couleur, vitesse_max=130): """Constructeur""" self.nom = nom self.couleur = couleur self.vitesse = 0 self.vitesse_max = vitesse_max
-
voiture.py
def __init__(self, nom, couleur, carburant): """Constructeur""" self.nom = nom self.couleur = couleur self.vitesse = 0 self.carburant = carburant
6 CI
L’intégration continue permet d’automatiser certaines tâches lorsque l’on pousse du code vers un remote, par exemple :
- compiler le projet ou générer un paquet
- lancer les tests unitaires avec pytest
- vérifier la qualité du code
Il existe également le Déploiement Continu (CD) qui va installer automatiquement le programme sur un serveur.
Il est possible de créer des pipelines automatisés pour mettre en place du CI/CD.
6.1 Notre premier pipeline
Nous allons créer un pipeline qui va exécuter sur une machine virtuelle vierge :
- installer ubuntu
- installer un environnement python
- installer les packages python nécessaires (requirements.txt)
et ensuite :
- lancer les tests unitaires
- lancer pylint, un outil pour évaluer la qualité du code
La fonctionnalité GitHub qui permet de faire cela se nomme GitHub actions. GitLab a un équivalent.
.github/workflows/ci.yml
name: pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.13"]
steps:
- uses: actions/checkout@v4
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Unit Tests with pytest
run: |
pytest
- name: Analysing the code with pylint
run: |
pylint --output-format=colorized --disable=C0114,C0411,C0415,W0718 $(git ls-files '*.py') --fail-under=7.5
-
- c’est important de respecter ces noms précis
Lors d’un push, cela va maintenant déclencher un pipeline sur GitHub.
Git sur la VM ENSAI
Optionnel
Si vous souhaitez gérer des dépôts locaux sur votre VM ENSAI, vous pouvez utiliser le paramétrage ci-dessous.
La communication avec GitHub se fera avec le protocole ssh
Configuration
setup-git.sh
git config --global user.name "<Prenom Nom>"
git config --global user.email <prenom.nom>@eleve.ensai.fr
git config --global credential.helper store
git config --global core.mergeoptions --no-edit
git config --global core.editor "code -w"
Création d’une clé SSH
Pour permettre de faire dialoguer notre dépôt local avec le dépôt distant de GitHub, vous utiliserez le protocole SSH
. Pour cela, vous allez :
- générer une paire de clés (publique/privée) sur notre machine
- déclarer votre clé publique à GitHub
Ce paramètrage SSH est réalisé au niveau de la machine.
Si par exemple, vous souhaitez utiliser Git sur votre ordinateur personnel, il faudra faire également ce paramétrage.
Dans Git Bash :
-
mkdir -p ~/.ssh
-
ssh-keygen -t rsa -b 4096 -N '' -q -f ~/.ssh/id_rsa
-
cat ~/.ssh/id_rsa.pub | clip
- c’est comme si vous copiez le contenu du fichier id_rsa.pub
Déclarez votre clé publique à GitHub, pour pouvoir ensuite faire communiquer dépôts locaux avec les dépôts distants :
-
- Title : VM ENSAI
- Key : Collez votre clé publique
SSH (Secure Shell) est un protocole permettant de se connecter à un autre ordinateur sur un réseau de manière sécurisée.
SSH chiffre toutes les informations échangées afin de protéger les données.
SSH utilise un mécanisme de clés cryptographiques pour authentifier les ordinateurs et les utilisateurs, garantissant que la connexion est effectuée avec le bon serveur et sans intervention malveillante :
Clé privée
: C’est comme la clé de votre maison. Vous la gardez en sécurité avec vous et ne la partagez avec personne. Cette clé reste sur votre ordinateur et sert à prouver votre identité.Clé publique
: Elle serait comme votre adresse postale. Vous pouvez la partager avec d’autres. Dans SSH, vous placez votre clé publique sur les serveurs ou les ordinateurs auxquels vous souhaitez vous connecter.
Ces deux clés sont liées. Un message chiffré par la clé publique n’est déchiffrable que par celui qui posséde la clé privée. Lorsque vous chiffrez un message avec votre clé privée, vous prouvez à tous votre identité car chacun peut déchiffrer ce message avec la clé publique.