Differences

This shows you the differences between two versions of the page.

--- 2018_2019:s3:methodo:td:ci [2018/08/12 06:53] – created blay
+++ 2018_2019:s3:methodo:td:ci [2018/09/02 20:07] (current) – [Analyse de la qualité : SonarQube] blay
@@ Line 1: / Line 1: @@
 ====== Intégration continue ======
-Objectifs : mettre en place une intégration continue minimale
+Objectifs : mettre en place une intégration continue minimale associée à votre projet gitlab
-NOus allons à présent reprendre les codes donnés lors du premier exercice, les placer sous contrôle de version (GIT) et mettre en placce des mécanismes automatiques de tests.
+Nous allons à présent reprendre les codes donnés lors du premier exercice, les placer sous contrôle de version (GIT) et mettre en place des mécanismes automatiques de tests.
+  - Placez les codes que vous avez développé lors du premier exercice dans votre répertoire sous gestion de version, i.e. **seulement ''src'' et ''tests''**
+  - Créez un projet java sous eclipse qui référence votre projet
+        - new java project
+        - dé-sélectionner la localisation par défaut pour y mettre la place où vous avez stocké votre projet
+  - Exécutez les tests
+  - AVANT de commiter, nous devons éliminer tout ce qui n'a pas besoin d'être sous version de contrôle en particulier les binaires, pour cela le fichier ''.gitignore'' nous permet de préciser les fichiers à omettre.
+       - Sous sourceTree vous pouvez sélectionner les fichiers à ignorer et commiter.. {{ :2018_2019:s3:methodo:td:capture_d_e_cran_2018-09-02_a_19.34.06.png?direct&300 |}}
+       - Dans le projet que vous aviez récupéré initialement, il y a un fichier ''.gitignore'' qui élimine d'office la plupart des fichiers qu'il est inutile de commiter dans le cadre d'un projet eclipse et java. Vous pouvez trouver des patrons de ''.gitignore'' sur le web facilement.
+  - Vérifiez que vous avez bien "poussé " uniquement des fichiers voulus.
+  - A présent nous avons pour objectif de forcer la validation des tests à chaque fois que le code est poussé.
+      - Récupérer le fichier .gitlab-ci.yml et l'ouvrir sous eclipse par exemple en installant le plugin Yaml
+      - Ajouter le fichier à la gestion de version.
+  - Constater sous gitlab ci que l'exécution est en attente d'un "runner" {{ :2018_2019:s3:methodo:td:gitlabci_2018-09-02_a_21.02.57.png?direct&400 |}}
+      - Pour désigner le Runner aller sous Setting, Ci, {{ :2018_2019:s3:methodo:td:gitlabci_2018-09-02_a_21.07.16.png?direct&300 |}}
+      - Expand Runners
+           - Sélectionner  le runner specific {{ :2018_2019:s3:methodo:td:specificrunners_2018-09-02_a_21.12.15.png?direct&300 |}}
+  - Vérifier que les tests s'exécutent correctement.
+  - Oter le commentaire devant le test qui échoue dans yml, commiter et vérifier que les tests échouent bien.
+/*        - clique droit sur le projet, configure build path{{ :2018_2019:s3:methodo:td:configurebuildpath2018-09-02_a_19.18.10.png?direct&300 |}}
+*/
-PENSEZ à revenir sur le 1e TD pour connecter SONAR
-[[2018-2019:gitlab:ci:start|Gestion de versions]]
-===== Analyse de la qualité : SonarQube =====
-<accordion  collapsed="true">
-<panel  icon="fa fa-pencil"  title="Gérer la qualité">
-Générer un token
-Attention il faut etre sur le VPN
-http://codequal-info-01:9000
-</panel>
-</accordion>