@@ -121,7 +121,19 @@ Nous allons maintenant travailler avec un petit module en pur python créé pour
*[dice-http-server](python-dice/dice-http-server) : notre application web totalement disruptive, qui utilise notre module ;
*[Dockerfile](python-dice/Dockerfile) : à votre avis ?
### 11. Test et publication de la documentation à l'aide de Gitlab Pages ###
### 11. Tests et publication de la documentation à l'aide de Gitlab Pages ###
Nous allons écrire un pipeline complet, qui teste la fonctionnalité et le style du code (avec *pycodestyle*, disponible dans *pip*,) et qui génère et déploie la documentation (avec *sphinx*, disponible lui aussi dans pip). Pour la partie documentation, on utilisera [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) pour ne la regénérer que si le message de commit commence par `[doc]`. Cette étape un peu spéciale est appelée [pages](https://docs.gitlab.com/ee/ci/yaml/#pages) et s'appuie sur une fonctionnalité appelée [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html)(original !).
**But** : Écrire un fichier .gitlab-ci.yml qui comporte trois deux étapes.
* La première étape comporte deux jobs, l'un qui teste le code à l'aide du test unitaire, et l'autre qui teste son style à l'aide de pycodestyle. Comme nous ne sommes pas des orthodoxes, admettons que dans certains cas le *coding style* peut ne pas être respecté...
* La seconde étape génère et déploie la documentation dans Gitlab Pages
Vérifier qu'en ne respectant pas la [PEP8](https://www.python.org/dev/peps/pep-0008/), le pipeline émet une alerte.
Vérifier que la documentation est bien déployée (le lien est disponible dans *Settings -> Pages*).
*Note* : Pour générer la documentation dans `build/sphinx/html`, utilisez la commande distutils `build_sphinx`.
