View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001088 | Dracca | [All Projects] General | public | 2016-03-20 18:46 | 2017-04-25 17:16 |
Reporter | Xenos | Assigned To | Xenos | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | Close | Resolution | fixed | ||
Product Version | |||||
Target Version | Fixed in Version | 1.0.1 | |||
Summary | 0001088: Ajouter un mécanisme évitant de recompiler le gamebook si le déploiement a été stoppé | ||||
Description | Quand je déploie Dracca, le gamebook est intégralement recompilé. C'est bien, ça m'évite d'oublier des trucs. Néanmoins, d'autres tests suivent cette compilation (Selenium, repo, PHPUnit, etc). Si l'un de ces tests foire, tout le déploiement est stoppé. Donc, lorsque j'aurai corrigé le soucis, il faudra re-compiler de nouveau tout le gamebook. Il faut donc trouver un moyen de ne pas recompiler le gamebook si celui-ci a déjà été compilé correctement. Je pourrai ajouter un tag local sur le dernier commit mercurial lorsque la compilation est faite intégralement. Mais cela pose un soucis: si je commit à nouveau, la compilation a encore lieu. Or, si le déploiement a été stoppé, c'est qu'un truc manque et donc, il y a de fortes chances que je doive commiter la correction, et que la compilation soit donc re-effectuée inutilement. C'est un peu dommage. Une idée plus intéressante est de génrer un hash correspondant à tous les fichiers impliquées par la compilation du gamebook: je génère donc une signature pour l'ensemble des fichiers dans (sources/gamebook/builder + sources/gamebook/univers + sources/livres/livre-?/) que je sauve dans un fichier tmp/gamebook-?.sha (genre sha256). Quand je doit recompiler tout le gamebook, j'ai juste à vérifier que la signature calculée correspond à celle éventuellement stockée dans le tmp/gamebook-?.sha: si oui, inutile de recompiler, si non, je recompile. Ainsi, je gagnerai du temps car je pers 10 minutes à chaque compilation, donc s'il faut en faire 6 de suite parce qu'il y a eu 6 échecs de pré-deploy, ça ne va pas aller ! | ||||
Tags | No tags attached. | ||||
Attach Tags | |||||
Le script shell "pre-deploy.sh" calcule maintenant le hash md5 de l'ensemble des fichiers impliqués dans la génération du gamebook (builder, univers et paragraphes): si la signature trouvée est la même que la dernière signature, alors le système ne recompile pas le gamebook. Ainsi, lors d'un deploy, ce pre-deploy.sh est lancé, et compile le gamebook. Si la suite du deploy fail (pour une raison quelconque, genre un CSS n'est pas valide), alors je peux corriger les fichiers du projet, commiter, et refaire un deploy. Comme je n'ai pas touché aux codes du gamebook, le pre-deploy.sh va retrouver la même signature qu'avant, et ne recompilera pas le gamebook. Donc, je gagnerai du temps en évitant de perdre 10 minutes à chaque tentative de deploy ! |
|
Eh ben oui: j'ai gagné 5 minutes au déploiement en ne recompilant pas inutilement le gamebook (et j'ai gagné aussi du temps à droite à gauche au gré des quick builds et autres trucs du genre). | |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-03-20 18:46 | Xenos | New Issue | |
2016-03-20 18:46 | Xenos | Status | New => Accepted |
2016-03-25 16:14 | Xenostom | Assigned To | => Xenostom |
2016-03-25 16:14 | Xenostom | Status | Accepted => In progress |
2016-03-25 16:41 | Xenostom | Note Added: 0001646 | |
2016-03-25 16:41 | Xenostom | Status | In progress => Ready |
2016-03-25 16:41 | Xenostom | Resolution | open => fixed |
2016-04-01 16:50 | AutoUpdater | Assigned To | Xenostom => Xenos |
2016-04-01 16:50 | AutoUpdater | Status | Ready => Resolved |
2016-04-01 17:07 | AutoUpdater | Fixed in Version | => 1.0.1 |
2016-04-01 17:14 | Xenos | Note Added: 0001662 | |
2016-04-01 17:14 | Xenos | Status | Resolved => Close |
2017-04-25 17:16 | Xenos | Project | @15@ => Dracca |