Handbook GitLab ESR

1 - Bonnes pratiques Git

Bonnes pratiques d’utilisation de Git

Fonctionnement des dépôts

  • Faire des commits fonctionnels (un commit = une fonctionnalité) Cela facilitera la recherche de bugs.
  • Utiliser des branches pour les fonctionnalités et les corrections de bugs. Cela permettra de garder le code principal propre et stable.
  • Utiliser des étiquettes pour marquer les versions stables du code. Cela permettra aux utilisateurs de télécharger la version correcte du code.
  • Protéger la branche principale. Cela empêchera les modifications accidentelles.

En plus des dépôts

  • Mettre en place des pipelines CI/CD. Cela permettra d’automatiser les tests et les déploiements du code.
  • Documenter le code. Cela permettra aux autres développeurs de comprendre le fonctionnement du code.

Ressources git

  • Learning Git Branching pour apprendre les commandes importantes de git et visualiser leurs effets.
  • Git flow pour comprendre le rôle des branches main, develop et feature dans un projet git.
  • GitHub flow une version plus simple du lien précédent basée sur deux branches seulement.

2 - Intégration continue, déploiement continu

Ressources

3 - Configurations anti-bots

Utiliser les fonctionnalités de GitLab

Config iocaine pour gitlab

Contribué par Mathrice.

Tutoriel complet.

Config fail2ban

Contribuée par Remy Dernat

Fichier /etc/fail2ban/filter.d/gitlab-llm-bots.conf:

[Definition]
failregex = <HOST> -.* "GET .*" 403.* ".*(AmazonBuyForMe|Amzn-SearchBot|Amzn-User|Anomura|ApifyBot|ApifyWebsiteContentCrawler|Aranet-SearchBot|AzureAI-SearchBot|Bravebot|BuddyBot|Channel3Bot|ChatGLM-Spider|Cloudflare-AutoRAG|Crawl4AI|DeepSeekBot|ExaBot|Google-Agent|Google-Firebase|Google-NotebookLM|IbouBot|KlaviyoAIBot|KunatoCrawler|LAIONDownloader|LCC|LingueeBot|LinkupBot|Manus-User|NotebookLM|Poggio-Citations|ShapBot|Spider|TavilyBot|TerraCotta|TwinAgent|WRTNBot|ZanistaBot|amazon-kendra|atlassian-bot|iAskBot|imageSpider|laion-huggingface-processor|meta-webindexer|webzio-extended|Grok|DeepSeekBot|OAI-AdsBot|Microsoft-Copilot|Googlebot-Genie|Databricks-Agent|GPTBot|ChatGPT-User|AppleBot-Extended|ClaudeBot|Claude-SearchBot|PerplexityBot|Perplexity-User|Google-Extended|OAI-SearchBot|AmazonBot|Meta-ExternalAgent|Bytespider|cohere-ai|DuckAssistBot|FacebookBot|Gemini-User|MistralAI-User|YouBot|CCBot).*"
            
            # Alternative si le code statut n'est pas toujours présent ou si vous voulez juste capturer l'user-agent quel que soit le code
            # Note: On utilise <HOST> au début pour capturer l'IP, et on cherche la chaîne dans le User-Agent (généralement après le code HTTP ou à la fin)
            
            # Regex optimisée pour le format standard Nginx (Host - UserAgent [Date] "Request" Status "Referrer")
            ^<HOST> .+ ".*" .* ".*".*(AmazonBuyForMe|Amzn-SearchBot|Amzn-User|Anomura|ApifyBot|ApifyWebsiteContentCrawler|Aranet-SearchBot|AzureAI-SearchBot|Bravebot|BuddyBot|Channel3Bot|ChatGLM-Spider|Cloudflare-AutoRAG|Crawl4AI|DeepSeekBot|ExaBot|Google-Agent|Google-Firebase|Google-NotebookLM|IbouBot|KlaviyoAIBot|KunatoCrawler|LAIONDownloader|LCC|LingueeBot|LinkupBot|Manus-User|NotebookLM|Poggio-Citations|ShapBot|Spider|TavilyBot|TerraCotta|TwinAgent|WRTNBot|ZanistaBot|amazon-kendra|atlassian-bot|iAskBot|imageSpider|laion-huggingface-processor|meta-webindexer|webzio-extended|Grok|DeepSeekBot|OAI-AdsBot|Microsoft-Copilot|Googlebot-Genie|Databricks-Agent|GPTBot|ChatGPT-User|AppleBot-Extended|ClaudeBot|Claude-SearchBot|PerplexityBot|Perplexity-User|Google-Extended|OAI-SearchBot|AmazonBot|Meta-ExternalAgent|Bytespider|cohere-ai|DuckAssistBot|FacebookBot|Gemini-User|MistralAI-User|YouBot|CCBot).*$

