Je ne suis pas expert pipeline gitlab mais on utilise ça depuis 2 ans dans l'équipe je peux déjà te donner des billes. Mais le mieux c'est qe tu te monte une VM et un projet de test type hello world pour voir si tu arrives à faire ce que tu veux, ça se fait assez vite.
1) Déjà est-ce que le runner c'est un container Docker ou est-ce juste l'agent installé sur le serveur (par exemple le serveur web qui va recevoir une nouvelle livraison)
non le runner n'est pas un container, j'ai pas trop testé ce mode, moi je l'utilise en mode shell dans ce cas ton process est éxécuté sur la machine où le runner est installé. ca me convient bien.
et qui scrute le repo git (donc l'origine) en l'attente d'un push ?
Non c'est l'inverse c'est gitlab qui déclanche l'utilisation du runner, par exemple, chez nous c'est configurer pour ne généré une release qu'à chaque tag.
2) J'ai lu que le "script" ou les stages contenu dans le .gitlab-ci.yml s'éxécutent à chaque commit de code. Est-ce que ça veut dire que Gitlab indique à la machine d'où est partie le commit d’exécuter le contenu du .gitlab-ci.yml ?
oui
3) Qu'est-ce qu'on appelle pipeline ? Est-ce un Job ? Un ensemble de Job strictement défini ? L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml ?
L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml en gros tu as une étape build / test / preprod / prod il y a même possibilité d'avoir un bouton pour basculer d'une étape à l'autre
4) Si j'ai bien compris il ne peut y avoir qu'un seul .gitlab-ci-yml par branche git ?
Donc si j'ai 5 environnements différents (par ex LOCAL, TEST, DEV, STAGING, PROD) et que je veux un déploiement entièrement automatique et changer quelques détails en fonctione de l'environnement jusqu'en STAGING il faut que j'organise mon projet en 5 branches différentes avec chacune un fichier .gitlab-ci-yml ?
Non, il faut que ton .gitlab-ci-yml gère toutes ces étapes les unes après les autres
5) Qu'est-ce qui se passe à l'issue d'une merge request si par exemple je veux merger la branche STAGING vers la branche PROD ? Est-ce que ma branche STAGING continue d'exister et son .gitlab-ci-yml reste inchangé? Ou disparait elle ? En d'autre termes est-ce qu'une MR c'est seulement le remplacement du contenu de ma branche PROD par celui de la branche STAGING par une sorte de rm -rf prod/ et cp -R STAGING/ PROD/ ?
# Pioufff
Posté par MrBidon . En réponse au message Fonctionnement des Gitlab runner et pipeline. Évalué à 1. Dernière modification le 21 février 2020 à 15:33.
Je ne suis pas expert pipeline gitlab mais on utilise ça depuis 2 ans dans l'équipe je peux déjà te donner des billes. Mais le mieux c'est qe tu te monte une VM et un projet de test type hello world pour voir si tu arrives à faire ce que tu veux, ça se fait assez vite.
non le runner n'est pas un container, j'ai pas trop testé ce mode, moi je l'utilise en mode shell dans ce cas ton process est éxécuté sur la machine où le runner est installé. ca me convient bien.
Non c'est l'inverse c'est gitlab qui déclanche l'utilisation du runner, par exemple, chez nous c'est configurer pour ne généré une release qu'à chaque tag.
oui
L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml en gros tu as une étape build / test / preprod / prod il y a même possibilité d'avoir un bouton pour basculer d'une étape à l'autre
Non, il faut que ton .gitlab-ci-yml gère toutes ces étapes les unes après les autres
C'est plutôt un comprégension de git qu'il te faut et non de gitlab, on a discuté d'un sujet similaire, il y a pas longtemps ici : https://linuxfr.org/forums/programmation-php/posts/branches-git
Bon courage :)