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.

GitLab ne permet pas de créer de nouveaux groupes d'utilisateurs (les quatre possibles sont ceux par défaut), mais on peut inviter une personne sur un dépôt avec un autre groupe que celui qu'elle a ailleurs. Et il gère aussi des groupes d'applications dans lesquels un utilisateur peut avoir les mêmes droits.
CI/CDModifier
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.
IHMModifier
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.ymlModifier
Pour qu'un pipeline se lance par hook dans un dépôt, il doit contenir un fichier .gitlab-ci.yml à la racine.
Exemple simpleModifier
stages:
- build
build-code:
stage: build
script:
- echo "Hello World!"
- pwd; ls -alh
before_scriptModifier
Script à exécuter avant chaque job.
variablesModifier
Variables appelables plusieurs fois au sein du .gitlab-ci.yml. Certaines permettent de configurer le comportement de GitLab CI. Exemple :
GIT_STRATEGYModifier
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_DEPTHModifier
Définit la profondeur lors du clone du dépôt : shallow clone[3].
Dans un jobModifier
stageModifier
Étape qui lancera le job.
scriptModifier
Script à lancer.
onlyModifier
Liste des branches où le job peut s'exécuter (lors des merges).
Exemple complexeModifier
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
DebugModifier
Vérifier les valeurs des variables[4] :
build-code:
stage: build
script:
- export
ImportationModifier
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éploiementsModifier
Déploiement de test à chaque Merge RequestModifier
À 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 registreModifier
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 DockerModifier
image: docker:latest
Via Docker-composeModifier
Utile en cas de communication entre plusieurs conteneurs.
image: docker/compose:1.27.4
Via KanikoModifier
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érencesModifier
- ↑ 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