ignoreregex =

Dans paths-common.conf rajouter :

gitlab_nginx_error_log = /var/log/gitlab/nginx/*error.log
gitlab_nginx_access_log = /var/log/gitlab/nginx/*access.log

Fichier /etc/fail2ban/jail.d/gitlab-llm-bots.conf :

[gitlab-llm-bots]
enabled = true
filter = gitlab-llm-bots
#logpath = /var/log/gitlab/nginx/gitlab_access.log
logpath = %(gitlab_nginx_access_log)s
maxretry = 1
findtime = 600
bantime = 86400

On teste avec

fail2ban-regex /var/log/gitlab/nginx/gitlab_access.log gitlab-llm-bots

puis

systemctl restart fail2ban.service

fail2ban-client status gitlab-llm-bots

tail -f /var/log/fail2ban.log | grep gitlab-llm-bots

4 - Configurer une instance GitLab

5 - Cycle de vie des projets

Création des projets

Archivage des projets

6 - Migrer vers de Mattermost omnibus à Mattermost Standalone

Contribué par Pablo Rauzy

Le tuto officiel est là : https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html

Bon, installer postgres, ça va. Ensuite, étape par étape :

Step 1 : pour que ça fonctionne correctement j’ai dû virer le “–owner” et mettre “-d” à la place.

sudo gitlab-psql -- /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql -d mattermost_production | gzip > mattermost_dbdump_$(date --rfc-3339=date).sql.gz

Step 2 : dans le sous-tuto de préparation de la base de donnée, en fait la commande “locale-gen” ignore complètement ses arguments, c’est dans /etc/locale.gen qu’il faut aller décommenter la ligne en_US.UTF-8 avant le lancer la commande. Et ce n’est pas précisé mais il faut bien s’arrêter dans le sous-tuto avant “File storage preparation”, ne faire que la partie “Database preparation”, sinon y a des commandes plus tard qui ne fonctionnent pas.

Step 3 : ce n’est pas dit mais dans le dump il y a plein de “ALTER … OWNER TO gitlab_mattermost” qui vont échouer, faut les récupérer après coup (avec zgrep par exemple) pour les effectuer quand même et remplacer “gitlab_mattermost” par “mmuser”, si on suit les noms du tutoriel de migration.

Step 4 : il faut faire l’étape 5 avant, sinon on a le choix de modifier un fichier de config qui n’existe pas et qu’on va écraser à l’étape d’après, ou de modifier un fichier de config de façon incohérente…

Step 5 :

5.1 : Le bon tuto est là : https://docs.mattermost.com/deployment-guide/server/deploy-linux.html Attention avec Mattermost 11 on a une limite d’utilisateurs ridiculement petite et on a plus le SSO sur le GitLab, si on veut conserver ça faut prendre la dernière version ESR de la v10. Pour ça faut juste remplacer la version à télécharger par “Mattermost Team Edition v10.11.20 Extended Support Release (ESR)” qu’on trouve ici : https://docs.mattermost.com/product-overview/version-archive.html Il faut faire les étapes 3 “Download” et 4 “Install Mattermost server” uniquement, et dans la 4 il ne faut pas faire l’étape 4.3 où ont créé le dossier “data”, ou si on le fait faire gaffe plus bas quand on sera de retour à l’étape 4 du tuto migration.

5.2 : si l’installation se fait sur le même serveur pas besoin de faire toute la danse avec /tmp et scp, et c’est possible de juste faire un mv plutôt que de cp (ce qui peut être long). Attention si on suit leur commande on peut se retrouver avec le dossier de données dans le dossier /opt/mattermost/data plutôt que ce dernier soit le dossier de données. Et le fichier de config de GitLab Mattermost n’est pas à l’emplacement indiqué… (un dossier “config” de trop dans le tuto). Ce que je recommande de faire c’est simplement les deux commandes suivantes :

sudo cp /var/opt/gitlab/mattermost/config.json /opt/mattermost/config/
sudo mv /var/opt/gitlab/mattermost/data /opt/mattermost/data

(pour nous le dossier /opt/mattermost/data n’existe pas donc c’est bon, mais si il existe comme devrait le supposer le tutoriel puisqu’on l’a créé en 4.3 du tuto d’installation qu’on a suivi à l’étape 5.1 du tuto migration, ne pas l’indiquer à la fin du chemin de destination, sinon on se retrouve avec un dossier data dans le dossier data).

5.3 : là c’est bon on peut suivre !

Retour à l’étape 4 !

Step 4 : Ce n’est dit nul part dans le tutoriel mais en plus de modifier la config DataSource pour pointer vers la nouvelle base de données, faut aussi modifier la config “Directory” pour pointer vers le nouveau dossier où il y a les data (pour mettre “/opt/mattermost/data” à la place de “/var/opt/gitlab/mattermost/data”.

Et voilà c’est… quasi terminé, avant de tout relancer faut quand même indiquer au nginx de GitLab que le nouveau Mattermost existe, et lui faire gérer les certificats, ce qui n’est dit nul part non plus… Pour ça (en remplaçant partout “MATTERMOSTDOMAIN” par votre domaine pour Mattermost et GITLABDOMAIN par votre domaine GitLab) :

Dans gitlab.rb :

gitlab_rails['mattermost_host'] = "https://MATTERMOSTDOMAIN"
letsencrypt['alt_names'] = [… 'MATTERMOSTDOMAIN']

(y a pas littéralement “…” c’est juste pour dire qu’il faut l’ajouter à la liste existante)

Et ajouter un fichier pour Mattermost dans /etc/gitlab/nginx/sites-available/

Chez moi par exemple :

server {
    server_name MATTERMOSTDOMAIN;

    location / {
        proxy_pass http://127.0.0.1:8065;
        client_max_body_size 100M;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_buffers 256 16k;
        proxy_buffer_size 16k;
        proxy_read_timeout 600s;
        proxy_http_version 1.1;
    }

    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    ssl_certificate /etc/gitlab/ssl/GITLABDOMAIN.crt;
    ssl_certificate_key /etc/gitlab/ssl/GITLABDOMAIN.key;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

Puis dans /etc/gitlab/nginx/sites-enabled/ mettre un lien symbolique vers ce fichier qui est dans ../sites-available/

Maintenant, tout relancer, le Mattermost standalone et le GitLab. Normalement tout devrait aller bien.

7 - Organisation des projets

Bonnes pratiques pour l’organisation de projets sur GitLab

Organisation des projets individuels

  • Utiliser des noms de dépôts clairs et descriptifs. Cela permettra aux utilisateurs de trouver facilement le dépôt qu’ils recherchent.
  • Structurer le dépôt de manière logique. Utilisez des sous-répertoires pour regrouper les fichiers associés.
  • Mettre en place des conventions de nommage cohérentes pour les fichiers et les branches. Cela facilitera la navigation dans le dépôt.
  • Rédiger des messages de commit clairs et concis. Cela permettra aux autres développeurs de comprendre les modifications apportées.

Organisation des projets par groupe

  • Utiliser des groupes pour regrouper les projets connexes. Cela permettra de mieux organiser les projets et de contrôler les autorisations.
  • Définir des autorisations au niveau du groupe et du projet. Cela permettra de contrôler qui peut accéder aux projets et aux données.
  • Utiliser des sous-groupes pour organiser les groupes. Cela permettra de créer une hiérarchie de groupes.
  • Créer des modèles de groupe pour définir les paramètres par défaut des nouveaux projets. Cela permettra de gagner du temps et de garantir la cohérence des projets.
  • Utiliser les fonctionnalités de gestion de portefeuille de projets de GitLab. Cela permettra de suivre l’avancement des projets et de prendre des décisions stratégiques.

En plus de ces bonnes pratiques, il est important de s’adapter aux besoins spécifiques de votre équipe et de votre projet. Il n’y a pas de solution unique pour tous, et la meilleure façon d’organiser vos projets GitLab est de trouver ce qui fonctionne le mieux pour vous.

Ressources

Voici quelques ressources supplémentaires qui pourraient vous être utiles :

8 - Ressources pédagogiques

Cette page regroupe des ressources pédagogiques sur les forges en général, des forges particulières, ou des composants spécifiques produites par des collègues.

Ressources d’Arnauld BIGANZOLI

Contact mail : biganzoli[at]laplace.univ-tlse.fr

Il s’agit de supports utilisés pour des enseignements à l’INSA de Toulouse.

N’hésitez pas à regarder dans les commentaires du présentateur (sous les slides), il y a plein d’info et de lien complémentaire pour approfondir le sujet :

Ressources CIRAD

Le CIRAD propose un ensemble de ressources concernant le fonctionnement de sa forge.

9 - Gestion des utilisateurs

Ressources