# Git/GitLab

* Principes
* Apprendre à travailler avec Git
** Avant de commencer : installation et configuration de Git
** Création de votre dépôt local
** Visualiser le contenu de votre dépôt local
** Premiers pas
** Gestion des branches
** Synchroniser le dépôt local avec le dépôt distant
* Fonctionnalités avancées
** Étiquetage (tags)
** Remise (stash)
** Recombinaison (rebase)
** Sous-modules et Super-projets
** Structure interne
** Pull-request
* Recettes
** Exclure des fichiers du dépôt
** Écrire des messages de commit
* Environnement
** Intégration dans les IDEs
** Améliorer sa productivité en configurant Git
** Git sous Linux
** Git sous Windows
** Forges
*** GitLab
*** GitHub
*** Bitbucket
* Git et Subversion (svn)
** Passer de Subversion à Git
** Travailler avec Git local et un dépôt Subversion distant
** Participer au développement de Wikimédia (Gerrit)
* Problèmes connus
* Ressources externes
* Principes
* Apprendre à travailler avec Git
** Avant de commencer : installation et configuration de Git
** Création de votre dépôt local
** Visualiser le contenu de votre dépôt local
** Premiers pas
** Gestion des branches
** Synchroniser le dépôt local avec le dépôt distant
* Fonctionnalités avancées
** Étiquetage (tags)
** Remise (stash)
** Recombinaison (rebase)
** Sous-modules et Super-projets
** Structure interne
** Pull-request
* Recettes
** Exclure des fichiers du dépôt
** Écrire des messages de commit
* Environnement
** Intégration dans les IDEs
** Améliorer sa productivité en configurant Git
** Git sous Linux
** Git sous Windows
** Forges
*** GitLab
*** GitHub
*** Bitbucket
* Git et Subversion (svn)
** Passer de Subversion à Git
** Travailler avec Git local et un dépôt Subversion distant
** Participer au développement de Wikimédia (Gerrit)
* Problèmes connus
* Ressources externes
[ Modifier le sommaire ]
GitLab est une forge logicielle open-source lancée en 2011.
Elle fournit une interface graphique pour créer des branches, des tags, des pull requests (appelées merge requests, alias MR ou PR), 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.

## Merge requests

Des commentaires du code à relire, contenant éventuellement des propositions de modifications applicables en un clic sont possible. Leur syntaxe est le Markdown.
On peut par exemple y afficher des images, redimensionnées. Ex :

## CI/CD

GitLab CI/CD est un outil d'intégration continue et de déploiement continue, 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, création de tag, ou clique sur le job à lancer).
Ces jobs peuvent être lancés dans un certain ordre ou en parallèle, selon les étapes (stages) auxquelles ils appartiennent.

### IHM

Dans le menu de gauche de GitLab, cliquer sur :
* "Build" pour voir les tâches qui se lancent sur les serveurs "runners" :
** Pipelines : liste des groupes de jobs déjà lancés sur le dépôt.
** Jobs : liste de tous les jobs.
** Pipeline editor : éditeur en ligne du fichier .gitlab-ci.yml du dépôt. Il s'agit du fichier versionné contenant la configuration des pipelines.
** Pipeline schedules : gestion des tâches planifiées.
** Artifacts
* Settings : accessible uniquement aux propriétaires du repo, pour configurer par exemple les branches protégées ou les conditions de fusion des merge requests.

### .gitlab-ci.yml

Pour qu'un pipeline se lance par hook dans un dépôt, il doit contenir un fichier .gitlab-ci.yml à la racine.

#### before_script

Script à exécuter avant chaque job.

#### variables

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

##### GIT_STRATEGY

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.
La valeur par défaut est définie dans l'IHM : /settings/ci_cd.

##### GIT_DEPTH

Définit la profondeur lors du clone du dépôt : shallow clone.

##### CI_PIPELINE_SOURCE

Origine du pipeline (ex : push, merge, tâche planifiée, clic sur le job...).

#### Dans un job
##### stage

Étape qui lancera le job.

##### script

Script à lancer.

##### rules

Conditions pour déclencher ou interdire le job courant.
Cette clause est préconisée car plus complète, par rapport à "only" et "except" qui servent lister des branches où le job peut s'exécuter ou pas (lors des merges).

##### dependencies

Définit les jobs ont on récupère les artefacts pour le courant.

##### needs

Noms des étapes obligatoires avant.

##### parallel: matrix

Type de needs définissant des jobs à exécuter en parallèle.

##### parent et child

Jobs à exécuter dans un sous-graphe.

##### include

Inclut un .yaml de CI (local ou distant). Ce qui permet par exemple de le construire avant de l'exécuter depuis un autre job.

##### trigger

Pour déclencher une action, par exemple un "include" ou un job d'un autre projet.

#### Exemple complexe

Voici le squelette d'un pipeline complet, dans lequel il faudrait remplacer les echo par les vraies opérations :

#### Debug

Vérifier les valeurs des variables :

#### Importation

Il est possible d'incorporer des tâches de GitLab dans le pipeline, par exemple pour la sécurité :

### Déploiements
#### Lancement de tests à chaque Merge Request

À chaque Merge Request, 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".
Les runners peuvent être fournis par GitLab ou installés soi-même. Dans ce cas leur configuration se trouve dans un fichier .toml.
Une fois l'évènement GitLab déclenché, la commande pour déployer dépend de l'environnement cible. Par exemple pour Kubernetes, un curl peut-être utilisé.

#### À partir d'une image Docker du registre

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-compose

Utile en cas de communication entre plusieurs conteneurs.

##### Via Kaniko

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.

## Références

* ↑ 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

## Voir aussi

* Jenkins