Hudson, GIT/Github et iptables sont sur un bateau

Comme annoncé dans le précédent billet, je vais avoir à installer différentes « choses » pour mon nouveau projet. Sens du partage oblige, voici quelques trucs et astuces (d’autres devraient arriver).

Ayant décidé d’assurer l’intégration continue avec Hudson, je me suis attelé à l’installation de ce dernier sur un serveur dédié Ubuntu chez OVH. Le serveur étant déjà en production et sécurisé avec iptables, j’ai du affronter quelques problèmes. Ne vous attendez pas à une installation step-by-step comme cela à été le cas pour le MAMP, mon époque réseau est révolue (Gentoo <3), je découvre beaucoup de choses d’un coup et un tuto d’installation ne serait pas forcément pertinent.

Etape 1 : l’installation d’Hudson

J’ai essayé d’installer Hudson de deux façons différentes : la première en utilisant la version hudson avec un « apt-get install hudson » et la second à travers un serveur tomcat6 et l’ajout du fichier hudson.war

Rien de spécial à ce niveau, contentez-vous de suivre les procédures classiques d’installation. Il faudra cependant autoriser le serveur Hudson à parler avec l’extérieur en ajoutant une entrée dans iptables :

$ sudo iptables -A INPUT -p tcp -i eth0 -s <votre ip publique> --dport 8080 -j ACCEPT

Etape 2 : Premier problème avec Hudson

Une fois votre serveur lancé « sudo /etc/init.d/hudson start » votre serveur devrait théoriquement vous afficher quelque chose comme « Merci d’attendre que Hudson soit prêt… » Vous pouvez attendre un petit peu ou trois heures comme moi.

- Toc Toc!
- Qui est la ?
...
...
...
...
Java !

Le problème découle directement du fait que les version de Hudson à partir de la build 1.359 utilise le multicast. Il faut donc l’activer sur iptables :

$ sudo iptables -A INPUT -p igmp  -j ACCEPT
$ sudo iptables -A OUTPUT -p igmp  -j ACCEPT

Et si ça ne fonctionne pas (comme chez moi en fait), descendez à la build 1.358 – parce que oui, la je suis vaincu.

Etape 3 : Git

Donc votre serveur Hudson tourne et vous accédez au dashboard. Installer les plugins GIT via la gestion des plugins à savoir le « Hudson Git plugin » et le « Github Plugin ». Une fois installé, une configuration de GIT est nécessaire.

Dans la configuration générale du système, ajouter une installation GIT baptisée « default » avec comme path pour l’executable « git » puis enregistrer.

Dans la configuration du projet, cela se complique un peu suivant ce que vous voulez faire à savoir dans mon cas :

le développeur push vers un repository local « git bare » dans un répertoire /var/git/NomDuProjet.git
hudson lance sa compilation et fais ses tests
hudson push sur un repository github

Iptables oblige, il va encore falloir ajouter une entrée pour échanger sur le port utilisé par Git.

$ sudo iptables -A OUTPUT -p tcp --dport 9418 -j ACCEPT

Hudson étant plutôt capricieux vis à vis de GIT, il faut ensuite configurer le user.email et le user.name par projet. Normal.

$ git config user.email "some@email.com"
$ git config user.name "hudson"

Cela permettra d’éviter de se faire jeter parce que monsieur Hudson chercher à s’authentifier comme anonyme.

Concernant la configuration maintenant, dans votre projet. Ajouter deux repositories pour GIT en nommant le repository comme si vous ajoutiez un remote (pour plus de facilité). Ce qui donne dans mon cas :

URL of repository : git@github.com:pocky/test.git
Name of repository (blank to create default) : github
Refspec (blank to create default) : +refs/heads/*:refs/remotes/origin1/*

URL of repository : /var/git/test.git
Name of repository (blank to create default) : origin
Refspec (blank to create default) : +refs/heads/*:refs/remotes/origin1/*

Branch Specifier (blank for default): master

Ensuite configurer le Git Publisher (en bas de page) dans la partie Branches :

Branch to push : master
Target remote name : github

Ce qu’il va se passer : Lors d’un build, Hudson va d’abord chercher à rapatrier toutes les changements depuis les différents repositories puis va lancer son build et en cas de réussite faire un push vers github. Pour un meilleur échange lors du premier build, je vous conseil de créer un fichier sur votre ordinateur puis de push vers votre remote de preprod (le serveur hudson) et votre remote github. Cela évitera à Hudson de vous renvoyer un message d’erreur lors du fetch.

Pour tester la connexion vers github après la configuration complète, rien de bien compliqué :

$ sudo su - hudson
$ ssh git@github.com

Vous saurez tout de suite si il existe un problème ou non. Si un problème de connexion vis à vis de git survient, cela provient sûrement de vos clés ssh. Il faut les rajouter dans le repertoire home de hudson dans un repertoire .ssh (qu’il faudra créer) via la procédure standard de création de clé ssh (ssh-keygen et tutiquanti). Il faudra ensuite faire prendre en compte les modifications en redémarrant la session utilisateur Hudson ou en redémarrant le serveur.

Et la on pourrait croire que c’est terminé. Mais non.

Lorsque vous allez essayer de build, Hudson va vous claquer entre les doigts à cause des submodules (malgré le fait que la connexion soit bonne). Le problème vient apparemment du fait d’utiliser « git:// ». Il va falloir aller dans le fichier « .git/config » et changer tous vos « git:// » par « http:// » et tant que vous y êtes dans le fichier « .gitmodules ». Bien entendu, si cela a été fait en amont, c’est bon.

Vous n’avez plus qu’à relancer, ça fonctionne, c’est magique et vous aurez économisé une trentaine de build en échec. Merci qui ? Merci bibi !