dépôts git

Published: 05-08-2015

Updated: 21-11-2016

By: Maxime de Roucy

tags: git gitolite

gitolite permet de créer simplement des dépôts git avec accès restraint.

dépôts public

Sources :

Gitolite permet de créé des dépôts en lecture écriture avec accès restraint. Pour créé des dépôts lisible par n’importe qui (mais pas writable par n’importe qui) je recommande d’utiliser git daemon. Voire de coupler ça avec un xinetd ou une socket systemd si votre dépôts est rarement utilisé.

Pour indiquer au démon quel sont les dépôt à partager publiquement vous devez créé dans les répertoire correspondant à ces dépôts le fichier git-daemon-export-ok. Vous pouvez les créer à la main mais gitolite peut le faire pour vous.

Pour qui gitolite créé le fichier git-daemon-export-ok vous devez, via le dépôt gitolite-admin, donné au dépôt les droits en lecture à l’utilisateur daemon. C’est un utilisateur « virtuel », il ne doit pas posséder de clé ssh.

gitolite

umask

Par défaut gitolite utilise un umask de 0077 pour créé les dépôts. Ça peut posser problème lorsqu’on veut faire un déploiement du dépôt. Pour résoudre le problème on peut utiliser la commande umask dans le script de hook ou modifier cette propriété de gitolite via le fichier ~git/.gitolite.rc.

En locale

Source : help for emergencies sur la documentation officiel de gitolite.

Il est possible mais déconseillé de travaillé en local sur le serveur. Ça peut permettre de modifier des dépôts sans pour autant avoir les droits dessus ☺.

Le seul point spécifique est l’utilisation de gitolite push pour pousser les modifications sur le dépôt. Les actions sont à effectuer avec l’utilisateur git (celui qui gère les dépôts gitolite). Par exemple pour modifier le dépôts gitolite-admin en locale sur le serveur :

git@serveur % git clone ~/repositories/gitolite-admin.git
git@serveur % cd gitolite-admin
git@serveur % … bidouille …
git@serveur % git commit …
git@serveur % gitolite push

anciennes versions

La dernière fois j’ai voulu modifier un dépôt gitolite sur une debian 6 (squeeze)… la commande gitolite n’existait pas. La version 1.5.4-2+squeeze1 de gitolite était installée.

J’ai essayé en faisant juste un export de la variable d’environnement GL_BYPASS_ACCESS_CHECKS, car c’est ce que fait gitolite push mais ça n’a pas fonctionné.

git@server % export GL_BYPASS_ACCESS_CHECKS=1
git@server % git push

J’ai été voir dans le fichier de hook ~git/repositories/gitolite-admin.git/hooks/update et j’ai cherché « bypass ». Victoire ! enfin c’est ce que je croyais… Il est indiqué en commentaire qu’un utilisateur local peut utiliser GL_BYPASS_UPDATE_HOOK pour ne pas se faire jeter au moment de l’authentification. Mais le git push échoue même après la l’export de la variable.

git@server % cd …/clone-temporaire
git@server % export GL_BYPASS_UPDATE_HOOK=1
git@server % git push
…
remote: hooks/post-update: 18: /gl-compile-conf: not found
…

Il s’agit du hook post-uptade, en regardant un peut dedans je m’aperçois qu’il manque certaines variable d’environnement. Le scripte à fait un checkout de la branch master du dépôts, non pas dans le dossier ~git/.gitolite comme il aurait dû mais dans directement dans le répertoire du dépôt. En gros j’aurai pu tous casser ☺. Pour réparer, j’ai juste supprimé les dossiers conf et keydir qui sont les deux seuls éléments du working tree et j’ai désactivé le dernier commit pour pouvoir refaire un push propre.

git@server % cd ~git/repositories/gitolite-admin.git
git@server % rm -r conf keydir
git@server % git log
…
git@server % git update-ref …

Après avoir été voir le fichier de hook ~git/repositories/gitolite-admin.git/hooks/post-update j’ai compris qu’il manquait deux autres variable d’environnement GL_BINDIR qui indique à gitolite où trouver le script gl-compile-conf et GL_ADMINDIR qui indique où faire le checkout du working tree.

git@server % cd …/clone-temporaire
git@server % export GL_BYPASS_UPDATE_HOOK=1
git@server % export GL_BINDIR=/usr/share/gitolite
git@server % export GL_ADMINDIR=$HOME/.gitolite
git@server % git push