https://docs.gitlab.com/ee/ci/pipelines/pipeline_artifacts.

html

https://docs.gitlab.com/ee/ci/docker/using_kaniko.html

Utiliser extends pour éviter les répétitions :

La directive extends est un excellent moyen de réutiliser certaines parties de YAML à plusieurs endroits
(une sorte de 'template'), par exemple :

Dans l'exemple, je créé une clé cachée (car elle commence par un . ) et haut de mon fichier que je peux
ensuite appeler à travers les différentes étapes (test, deploy).

Bien sûr on peut étendre les fonctionnalités afin d'obtenir des choses bien plus complexes et de réduire
la complexité et de rendre le pipeline plus lisible.

Utiliser include pour "templatiser" vos projets

Bon, pour éviter de se répéter, on peut inclure un template (un fichier YAML) grâce à la
directive include dans notre pipeline actuel.
Le fichier peut être soit local, soit distant dans un autre dépôt.
On pourrait très bien créer un dépôt qui contient uniquement nos templates pour tous nos projets.
(le projet pipelines dans le cas PZ7) Ce qui est très pratique si on souhaite partir sur une
pratique DevSecOps où l'équipe sécu pourrait fournir des templates ayant les prérequis sécu !
Utiliser directive artifacts : Artefacts de Pipeline (ce n’est
pas la même chose qu’artefact de travail !!)
Les artefacts de pipeline sont des fichiers créés par GitLab après la fin d'un pipeline. Les artefacts
de pipeline sont différents des artefacts de travail car ils ne sont pas gérés explicitement
par .gitlab-ci.yml des définitions.
Lorsque les artefacts de pipeline sont supprimés, Artefacts de pipeline de :
 Les derniers pipelines sont conservés pour toujours.
 Les pipelines remplacés par un pipeline plus récent sont supprimés sept jours
après leur date de création.
Les artefacts de pipeline sont enregistrés sur le disque ou le stockage d'objets. Ils sont pris en
compte dans le quota d'utilisation de l'espace de stockage d'un projet (en GITLAB
effectivement). Les artefacts de la page Quotas d'utilisation correspondent à la somme de tous
les artefacts de tâche et de pipeline.

è C’est utile pour pouvoir exploiter l’artefact lors l’étape prochaine

Les artefacts sont un peu comme du cache mais ils peuvent être récupérés depuis un autre
pipeline. Comme pour le cache il faut définir une liste de fichiers ou/et répertoires qui seront
sauvegardés par GitLab. Les fichiers sont sauvegardés uniquement si le job réussit.

Nous y retrouvons cinq sous-directives possibles :

 paths : obligatoire, elle permet de spécifier la liste des fichiers et/ou dossiers à mettre
en artifact
 name : facultative, elle permet de donner un nom à l’artifact. Par défaut elle sera
nommée artifacts.zip
  Untracked : facultative, elle permet d’ignorer les fichiers définis dans le fichier .gitignore
 when : facultative, elle permet de définir quand l’artifact doit être créé. Trois choix
possibles on_success, on_failure, always. La valeur on_success est la valeur par défaut.
 Expire_in : facultative, elle permet de définir un temps d’expiration

Utiliser kaniko pour builder Docker images

kaniko est un outil pour créer des images de conteneur à partir d'un Dockerfile, à l'intérieur d'un
conteneur ou d'un cluster Kubernetes.

kaniko résout deux problèmes avec l'utilisation de la méthode de construction Docker-in-

Docker :

 Docker-in-Docker nécessite un mode privilégié pour fonctionner, ce qui est un

problème de sécurité important.
  Docker-in-Docker entraîne généralement une pénalité de performance et peut
être assez lent

Utiliser les badges de Gitlab CI