Merge branch 'pages' into 'master'

Pages See merge request m.boileau/tp-gitlab-ci!4

Merge branch 'pages' into 'master'
Pages See merge request m.boileau/tp-gitlab-ci!4
654fc5b8 · Matthieu Boileau · 9080761f · 2480e914 · 654fc5b8 · 654fc5b8
Commit 654fc5b8 authored 7 years ago by Matthieu Boileau
--- a/index.ipynb
+++ b/index.ipynb
@@ -22,6 +22,7 @@
    "\n",
    "- [Notebook](http://nbviewer.jupyter.org/urls/boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.ipynb)\n",
    "- [Slideshow](https://boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.slides.html)\n",
+    "- [Sources](https://git.unistra.fr/m.boileau/tp-gitlab-ci)\n",
    "---\n",
    "\n",
    "Matthieu Boileau - <matthieu.boileau@math.unistra.fr>\n",

 %% Cell type:markdown id: tags:
 ### Journée X/Stra-Dev Intégration continue
 21 novembre 2017
 ---
 # L'intégration continue avec GitLab
 ![image.png](tanuki.png)
 ## *Session pratique*
 - [Notebook](http://nbviewer.jupyter.org/urls/boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.ipynb)
 - [Slideshow](https://boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.slides.html)
+- [Sources](https://git.unistra.fr/m.boileau/tp-gitlab-ci)
 ---
 Matthieu Boileau - <matthieu.boileau@math.unistra.fr>
 *Contenu sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0)*

--- a/tp-gitlab-ci.ipynb
+++ b/tp-gitlab-ci.ipynb
@@ -347,7 +347,7 @@
    "Settings > CI / CD > Runners settings\n",
    "```\n",
    "\n",
-    "Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui porte les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`"
+    "Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui portent les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`"
   ]
  },
  {
@@ -626,7 +626,7 @@
   "cell_type": "markdown",
   "metadata": {
    "slideshow": {
-     "slide_type": "slide"
+     "slide_type": "subslide"
    }
   },
   "source": [
@@ -648,7 +648,7 @@
   "cell_type": "markdown",
   "metadata": {
    "slideshow": {
-     "slide_type": "slide"
+     "slide_type": "subslide"
    }
   },
   "source": [
@@ -771,19 +771,9 @@
  },
  {
   "cell_type": "code",
-   "execution_count": 68,
+   "execution_count": null,
   "metadata": {},
-   "outputs": [
+   "outputs": [],
-    {
-     "name": "stdout",
-     "output_type": "stream",
-     "text": [
-      "No local changes to save\n",
-      "Already on 'exo3'\n",
-      "Your branch is up-to-date with 'origin/exo3'.\n"
-     ]
-    }
-   ],
   "source": [
    "cd $TPDIR\n",
    "git stash  # si vous avez des modifications non enregistrées dans exo2\n",
@@ -918,7 +908,7 @@
    "\n",
    "Comme le montre ce schéma, l'exécution de différents jobs d'une même étape peut être réalisée en parallèle par différents runners.\n",
    "\n",
-    "Plus d'information "
+    "Plus d'information sur la [doc en ligne](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html)."
   ]
  },
  {
@@ -929,15 +919,23 @@
    }
   },
   "source": [
-    "## Récupérer un artifact"
+    "# Conclusion\n",
+    "\n",
+    "### Ce qu'on a vu\n",
+    "- comment configurer un runner `shell`\n",
+    "- comment cibler différents runners\n",
+    "- comment mettre en place une chaîne d'intégration continue\n",
+    "- comment tirer/construire/pousser des images Docker\n",
+    "\n",
+    "### Ce qu'on n'a pas vu\n",
+    "- comment utiliser les autres types de runners (en particulier `docker`)\n",
+    "- comment récupérer des artefacts d'intégration\n",
+    "- les problèmes de [sécurité](http://docs.gitlab.com/runner/executors/shell.html#security)\n",
+    "- GitLab Pages\n",
+    "- bien plus !\n",
+    "\n",
+    "Mais beaucoup de réponses sont dans la [doc en ligne](https://docs.gitlab.com/ee/ci/README.html) qui est très complète !"
   ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {},
-   "outputs": [],
-   "source": []
  }
 ],
 "metadata": {

 %% Cell type:markdown id: tags:
 ### Journée X/Stra-Dev Intégration continue
 21 novembre 2017
 ---
 # L'intégration continue avec GitLab
 ![image.png](tanuki.png)
 ## *Session pratique*
 ---
 Matthieu Boileau - <matthieu.boileau@math.unistra.fr>
 *Contenu sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0)*
 %% Cell type:markdown id: tags:
 # GitLab CI
 GitLab CI propose une chaîne complète d'intégration continue intégrée à son système de forge logicielle.
 ![](cicd_pipeline_infograph.png)
 <span style="font-size:0.7em;"><https://docs.gitlab.com/ee/ci/README.html></span>
 **Les avantages :**
 - la simplicité de mise en oeuvre
 - la robustesse d'une solution intégrée
 %% Cell type:markdown id: tags:
 ## Le gitlab runner
 ### Introduction
 - `gitlab-runner` est un démon installé sur une machine destinée à exécuter les tâches d'intégration continue.
 - Pour chaque *runner* enregistré, `gitlab-runner` écoute l'instance de gitlab correspondante dans l'attente d'une tâche
 - Cette tâche est déclenchée par des évènements (`push`, `merge`, etc.) sur le projet avec lequel il est lié
 - Ce lien est créé à l'enregistrement du *runner* par un token associé au projet.
 [**Doc en ligne**](https://docs.gitlab.com/ce/ci/runners/#shared-vs-specific-runners)
 %% Cell type:markdown id: tags:
 ### Runners : *shared* vs *specific*
 - *shared* : n'importe quel projet peut s'en servir. Seul l'administrateur du GitLab peut enregistrer des runners partagés.
 - *specific* : seul le créateur du runner peut s'en servir dans d'autres projets
 > **Attention** : les runners partagés sont pratiques mais peuvent présenter des [problèmes de sécurité](https://docs.gitlab.com/ee/ci/runners/README.html#be-careful-with-sensitive-information).
 ### Runners : *locked* vs *unlocked runners*
 - *locked* : le runner ne peut être utilisé que pour le projet avec lequel il est lié
 - *unlocked* : le créateur du runner peut l'utiliser dans ses autres projets
 %% Cell type:markdown id: tags:
 ### Installer `gitlab-runner`
 La **[procédure](https://docs.gitlab.com/runner/install/)** dépend du système d'exploitation.
 %% Cell type:markdown id: tags:
 ## Fork du TP
 Faire un *fork* du projet sur votre compte GitLab en allant sur la page d'accueil du projet
 ![fork.png](fork.png)
 ou en suivant [ce lien](https://git.unistra.fr/m.boileau/tp-gitlab-ci/forks/new).
 %% Cell type:markdown id: tags:
 ## Clone du TP
 %% Cell type:markdown id: tags:
 - Pour paramétrer les commandes de ce notebook, positionner les variables d'environnement suivantes :
 %% Cell type:code id: tags:
 ``` bash
 export USERNAME="m.boileau"  # votre login sur git.unistra.fr
 export TPBASEDIR=$HOME       # le répertoire où vous souhaitez installer le TP
 export TPDIR=$TPBASEDIR/tp-gitlab-ci
 ```
 %% Cell type:markdown id: tags:
 - Cloner localement votre projet
 %% Cell type:code id: tags:
 ``` bash
 cd $TPBASEDIR
 git clone git@git.unistra.fr:$USERNAME/tp-gitlab-ci.git
 ```
 %% Cell type:markdown id: tags:
 ## Enregistrer  un nouveau runner
 > Si `gitlab-runner` n'est pas installé sur votre machine, rdv à la section **Exo1**
 Engistrer un runner consiste à créer un nouveau runner associé à un projet.
 Si vous n'êtes pas administrateur du GitLab, il s'agit forcément d'un runner spécifique. Celui-ci se trouve dans
 votre projet, rubrique :
 ```
 Settings > CI / CD > Runners settings
 ```
 %% Cell type:markdown id: tags:
 Dans le terminal, maintenant :
 %% Cell type:code id: tags:
 ``` bash
 export CI_SERVER_URL=https://git.unistra.fr/  # Do not change for this session
 export RUNNER_NAME=a_runner_for_$USERNAME
 export REGISTRATION_TOKEN=xxx  # Replace by the value provided by the runner setting page
 export REGISTER_NON_INTERACTIVE=true
 #gitlab-runner register --executor shell        # sous MacOS
 #sudo gitlab-runner register --executor shell   # sous Linux
 ```
 %% Cell type:markdown id: tags:
 Ou bien lancez la commande en mode interactif et en suivant pas à pas la [procédure](http://docs.gitlab.com/runner/register/#registering-runners):
 ```
 gitlab-runner register       # sous MacOS
 sudo gitlab-runner register  # sous Linux
 ```
 %% Cell type:markdown id: tags:
 - Retournez sur la page de paramètrage des runners
 - Repérez votre nouveau runner
 - Editez-le et ajouter les tags `specific, shell`
 Votre runner est maintenant prêt à travailler. Nous allons le tester en lui soumettant une tâche GitLab CI déclenchée par un `git push` sur votre projet.
 %% Cell type:markdown id: tags:
 ## Exo1 : helloworld en bash
 ### Mettre en place une action d'intégration continue
 Allez dans le répertoire racine du clone local de votre projet et basculez sur la branche `exo1`
 %% Cell type:code id: tags:
 ``` bash
 cd $TPDIR
 ```
 %% Cell type:code id: tags:
 ``` bash
 git pull
 git stash
 git checkout exo1
 git checkout exo1-start .gitlab-ci.yml  # Clean previous modifications
 ```
 %% Cell type:markdown id: tags:
 Repérer le fichier `.gitlab-ci.yml`
 %% Cell type:code id: tags:
 ``` bash
 ls -al
 ```
 %% Cell type:markdown id: tags:
 L'éditer avec l'éditeur de votre choix
 %% Cell type:code id: tags:
 ``` bash
 cat .gitlab-ci.yml
 ```
 %% Cell type:markdown id: tags:
 - `helloworld` indique le nom du job d'intégration continue
 - `tags` permet de sélectionner des runners sur la base de mot-clés
 - `scripts` correspond aux lignes de commande `bash` que vous souhaitez exécuter
 %% Cell type:markdown id: tags:
 ### Si vous souhaitez utiliser un runner partagé
 Dans la rubrique :
 ```
 Settings > CI / CD > Runners settings
 ```
-Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui porte les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`
+Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui portent les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`
 %% Cell type:markdown id: tags:
 ### Déclenchez une action d'intégration continue
 Modifiez la ligne de script, par exemple:
 %% Cell type:code id: tags:
 ``` bash
 echo '    - echo "bonjour, monde"' >> .gitlab-ci.yml
 cat .gitlab-ci.yml
 ```
 %% Cell type:markdown id: tags:
 Enregistrez avec git
 %% Cell type:code id: tags:
 ``` bash
 git add .gitlab-ci.yml
 git commit -m "Update .gitlab-ci.yml"
 ```
 %% Cell type:markdown id: tags:
 Poussez vos modifications
 %% Cell type:code id: tags:
 ``` bash
 git push
 ```
 %% Cell type:markdown id: tags:
 Sur GitLab, observez l'exécution de votre job dans la rubrique de votre projet :
 ```
 CI / CD > Pipelines
 ```
 %% Cell type:markdown id: tags:
 ### Provoquez une erreur
 Dans `.gitlab-ci.yml`, introduisez une erreur dans une des lignes du script et observer l'effet dans `CI / CD > Pipelines` après avoir poussé les modifications.
 > **Note :** les fichiers peuvent s'éditer directement dans GitLab.
 %% Cell type:markdown id: tags:
 ## Exo2 : helloworld en C
 ### Description
 On écrit le programme `helloworld` en C qui doit afficher `hello, world`.
 ### Mettre en place une action de *build*
 Dans votre clone local, basculez sur la branche `exo2`
 %% Cell type:code id: tags:
 ``` bash
 cd $TPDIR
 git stash  # si vous avez des modifications non enregistrées dans exo1
 git checkout exo2
 git rm .gitlab-ci.yml  # Clean previous commits
 ```
 %% Cell type:markdown id: tags:
 Listez le contenu du répertoire
 %% Cell type:code id: tags:
 ``` bash
 ls -al
 ```
 %% Cell type:markdown id: tags:
 Vérifiez que le progamme compile
 %% Cell type:code id: tags:
 ``` bash
 make
 ```
 %% Cell type:markdown id: tags:
 On crée le fichier `.gitlab-ci.yml` avec une étape (`stage`) de `build`. Il doit contenir :
 ```yaml
 build_hello:
  stage: build
  tags:
    - shell
  script:
    - make
 ```
 %% Cell type:code id: tags:
 ``` bash
 cat > .gitlab-ci.yml <<- EOM
 build_hello:
  stage: build
  tags:
    - shell
  script:
    - make
 EOM
 ```
 %% Cell type:markdown id: tags:
 On vérifie le contenu
 %% Cell type:code id: tags:
 ``` bash
 cat .gitlab-ci.yml
 ```
 %% Cell type:markdown id: tags:
 On enregistre et on pousse.
 %% Cell type:code id: tags:
 ``` bash
 git add .gitlab-ci.yml
 git commit -m "Add .gitlab-ci.yml with a build stage"
 ```
 %% Cell type:code id: tags:
 ``` bash
 git push
 ```
 %% Cell type:markdown id: tags:
 Sur GitLab, observez l'exécution de votre job dans la rubrique de votre projet :
 ```
 CI / CD > Pipelines
 ```
 %% Cell type:markdown id: tags:
 ### Ajouter une action de *test*
 On souhaite ajouter une étape de test réalisée avec `make test`. Tester l'exécution du test (il ne doit pas renvoyer d'erreur) :
 %% Cell type:code id: tags:
 ``` bash
 make test
 ```
 %% Cell type:markdown id: tags:
 Il faut ajouter le contenu suivant :
 ```yaml
 test_hello:
  stage: test
  tags:
    - shell
  script:
    - make test
 ```
 %% Cell type:code id: tags:
 ``` bash
 cat >> .gitlab-ci.yml <<- EOM
 test_hello:
  stage: test
  tags:
    - shell
  script:
    - make test
 EOM
 ```
 %% Cell type:code id: tags:
 ``` bash
 cat .gitlab-ci.yml
 ```
 %% Cell type:markdown id: tags:
 On enregistre, on pousse et on vérifie l'exécution de la chaîne d'intégration continue dans `CI / CD > Pipelines`
 %% Cell type:code id: tags:
 ``` bash
 git add .gitlab-ci.yml
 git commit -m "Add a test stage to .gitlab-ci.yml"
 ```
 %% Cell type:code id: tags:
 ``` bash
 git push
 ```
 %% Cell type:markdown id: tags:
 ### Provoquez des erreurs
 Modifier les fichiers pour provoquer des erreurs.
 Notez que le test n'est pas exécuté si le build échoue.
 %% Cell type:markdown id: tags:
 ## Exo3 : Docker pour gérer les dépendances
 À `helloworld`, on ajoute un programme en python `rosenbrock.py` qui calcule la [fonction de Rosenbrock](https://fr.wikipedia.org/wiki/Fonction_de_Rosenbrock). Ce programme nécessite [`pythran`](http://pythran.readthedocs.io/), un traducteur de python vers C++ qui permet d'accélérer le code python.
 Cet exercice a pour but d'illustrer la gestion des dépendances de compilation avec les conteneurs Docker dans une chaîne GitLab CI.
 Pour le reproduire, il est nécessaire de :
 1. créer un compte sur [DockerHub](https://hub.docker.com/)
 2. y créer un dépôt vierge intitulé `rosen`
 3. que Docker soit installé sur la machine qui héberge le runner (c'est le cas pour le runner partagé de ce TP).
 %% Cell type:markdown id: tags:
 Dans votre clone local, basculez sur `exo3`
 %% Cell type:code id: tags:
 ``` bash
 cd $TPDIR
 git stash  # si vous avez des modifications non enregistrées dans exo2
 git checkout exo3
 ```
-%% Output
-    No local changes to save
-    Already on 'exo3'
-    Your branch is up-to-date with 'origin/exo3'.
 %% Cell type:markdown id: tags:
 ### Entête et étape préliminaire du fichier `.gitlab-ci.yml`
 ```yaml
 stages:
  - build
  - test
  - release
 variables:
  CONTAINER_TEST_IMAGE: boileaum/rosen:$CI_COMMIT_REF_NAME
  CONTAINER_RELEASE_IMAGE: boileaum/rosen:latest
 before_script:
  - echo $DOCKERHUB_PASSWD | docker login -u boileaum --password-stdin
 [...]
 ```
 Pour faire marcher l'exercice :
 1. Remplacez `boileaum` par votre `username` sur DockerHub.
 2. Sur GitLab dans `Settings > CI / CD > Secret variables`, créez une variable `DOCKERHUB_PASSWD` qui contient le mot de passe de votre compte DockerHub.
 %% Cell type:markdown id: tags:
 ### Etape de `build` :
 ```yaml
 [...]
 b:docker:
  stage: build
  tags:
    - shell, docker
  script:
    - docker build --pull -t $CONTAINER_TEST_IMAGE -f ./docker/Dockerfile-rosen .
    - docker push $CONTAINER_TEST_IMAGE
 [...]
 ```
 - on construit l'image de test à partir du fichier `./docker/Dockerfile-rosen`
 - on pousse cette image sur DockerHub
 > **Note :** l'image `Dockerfile-rosen` est basée sur l'image construite avec `./docker/Dockerfile-pythran` et qui contient les dépendances.
 %% Cell type:markdown id: tags:
 ### Etapes de `test`
 ```yaml
 [...]
 t:helloworld:
  stage: test
  tags:
    - shell, docker
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker run $CONTAINER_TEST_IMAGE /bin/bash -c 'python test_helloworld.py'
 [...]
 ```
 - on tire l'image de test
 - on lance les tests unitaires
 %% Cell type:markdown id: tags:
 ### Etape de livraison
 ```yaml
 [...]
 r:docker:
  stage: release
  tags:
    - shell, docker
  script:
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
    - docker push $CONTAINER_RELEASE_IMAGE
  only:
    - exo3
 [...]
 ```
 On ne fait que tirer l'image de test validée, la renommer, la pousser vers DockerHub.
 %% Cell type:markdown id: tags:
 ### Pipeline complet
 ![](pipeline.png)
 Comme le montre ce schéma, l'exécution de différents jobs d'une même étape peut être réalisée en parallèle par différents runners.
-Plus d'information
+Plus d'information sur la [doc en ligne](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html).
 %% Cell type:markdown id: tags:
-## Récupérer un artifact
+# Conclusion
-%% Cell type:code id: tags:
+### Ce qu'on a vu
+- comment configurer un runner `shell`
+- comment cibler différents runners
+- comment mettre en place une chaîne d'intégration continue
+- comment tirer/construire/pousser des images Docker
-``` bash
+### Ce qu'on n'a pas vu
-```
+- comment utiliser les autres types de runners (en particulier `docker`)
+- comment récupérer des artefacts d'intégration
+- les problèmes de [sécurité](http://docs.gitlab.com/runner/executors/shell.html#security)
+- GitLab Pages
+- bien plus !
+Mais beaucoup de réponses sont dans la [doc en ligne](https://docs.gitlab.com/ee/ci/README.html) qui est très complète !