Initial commit

.gitignore

+code/__pycache__
\ No newline at end of file

.gitlab-ci.yml

+image: "python:3.8"  # La pipeline doit se lancer dans un environnement avec python installé
+
+# before_script avant chaque Job (affichage de la version de Python et installation des dépendances)
+before_script:
+  - python --version
+  - pip install -r requirements.txt
+
+# On peut définir différents stages (étapes) dans la pipeline. Chaque stage peut avoir plusieurs job
+stages:
+  - Testing
+
+# Définition des Jobs
+pylint:
+  stage: Testing  # chaque Job est rattaché à une étape
+  script:  # Ce sont les commandes qui seront lancées et qui feront fail le job si une erreur est renvoyée
+    - pylint -d C0301 code/*.py
+
+unittest:
+  stage: Testing  # On crée 2 jobs en parallèle dans la même étape
+  script:
+    - python code/tests.py
\ No newline at end of file

README.md

+# TP: introduction à Git
+
+Bienvenu à toi, lecteur ! Ce TP a pour objectif de t'aider à prendre en main Git en mettant les mains dans le cambouis. Mais surtout pas de panique si tu n'as jamais utilisé Git ! Ce TP reprend tout de plus le début, mais a été pensé pour faire suite à une (courte) présentation théorique. Je te conseille de consulter les slides disponibles [ici]() avant de te lancer dans ce TP.
+
+## Prérequis
+
+Pour pouvoir faire ce TD, il te faudra le logiciel Git installé sur ton ordinateur : 
+* Si tu es sous Linux ou Mac, git est normalement déjà installé.
+* Si tu es sous Windows, je te conseille d'installer [GitBash](https://gitforwindows.org/). Tu peux aussi utiliser [WSL2](https://www.thomasmaurer.ch/2019/06/install-wsl-2-on-windows-10/) qui est plus complet mais un peu plus compliqué à installer.
+
+Ce TP va aussi utiliser l'éditeur de code [VSCode](https://code.visualstudio.com/). Je te conseille de l'utiliser aussi pour plus de clarté mais tu peux utiliser un autre éditeur de code.
+
+Maintenant que les prérequis sont installés, il est temps de se lancer !
+
+
+## Partie 0 : Configuration de Git et du Gitlab de ViaRézo
+
+Avant de pouvoir utiliser Git, il y a quelques configuration à faire.
+
+### Ajout d'un nom et email dans Git
+
+Pour que les modifications que tu feras sur le repository soient identifiables, il faut fournir un nom et une adresse email. Pour faire cette configuration, ouvre GitBash (ou un terminal pour Mac/Linux) et entre les commandes suivantes en remplaçant nom et adresse email :
+
+`git config --global user.name "<votre nom>"`
+
+`git config --global user.email "<votre adresse email>"`
+
+Git sait maintenant qui tu es et le nom choisi sera associé aux modifications que tu feras.
+
+### Paramètre de connexion au serveur Gitlab
+
+Lorsque l'on utilise Git, le code est stocké sur un serveur Gitlab. Dans ce TP, tu utiliseras le Gitlab de ViaRézo, accessible à [cette adresse](https://gitlab.viarezo.fr).
+
+Dans le cas où le projet Gitlab n'est pas public, il faudra s'authentifier. Gitlab propose deux manières de s'authentifier :
+* L'indentification par nom d'utilisateur/mot de passe. Par défaut, Gitlab demandera un identifiant (de la forme 2016vandammejc) et un mot de passe lorsque ce sera nécessaire.
+* Il n'est pas très confortable de devoir entrer à chaque fois identifiant et mot de passe. Il existe alors une deuxième méthode pour s'authentifier : le protocole ssh. Si cette solution t'intéresse, je t'invite à regarder l'encadré suivant pour la mettre en place.
+
+---
+**[?] Paramétrer l'authentification par clé ssh [?]**
+
+* Crée une clé ssh en suivant par exemple [ce tutoriel](https://inchoo.net/dev-talk/how-to-generate-ssh-keys-for-git-authorization/).
+* Ajoute ta clé dans ton profil Gitlab en te rendant dans `Settings` (disponibles après avoir cliqué sur le logo en haut à droite) puis `SSH Keys`.
+* Tu pourras maintenant t'authentifier via SSH.
+---
+
+Tout est maintenant configuré, on peut entrer dans le vif du suje !
+
+
+## Partie 1 : Fork et Repository
+
+La première étape est de créer un repo Git (c'est-à-dire un endroit pour mettre le code). Nous ne ferons pas comme dans les slides car on ne créeras pas de repo vide. Nous allons plutôt découvir une nouvelle opération : **le fork**.
+
+### Fork du projet formation
+
+---
+**Qu'est-ce que forker un projet ?**
+
+Lorsqu'un projet disponible en open source sur un Gitlab nous intéresse, on peut en créer une copie et travailler dessus. Ça évite de recommencer un projet de zéro. Il est important de noter que le forl est plus qu'une copie d'un projet puisque le projet source et le projet forkés sont toujours liés. Mais nous n'utiliserons pas ce lien dans ce TP.
+
+---
+
+C'est l'heure de créer ton premier fork. Rendez-vous sur [ce projet Gitlab]() pour en créer un fork :
+* Sur la page d'accueil du projet, clique sur ***Fork*** en haut à droite au-dessus de la liste des fichiers.
+* Il faut alors choisir un namespace (c'est à dire un endroit) où sera stocké le projet. Clique sur le bouton ***Select*** sous ton profil afin de créer un projet personnel.
+* Après un temps de chargement, ton projet personnel apparaît. Tu peux vérifier que c'est bien le train en regardant dans l'url. Il devrait y avoir ton nom d'utilisateur.
+* Comme tu viens de faire un fork, il est encore possible de faire des modifications sur ton projet et sur le projet original. Il faut donc désactiver cette option pour avoir un projet indépendant. Clique sur ***Settings*** dans la barre de gauche puis dans la sous-catégorie ***Advanced***, clique ***Remove fork relationship***. Confirme l'opération en entrant le nom du projet.
+
+Félicitations, tu as maintenant un projet indépendant dans lequel tu feras la suite du TP !! Il ne reste plus qu'à récupérer une copie local des fichiers.
+
+### Clone du repo
+
+* Sur la page d'accueil de ton projet, clique sur le bouton ***clone*** et copie le lien pour cloner avec `HTTPS` (**sauf si tu suivi l'étape pour paramétrer l'authentification par `SSH`**).
+
+* Ouvre un GitBash (Windows) ou un terminal (Mac et Linux) à l'endroit où tu veux enregistrer les fichiers du repo git.
+
+* Entre la commande `git clone <lien copié>`. Git va alors créer un dossier et téléchargement le contenu du projet sur le serveur. Tu as maintenant une copie locale du code !
+
+---
+**[!] Git a mémorisé un mauvais mot de passe [!]**
+
+Windows a mémorisé le mot de passe. Jette un oeil à [cette procédure](https://stackoverflow.com/questions/15381198/remove-credentials-from-git) pour le modifier.
+
+---
+
+## Partie 2 : Versionnage et Premiers commits
+
+Maintenant que tu as une copie locale des fichiers, tu peux commencer à les éditer localement (avant d'envoyer tes modifications sur le serveur). Pour cela, ouvre VSCode et fait ***File > Open Folder***. Sélectionne le dossier `formation-git` fraichement créé. Tu auras alors accès dans VScode à tous les fichiers du repo.
+
+### Mission 1 : Modifier un fichier
+
+Dans un repo git, l'édition des fichiers se fait comme dans un dossier classique. Mais cette modification en local doit ensuite être synchronisée avec le serveur.
+
+Voici-ci dessous une ligne moche et inutile. Sauras-tu la supprimer ?
+
+**Cette ligne est moche est inutile, supprime là !**
+
+Bravo pour avoir réussi à supprimer la ligne ! L'as-tu fait en ligne de commande ? Ou avec le module git intégré à VSCode ? Je t'encourage à essayer la méthode que tu n'as pas utilisée sur la deuxième ligne moche et inutile ci-dessous.
+
+**Cette ligne est aussi moche et inutile, supprime là !**
+
+Tu peux vérifier que les lignes du fichier ont bien disparu du repo distant via l'interface web de Gitlab. Attention à bien regarder sur ta copie personnelle du projet et pas sur le projet originel.
+
+Merci d'avoir pris le temps de nettoyer ce fichier en enlevant ces lignes en trop ! Tu peux passer à la mission suivante.
+
+### Mission 2 : Ajouter un fichier
+
+Ta deuxième mission est de créer un fichier `solutions.md` à la racine du repo et d'y ajouter les solutions à la mission précédente.
+
+---
+**Remarque**
+
+L'extension de fichier `.md` signifie *Markdown*. Ce format permet de faire un peu de mise en page simple de fichier texte dans un format qui peut être lu et affiché sur l'interface web de Gitlab. Tu peux t'aider de [ce site](https://www.markdownguide.org/cheat-sheet/) pour faire un peu de mise en page du fichier de solutions.
+
+---
+
+Une fois le fichier créé, n'oublie pas de le synchroniser avec le serveur Gitlab !
+
+### Mission 3 : Supprimer un fichier
+
+Dernière mission pour la route, il y a dans le repo un fichier nommé `fichier_inutile`. Sauras-tu le supprimer du repo Gitlab ?
+
+Tu peux vérifier que le fichier a bien disparu du repo distant via l'interface web de Gitlab.
+
+Les quelques commandes que tu viens d'utiliser (`git status`, `git add`, `git commit`, `git pull`, `git push`) sont les commandes que tu utiliseras 95% du temps.
+
+Je t'invite à aller voir le graphe du repo depuis l'interface web disponible dans ***Repository > Graph***. Tu peux y retrouver l'historique de tes commits. Note bien l'importance du message de commit clair qui permet de te souvenir de ce qui a changé entre chaque commit ! On vient bien ici que Git permet de versionner le code facilement. Mais qu'en est-il de la collaboration ?
+
+## Partie 3 : Collaboration, branches et merge requests
+
+Il n'est pas pratique d'éditer en même temps les fichiers car cela peut poser des problèmes de synchronisations sur le serveur. C'est pour répondre à cette problématique que le concept de branches a été introduit.
+
+Généralement, on ne veut garder sur la branche master que du code 100% fonctionnel. Pour développer une nouvelle fonctionnalité, il faut alors créer une branche.
+
+### Mission 1 : Créer une branche
+
+* Crée une branche et place toi sur cette nouvelle branche
+* Vérifie que cette branche est bien sélectionnée
+* Consulte le code python de `code/main.py`. Il remplace des mots courants par leur équivalent smiley.
+
+---
+**Je veux exécuter mon code en local mais j'ai une erreur de module**
+
+Il faut installer le module emoji avec la commande `python3 -m pip install -r requirements.txt`. Cette commande va installer tous les modules python listés dans le fichier `requirements.txt`.
+
+---
+
+* Complète le dictionnaire `wordToEmoji` avec des emojis supportés. Tu peux trouver la liste [ici](https://www.webfx.com/tools/emoji-cheat-sheet/).
+* Si tu as exécuté le fichier python `code/main.py`, tu as pu remarquer l'apparition du dossier `code/__pycache__`. Ces fichiers ne sont pas intéressants à gitter (car pas nécessaires à l'exécution du fichier `code/main.py`). Il faut donc ajouter un gitignore pour les ignorer : ***crée un fichier nommé*** `.gitignore` ***à la racine du repo*** et ajoute les dossiers et fichiers que tu veux ignorer (ici: `code.__pycache__`).
+* Commit et push tes changements. Remarque que le dossier `code/__pycacche__` n'a pas été synchronisé.
+
+---
+**Je n'arrive pas à push les changements**
+
+Comme tu as créé une branche en local, Git n'arrive pas à trouver la branche correspondant sur le serveur. Il faut donc la créer avce une option spéciale. Pas de panique ! Git te donne la commande à copier-coller dans le message d'erreur (les erreurs avec Git sont souvent assez explicite pense à bien les lire en cas de problème).
+
+---
+
+
+### Merge requests
+
+Sur l'interface Web du Gitlab, il y a un menu déroulant sous le nombre de commit permettant de sélectionner une branche. Choisis la branche que tu viens de push. Tu peux y voir tes changements mais ils disparaissent si tu repasses sur la branche master. L'objectif est d'intégrer les changements à master. Il faut pour cela créer une **merge request**.
+
+* À gauche, clique sur ***Merge Requests*** puis clique sur ***New merge request***.
+* Choisis ta branche en tant que ***Source branch*** et master en tant que ***Targe branch***. Puis clique sur ***Compare branches and continue***
+* Remplis un titre et une description. Tu peux aussi ajouter des labels personnalisés pour catégoriser facilement les merge requests.
+* Tout en bas tu trouves 2 onglets : ***Commits*** et ***Changes***. Ils te permettent de voir l'historique et les changements entre les 2 branches.
+* Clique ***Submit merge request***. La merge request a été créée. il ne reste plus qu'à cliquer sur ***Merge*** pour que les changements soient intégrés à master.
+
+---
+**Remarque :**
+
+Si plusieurs personnes travaillent sur le même projet, les autres membres du projet peuvent review les changements avant d'accepter la merge request (clic sur ***Merge***). Il est important qu'il y ait un titre et une description claire pour que ce soit plus facile à review. Ils peuvent aussi laisser des commentaires sur le code.
+
+---
+
+Félicitations, tu viens de réussir ta première merge request ! Je t'invite à regarder le graphe accessible dans ***Repository > Graph*** afin de bien comprendre le workflow que tu viens d'appliquer.
+
+### Rebase
+
+Si tu retournes dans l'onglet ***Merge Requests***, tu verras qu'une merge request était déjà ouverte. Elle apporte des améliorations au code. Comme il y a déjà eu des changements sur le même fichier, il faut **rebase** la branche sur master. Pas de panique, il suffit de cliquer sur le bouton ***Rebase*** sur la page de la merge request. Une fois le rebase effectué, tu peux review le code et merge. Encore, une fois, n'oublie pas de regarder le graphe pour bien visualiser les opérations que tu viens de faire.
+
+## Partie 4 : CI/CD
+
+Tu sais maintenant comment garder un historique de ton code et comment collaborer efficacement à plusieurs. Tu as déjà tous les outils en main pour travail sur du code en groupe ! La dernière partie présente le concept un peu plus avancé mais très pratique de CI/CD (Continuous Integration/Continuous Deployment) à travers l'outil ***Pipeline*** de Gitlab. Mettre ces concepts en pratiques aux Coding Weeks peut donner une très bonne impression au jury lors de la soutenance et faire gagner quelques points (en plus de faire gagner du temps dans le processus de développement).
+
+### Rappel des Concepts
+
+Une pipeline est une liste de tâches à faire définie dans un fichier du repo gitlab. Ces actions sont lancées à **chaque fois que du code est push sur le serveur Gitlab**. C'est donc un très bon moyen d'automatiser des tests pour savoir à chaque changement si les modifications de code ont cassé des fonctionnalités.
+
+Maintenant commençons à écrire notre première pipeline !
+
+### Ajout d'une étape de lint
+
+Tout d'abord, il peut être pratique de mettre en place une étape de lint automatisée. En effet, un code qui renvoie des erreurs de linter ne fonctionnera pas.
+
+---
+
+**Qu'est-ce qu'un linter ?**
+
+Un linter est un programme qui analyse la syntaxe du code afin de chercher des erreurs de syntaxe. Il permet notamment de détecter les erreurs d'indentation ou de nom de variables avec une faute de frappe.
+
+---
+
+* Crée un fichier `.gitlab-ci.yml` à la **racine** du repo.
+* Souvent, on n'écrit pas le fichier de zéro car il existe de nombreux exemples sur internet. Par exemple pour un job de linting j'ai trouvé [cet article](https://medium.com/cubemail88/setting-gitlab-ci-cd-for-python-application-b59f1fb70efe) qui donne un exemple.
+* Copier-coller dans le fichier `.gitlab-ci.yml` le code suivant fortement inspiré du site du point précédent :
+
+```YAML
+image: "python:3.8"  # La pipeline doit se lancer dans un environnement avec python installé
+
+# before_script avant chaque Job (affichage de la version de Python et installation des dépendances)
+before_script:
+  - python --version
+  - pip install -r requirements.txt
+
+# On peut définir différents stages (étapes) dans la pipeline. Chaque stage peut avoir plusieurs job
+stages:
+    - Testing
+
+# Définition des Jobs
+pylint:
+    stage: Lint  # chaque Job est rattaché à une étape
+    script:  # Ce sont les commandes qui seront lancées et qui feront fail le job si une erreur est renvoyée
+        - pylint -d C0301 code/*.py
+```
+
+---
+
+**Quelques remarques sur la structure de ce fichier**
+
+* La structure globale ne varie peu suivant les pipelines, car ce sont principalement les commandes lancées dans `script` qui varient suivant les tâches.
+* Il est possible de définir plusieurs étape (`stages`), mais aussi plusieurs tâches (`jobs`) dans une étape. Dans ce cas, les différentes tâches pourront être parallélisées.
+* Attention à l'indentation : le fichier `.gitlab-ci.yml` est en langage YAML qui est sensible à l'indentation.
+
+---
+
+Maintenant que le fichier `.gitlab-ci.yml` a été créé, il suffit de le commit et de le push sur le serveur Gitlab pour qu'il prenne effet.
+
+Sur l'interface graphique, tu peux voir dans ***CI/CD > Pipelines*** l'état de la pipeline.
+
+### Ajout de tests unitaires
+
+Maintenant qu'on a une pipeline avec une étape de linting, on veut aller plus loin en rajoutant des tests unitaires. Un test unitaire est un test qui teste la réponse d'une fonction face à certains arguments. Les tests unitaires ont été écrits dans `code/tests.py`. Il n'y a donc plus qu'à écrire le job correspondant dans `.gitlab-ci.yml`.
\ No newline at end of file

code/main.py

+import emoji
+import sys
+
+wordToEmoji = {
+    'super': ':thumbs_up:',
+    'coeur': ':red_heart:',
+    'sourire': ':smiley:',
+}
+
+
+def translate(word):
+    if word in wordToEmoji.keys():
+        return wordToEmoji[word]
+    else:
+        return word
+
+
+def convert(word):
+    # emoji.emojize convertit le code smiley en smileys
+    return emoji.emojize(word, use_aliases=True)
+
+
+if __name__ == "__main__":
+
+    if len(sys.argv) == 0:
+        print("Veuillez entrer une phrase en paramètre.")
+
+    else:
+        convertedText = ""
+        for sentence in sys.argv:
+            words = sentence.split(" ")
+            for word in words:
+                convertedText += convert(translate(word))
\ No newline at end of file

code/tests.py

+import unittest
+from main import translate, convert  # Importation des fonctions
+
+##### On définit les tests ci-dessous : #####
+
+
+class TestFunctions(unittest.TestCase):
+    def test_translate(self):
+        self.assertEqual(translate('super'), ':thumbs_up:')
+        self.assertEqual(translate('coeur'), ':red_heart:')
+        self.assertEqual(translate('sourire'), ':smiley:')
+        self.assertEqual(translate('pasdansledictionnaire'),
+                         'pasdansledictionnaire')
+        self.assertEqual(translate('casseletest'), 'letestcasse')
+
+    def test_convert(self):
+        self.assertEqual(convert('pasdansledictionnaire'),
+                         'pasdansledictionnaire')
+
+
+##### On appelle les test #####
+
+unittest.main()
\ No newline at end of file

fichier_inutile

+Je ne sers à rien !
\ No newline at end of file

requirements.txt

+emoji==0.6.0
+pylint==2.6.0
\ No newline at end of file