Git/GitLab
GitLab est une forge logicielle open-source. Elle fournit une interface graphique pour créer des branches, des tags, des pull requests (appelées merge requests), les relire et les fusionner.
CI/CD[modifier | modifier le wikicode]
GitLab CI/CD est un outil d'intégration continue et de déploiement continue[1], fourni avec la forge logicielle Gitlab.
Un pipeline est un ensemble de jobs déclenché automatiquement après différentes actions manuelles (git push, création de merge request, merge de branche, ou création de tag). Ces jobs peuvent être lancés dans un certain ordre ou en parallèle, selon les étapes (stages) auxquelles ils appartiennent.
IHM[modifier | modifier le wikicode]
Dans le menu de gauche de GitLab, cliquer sur CI/CD pour voir les options :
- Pipelines : liste des groupes de jobs déjà lancés sur le dépôt. On peut les y relancer.
- Editor : éditeur en ligne du fichier .gitlab-ci.yml du dépôt. Il s'agit du fichier versionné contenant la configuration des pipelines.
- Jobs : liste de tous les jobs.
- Schedules : gestion des tâches planifiées.
.gitlab-ci.yml[modifier | modifier le wikicode]
Pour qu'un pipeline se lance par hook dans un dépôt, il doit contenir un fichier .gitlab-ci.yml à la racine.
Exemple simple[modifier | modifier le wikicode]
stages:
- build
build-code:
stage: build
script:
- echo "Hello World!"
- pwd; ls -alh
before_script[modifier | modifier le wikicode]
Script à exécuter avant chaque job.
variables[modifier | modifier le wikicode]
Variables appelables plusieurs fois au sein du .gitlab-ci.yml. Certaines permettent de configurer le comportement de GitLab CI. Exemple :
GIT_STRATEGY[modifier | modifier le wikicode]
Politique de clonage :
- none : pas de clone (ex : si on utilise une image Docker).
- fetch : clone différentiel depuis le dernier.
- clone : clone à partir de zéro[2].
La valeur par défaut est définie dans l'IHM : /settings/ci_cd.
GIT_DEPTH[modifier | modifier le wikicode]
Définit la profondeur lors du clone du dépôt : shallow clone[3].
Dans un job[modifier | modifier le wikicode]
stage[modifier | modifier le wikicode]
Étape qui lancera le job.
script[modifier | modifier le wikicode]
Script à lancer.
only[modifier | modifier le wikicode]
Liste des branches où le job peut s'exécuter (lors des merges).
Exemple complexe[modifier | modifier le wikicode]
Voici le squelette d'un pipeline complet, dans lequel il faudrait remplacer les echo par les vraies opérations :
stages:
- build
- test
- publish
- deploy
build:
stage: build
script:
echo 'Build'
except:
refs:
- tags
quality-check:
stage: test
script:
echo 'Quality check'
variables:
GIT_STRATEGY: clone
GIT_DEPTH: 1
tags:
- docker
only:
- branches
except:
refs:
- tags
- master
- develop
run-test:
stage: test
script:
echo 'Tests'
variables:
GIT_STRATEGY: clone
GIT_DEPTH: 1
tags:
- docker
only:
- branches
except:
refs:
- tags
- master
- develop
publish:
stage: publish
script:
echo 'Publish artefact'
variables:
GIT_STRATEGY: none
tags:
- docker
only:
- master
- develop
deploy:
stage: deploy
script:
echo 'Deploy artefact on merge in master'
rules:
- if: $CI_COMMIT_BRANCH == "master"
when: on_success
Debug[modifier | modifier le wikicode]
Vérifier les valeurs des variables[4] :
build-code:
stage: build
script:
- export
Importation[modifier | modifier le wikicode]
Il est possible d'incorporer des tâches de GitLab dans le pipeline, par exemple pour la sécurité :
sast:
before_script: []
stage: test
include:
- template: Security/SAST.gitlab-ci.yml
Déploiements[modifier | modifier le wikicode]
Déploiement de test à chaque Merge Request[modifier | modifier le wikicode]
À chaque Merge Request (alias Pull Request, ou PR, ou MR), un job est créé pour lancer les instructions du .gitlab-ci.yml dans l'ordre. Mais avant de se lancer, il doit attendre la disponibilité d'un serveur de test sur lequel s'exécuter, appelé "runner"[5].
Les runners peuvent être fournis par GitLab ou installés soi-même. Dans ce cas leur configuration se trouve dans un fichier .toml.
À partir d'une image Docker du registre[modifier | modifier le wikicode]
Le principe consiste à envoyer une image Docker dans le registre GitLab pour que les conteneurs puissent l'utiliser ensuite sans avoir à le reconstruire.
$CI_REGISTRY_IMAGE représente l'URL du registre, ex : https://registry.gitlab.com/mon_espace.
Via Docker[modifier | modifier le wikicode]
image: docker:latest
Via Docker-compose[modifier | modifier le wikicode]
Utile en cas de communication entre plusieurs conteneurs.
image: docker/compose:1.27.4
Via Kaniko[modifier | modifier le wikicode]
Si les conteneurs déployés le sont dans un autre conteneur, cela peut occasionner des problèmes de performances. Kaniko est un système pour éviter cela[6].
image: name: gcr.io/kaniko-project/executor:debug
Références[modifier | modifier le wikicode]
- ↑ https://docs.gitlab.com/ee/ci/
- ↑ https://docs.gitlab.com/ee/ci/runners/configure_runners.html#git-strategy
- ↑ https://docs.gitlab.com/ee/ci/large_repositories/
- ↑ https://docs.gitlab.com/ee/ci/variables/#list-all-environment-variables
- ↑ https://docs.gitlab.com/runner/
- ↑ https://docs.gitlab.com/ee/ci/docker/using_kaniko.html