1 \documentclass[12pt]{report}
3 \usepackage[a4paper, top=1.5cm, bottom=1.5cm, left=1.5cm, right=1.5cm]{geometry}
4 \usepackage[utf8]{inputenc}
5 \usepackage[T1]{fontenc}
6 \usepackage[francais]{babel}
17 \usepackage{hyperref} % html link
18 \usepackage{float} %placement images
19 \usepackage{caption} %légendes centrées
20 \usepackage{textcomp} %caractères spéciaux
21 \usepackage{version} %ajoute l'environnement comment pour les commentaires longs
24 \captionsetup{margin=10pt,font=small,labelfont=bf,justification=centerlast}
26 %définition des entêtes et pieds de page
28 \setlength{\headheight}{15pt}
29 \renewcommand{\headrulewidth}{0pt} %épaisseur ligne de séparation
30 \renewcommand{\footrulewidth}{0pt}
31 \pagestyle{fancyplain}
32 \renewcommand{\chaptermark}[1]{\markboth{#1}{}}
33 \renewcommand{\sectionmark}[1]{\markright{#1}{}}
38 \cfoot{\thepage\ / \pageref{LastPage}}
40 \newenvironment{note}{\textbf{Note:}}{}
45 \thispagestyle{empty} %pas d'entêtes pour la première page
48 \renewcommand{\contentsname}{Sommaire}
52 \chapter{Intégration continue}
53 \section{Les options de make}
54 Il y a principalement quatre \htmladdnormallink{options}{http://www.vtk.org/Wiki/CTest:Nightly,_Experimental,_Continuous} de compilation :
55 Nightly, Continuous, Experimental et Test.
57 Quiconque peut lancer une compilation avec l'une de ces options.
59 \item make Nightly fait un raz des binaires mais garde la configuration, update les sources, build, lance les tests puis submit au dashboard.
60 \item make Experimental fait un build, lance les tests puis submit au dashboard.
61 \item make Continous fait un build, lance les tests puis submit au dashboard.
65 \section{Installation des compilations automatiques}
67 \item Récupérer les scripts \begin{verbatim}git clone http://russule/gitSources/vvDashboard\end{verbatim}
68 \item Configurer les scripts
69 \item Créer la tache sous linux et éventuellement sous windows
72 \subsection{Configuration des scripts}
73 Voici un bref résumé du rôle de chacun des scripts
75 \item builderNightly.bat : Lance les builds pour windows
76 \item commonConfig.cmake : Arborescence des dossiers, URL des données de test, path vers ITK et VTK
77 \item continuousBuild.cmake : Amorce un continuous
78 \item dartConfig.cmake : Configuration du serveur distant
79 \item fetch\_data\_test.bat : git pull ou clone si le repo n'existe pas
80 \item fetch\_data\_test.sh : idem pour linux
81 \item nightlyBuild.cmake : Parse les arguments pour lancer le build correspondant.
82 L'appèle du script est de la forme
84 ctest -S nightlyBuild.cmake,Itkv3.20.0 (ou ,ItkNightly)
85 # variante : ctest -S nightlyBuild.cmake,Itkv3.20.0,NoTools
86 # où il faut définir que faire lorsque l'argument NoTools est trouvé (ici, CLITK_BUILD_TOOLS=OFF)
88 \item startNightlyBuilds.sh : Lance toutes les nightly et lance la vm
89 \item vmLaunch.sh : Lance toutes les images virtuelles.
90 \item itkNightlyBuild.cmake : Met à jour le dossier itk from scratch. Ce script est appelé par nightlyBuild.cmake,ItkNightly
93 Les principales informations à modifier sont dans le fichier commonConfig.cmake.\\
94 Description de commonConfig.cmake
96 set(itkBin "${itkVersion}Bin/")
97 set(dashboard_binary_name "vv${itkVersion}${buildOptions}Bin/")
98 set(dashboard_source_name "vvSource")
99 #adresse où télécharger(cloner) les données de test.
100 set(data_test_path "${CTEST_DASHBOARD_ROOT}${dashboard_binary_name}data/")
102 #http://192.168.156.8/gitSources/vvDataTest est l'adresse où récupérer les données de test
103 EXEC_PROGRAM(${CTEST_SCRIPT_DIRECTORY}/fetch_data_test.${ext} ARGS ${data_test_path} http://192.168.156.8/gitSources/vvDataTest)
105 Exemple d'architecture des dossiers :
108 ./vvItkNightlyNoToolsBin
110 ./vvItkv3.20.0NoToolsBin
111 ./vvItkv3.20.0NoVvBin
115 \subsection{Création des taches}
116 Concernant les compilations automatiques, il est possible de créer une tache appelant le script startNightlyBuilds. \\
117 Ce dernier exécute pour chacun des builds configurés un raz, une mise à jour, une configuration, une compilation, puis l'exécution des tests et la
118 soumission de leurs résultats.\\
119 Il lance également la machine virtuelle, dans laquelle se trouve des builds sous windows.
124 0 22 * * * /home/mpech/workspace/vv/vvDashboard/startNightlyBuilds.sh > /home/mpech/workspace/nightlyLog.log
125 0 5 * * * ctest -S /home/mpech/workspace/vv/vvDashboard/continuousBuild.cmake,ItkNightly -V > /home/mpech/workspace/vvItkNightly/continuousMaster.log 2>&1
127 A 22h, on commence les builds linux puis on lance la VM. Chaque OS a la responsabilité de s'éteindre.\\
129 A 5h tous les jours un continuous est lancé. Il n'est pas nécessaire d'appeler plusieurs fois le continous :
130 une fois appelé, il dure pendant ''dashboard\_loop'' et tente une mise à jour du repo et soumet un build
131 au dashboard si le repo a été modifié, tous les ''CTEST\_DELAY\_TIME''. Ces variables
132 se modifient dans continuousBuild.cmake.
133 En regardant le script continuousBuild.cmake, on constate qu'il est effectif pendant une durée de \${dashboard\_loop}68400/3600=19h.
136 Il faut également créer une tâche appelant builderNightly.bat. Ce dernier lance également les builds et une fois ceux-ci finis,
138 Voici un \htmladdnormallink{lien}{http://www.vistax64.com/tutorials/132903-task-scheduler-create-task.html}.
139 Démarrer>exécuter>taskschd.msc ou bien clique-droit gérer sur ''Ordinateur'' dans l'explorateur de fichiers.
141 Sur le pannel de gauche, librairie>windows, créer un dossier par exemple vv, et à l'intérieur créer une nouvelle tache.
142 Seuls les déclencheurs et l'action (builderNightly.bat) nous intéresse.
145 \section{Configuration du dashboard}
146 Le dashboard de VV est accessible via ce \htmladdnormallink{lien}{http://my.cdash.org/index.php?project=VV}.\\
148 Le fuseau horaire d'affichage du dashboard est EDT.\\
149 Nous sommes CET. Il n'est pas possible de modifier l'heure affichée sur le dashboard pour qu'elle
150 corresponde à l'heure CET.
151 En revanche, il est possible de spécifier l'heure de début des nightly : sachant qu'il y a un décalage de 6h
152 (10h en France équivaut à 4h sur le dashboard). Par exemple si nous soumettons un build à 1h CET le mardi, cela équivaut à soumettre ce build à 19h EDT le lundi.\\
153 Ce faisant, en indiquant que les nightly commencent à 19h EDT sur le dashboard, notre build sera bien affiché mardi sur le dashboard.
156 \chapter{Création d'un sous-module pour les données de test}
157 \section{Git deuxième repo}
158 Actuellement, un deuxième repo est utilisé pour les données de test.
160 http://russule/gitSources/vvDataTest
162 /home/mpech/workspace/git/vvDataTest
165 Le serveur n'est pas configuré pour pouvoir pusher par http. Donc soit passer par le repo /home/..., soit
167 git push ssh://mpech@russule/home/mpech/workspace/gitSources/vvDataTest
170 \subsection{Mise en place du Git par http}
172 sudo zypper install apache2
174 sudo ln -s /home/mpech/workspace/git gitSources
176 Il est possible que le dossier ne soit pas accessible, s'assurer que FollowSymlinks est bien précisé. Chez moi dans
177 le fichier ''/etc/apache2/default-server.conf'', rajouter les options si non présentes.\\
178 Indexes pour afficher la liste des dossiers/fichiers présents dans un répertoire \\
179 FollowSymLinks pour permettre les liens symboliques depuis le répertoire web vers un répertoire quelconque.
181 <Directory "/srv/www/htdocs">
182 Options Indexes FollowSymLinks
185 Enfin, après chaque push vers le remote repo, il faut updater le serveur manuellement.
187 cd /home/mpech/workspace/git;
188 git update-server-info
190 A la place, on peut activer le hook post-update de git (en renommant le post-update.sample sans son suffixe):
192 cd /home/mpech/workspace/git/vvDatatest/hooks
193 mv post-update.sample post-update
195 De fait, git sera automatiquement mis à jour.
198 Ici git ne fait pas référence au données de test, le répertoire git contient
200 \item vvDataTest qui est le repo qui nous intéresse
201 \item vvDashboard qui contient les scripts pour les nightly, également versionné
205 \section{Git submodule}
206 Procédure pour monter le dossier de tests.
207 Création de notre repo data (qui contiendra les données de test):
210 git clone tests dataCloned
212 cd dataCloned; echo "a">a; git add a; git commit -m "add a";
213 git push origin master
216 Le fichier ''a'' est accessible aux autres clones de data.
218 On ajoute notre repo dataCloned en tant que submodule du super repo (par exemple vv).
221 git submodule add ../dataCloned tests/data
222 git commit -m "added the submodule data"
231 git submodule update; //now tests/data contain a file named "a"
232 cd tests/data; echo "b">b; git add b && git commit -m "adding b";
236 Comme le sous-module a été modifié, on oublie pas de mettre à jour super :
238 git submodule add tests/data #remarque : PAS de trailing slash à la fin de data
239 git commit -m "mise à jour du sous-repos"
243 Désormais les autres pourront git submodule update avec la dernière version du repo de data.
245 Si on avait pas commité, alors le submodule update ne tient pas compte des nouvelles modifications
246 sur le repository data.
248 \subsection{Enlever des fichiers du repository data}
249 Si pour une raison x, on veut enlever des fichiers de data. Par exemple heavy.dcm
250 dans le submodule ou simplement dans dataCloned :
253 git filter-branch --index-filter 'git rm --cached --ignore-unmatch heavy.dcm' HEAD
254 git push origin master --force
257 dans le bare repo data :
259 git reflog expire --expire=now --all
260 git gc --aggressive --prune=now
263 Côté super, on met à jour le submodule,
266 #puis on ajoute la nouvelle référence :
267 git add tests/data; git commit -m "updated submodule"; git push
271 Côté client, celui-ci n'a plus qu'à runner
273 git pull; git submodule update
275 Si il avait le fichier heavy.dcm, alors celui-ci est potentiellement encore dans le .git du submodule. Il peut l'enlever
278 rm -rf .git/refs/original
279 git reflog expire --expire=now --all
280 git gc --aggressive --prune=now
283 Source : \htmladdnormallink{github}{http://help.github.com/remove-sensitive-data/}
289 \chapter{Procédure de test d'outils}
290 \section{Procédure de test}
292 \item Choisir un outil, et une image test d'entrée.
293 \item Lui faire générer une image
294 \item Cette image générée sert de référence. L'outil valide doit générer cette image à partir de l'image test d'entrée.
295 \item Passer l'image test d'entrée et s'assurer que l'outil génère bien l'image de référence.
297 \section{Step by Step}
299 \item Choisir un outils : ex : clitkCropImage
300 \item Chercher comment le lancer :
302 cat $(find -name *CropImage*ggo)
304 \item Choisir les images qui vont bien: par défaut sont présentes Lung3D.mhd, Deformation4D.mhd (toutes deux de petites
305 tailles), les paramètres etc...
306 \item Exécuter l'outil : ./clitkCropImage {parametres}
307 \item Récupérer la (les) images générées (vérifier qu'elle(s) est(sont) correcte(s)) et les copier dans le dossier
309 \item Mettre à jour le /tests/tools/CMakeLists.txt en ajoutant le test
310 \item Vérifier qu'on a bien le test qui passe,
312 #on reparse le CMakeLists.txt
317 Si un test échoue, on peut accéder à la raison via le fichier /Testing/Temporary/lastTest.log
318 \item Répéter pour autant de tests qu'on veut faire sur un outils
319 \item Mettre à jour le dashboard ''make Experimental''
320 \item Commit/Push les images sur le git des images tests
321 \item Commit du CMakeLists.txt sur le repository de vv