Git/GitLab — Wikilivres

Windows

GitHub

GitLab est une forge logicielle open-source lancée en 2011.

Git

Principes
Apprendre à travailler avec Git
Fonctionnalités avancées
Recettes
- Exclure des fichiers du dépôt
- Écrire des messages de commit
Environnement
Git et Subversion (svn)
Problèmes connus
Ressources externes

Version imprimable

[ Modifier le sommaire ]

Windows

GitHub

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/CD Modifier

GitLab CI/CD est un outil d'intégration continue et de déploiement continue^[1], fourni avec la forge logicielle Gitlab.

Exemple de pipelines

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

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

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

stages:
  - build

build-code:
  stage: build
  script:
    - echo "Hello World!"
    - pwd; ls -alh

before_script Modifier

Script à exécuter avant chaque job.

variables Modifier

Variables appelables plusieurs fois au sein du .gitlab-ci.yml. Certaines permettent de configurer le comportement de GitLab CI. Exemple :

GIT_STRATEGY Modifier

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

Définit la profondeur lors du clone du dépôt : shallow clone^[3].

Dans un job Modifier

stage Modifier

Étape qui lancera le job.

script Modifier

Script à lancer.

only Modifier

Liste des branches où le job peut s'exécuter (lors des merges).

Exemple complexe Modifier

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

Vérifier les valeurs des variables^[4] :

build-code:
  stage: build
  script:
    - export

Importation Modifier

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

Liste des runners.

Déploiement de test à chaque Merge Request Modifier

À 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

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

image: docker:latest

Via Docker-compose Modifier

Utile en cas de communication entre plusieurs conteneurs.

image: docker/compose:1.27.4

Via Kaniko Modifier

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

Voir aussi Modifier

Jenkins