gitlab

Installation d’un package npm depuis un dépôt GitLab

Pour utiliser un dépôt hébergé sur sa propre instance GitLab, rien de bien compliquer, si ce n’est le protocole à utiliser : git+https et pas juste https (ou git+http au lieu de http).

Ce qui nous donne pour la branche master d’un projet :

{
  ...
  "dependencies": {
    "mon-projet": "git+https://<mon-domaine-gitlab>/<user>/<mon-projet>#master",
    ...
  }
}

Illustration pour récupérer une configuration eslint sous forme de module dans son dépôt propre :

{
  ...
  "devDependencies": {
    "eslint-config-unicoda": "git+https://gitlab.unicoda.com/vvision/javascript-convention#master",
    ...
  }
}

Redis-server 2.8 sur Debian 7 Wheezy

La version 8.3 de Gitlab nécessite une mise à jour de redis car celle-ci se base sur redis-server en version 2.8. Problème, ce composant n’est pas disponible par défaut pour Debian Wheezy. Deux solutions possibles, mettre à jour Debian vers Debian Jessie avec tous les risques que cela comporte (init.d -> systemd, apache2.2 -> apache2.4, etc…) ou compiler le composant à partir des sources. Pour ma part, j’ai donc choisi la troisième solution : utiliser le dépôt backport wheezy qui par chance propose redis-server dans la version qui m’intéresse !

Pour commencer, on ajoute la ligne suivante dans le fichiers /etc/apt/sources.list du système :

deb http://ftp.debian.org/debian wheezy-backports main

On met à jour les dépôts :

apt-get update

On peux ensuite passer à l’installation :

apt-get -t jessie-backports install redis-server

Il sera nécessaire de faire un choix entre votre configuration locale et la configuration en provenance du paquet. Ici, pas le choix en regardant le diff entre les deux fichiers, il faut absolument prendre la nouvelle version.

Cela nécessite néanmoins de ré-appliquer la configuration de redis pour Gitlab comme décrit dans le paragraphe redis de la doc d’installation à partir de « Configure redis to use sockets« .

Pour vérifier la version de redis installée, on aura utilisé au préalable la commande :

redis-cli info | grep redis_version

Échec de sauvegarde Gitlab et objets LFS

Lors d’une récente sauvegarde du contenu de mon Gitlab en vue d’une mise à jour, j’ai vu apparaître une erreur déjà rencontrée lors d’une précédente sauvegarde.

rake aborted!
Errno::ENOENT: No such file or directory @ realpath_rec - /home/git/gitlab/shared/lfs-objects

N’ayant pas à ma connaissance d’objets LFS à sauvegarder, j’ai donc ajouter un paramètre pour éviter la tentative de sauvegarde de ces objets avec SKIP=lfs. On obtient donc la commande suivante :

sudo -u git -H bundle exec rake gitlab:backup:create SKIP=lfs RAILS_ENV=production

Maj : Ce problème est résolu à partir de Gitlab 8.3.

La migration de nos différents services s’effectue progressivement. Après WordPress, c’est au tour de notre système de gestion de code de changer de serveur et d’évoluer par la même occasion. Jusqu’à présent, nous utilisions Gitolite. Celui-ci fonctionne plutôt bien, une fois qu’on a trouvé les bonnes configurations. Pour une utilisation personnelle sous GNU/Linux, aucun problème, mais pour inviter d’autres contributeurs ce n’est pas toujours très simple. Entre la génération des clefs, la mise en place des bons fichiers de configuration sous Windows et l’obligation de gérer à la main les autorisations et créations de dépôts, j’ai décidé de passer à quelque chose de plus conséquent: Gitlab.

Les avantages sont nombreux: interface facilitant la gestion des dépôts et accessible à tous les utilisateurs, gestion fine du nombre de dépôts maximum pour chaque utilisateur, la création de dépôts n’est pas limité à l’administrateur et surtout, la possibilité de cloner un dépôt directement via http. Autant d’avantages qui m’ont incité à tenter l’installation de la bête.

La mise en place se déroule sans réels difficultés grâce à un guide d’installation pas à pas. Chaque étape est décrite en détails et toutes les commandes sont commentées, bref la navigation dans ce guide s’effectue sans écueils.

Le guide se termine par la configuration de Nginx pour permettre aux utilisateurs d’accéder au service. Si comme moi, vous utilisez plutôt Apache, pas de panique, des fichiers de configuration pour Apache sont également disponible. Pas grand chose à dire sur ce point là, à part de ne pas oublier d’activer les modules listés au début des fichiers via a2enmod.

La dernière étape, consiste à faire fonctionner la connexion sécurisée à tous les niveaux. Quelques recherches reste à faire de ce côté là pour s’assurer que git accepte mon certificat auto-signé. Des paramètres à modifier dans gitlab-shell entre autre.

Nous sommes maintenant près pour l’étape finale, pusher du code et mettre à disposition notre gitlab pour les amis, connaissances et autres!