GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
-`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
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
> 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`
-`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 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
```
%% Cell type:markdown id: tags:
### Entête et étape préliminaire du fichier `.gitlab-ci.yml`
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.
