Discussion :

[Elodie11]

Bonjour,

C'est une question très générale que j'ai à poser.

Nous sommes une équipe de développement de plugin Eclipse, nous générons donc des .product avec Tycho.
Notre projet contient à sa racine les dossiers suivants :
- Plugins
- Documents
- Features
- Repository

Ma question est : est-ce pertinent d'avoir un job pour la compilation de l'intégralité du projet ET un job pour le premier plugin ET un job pour le second ET un job pour la première feature, etc. ?

Si oui, je ne vois pas comment résoudre les dépendances : en effet mon plugin 1 dépend du plugin 2. Comment exprimer que s'il y a une modification dans le premier projet il faut qu'il lance le job associé au plugin 2 puis celui associé au plugin 1.
De même ma feature est basé sur les plusieurs plugins, comment exprimer qu'il faille d'abord compiler plugin 3, puis 2, puis 1 puis la feature ?

Merci,

Elodie

[romaintaz]

Bonjour,

Si ton premier build réalise la compilation de tous tes plugins, pourquoi en ajouter d'autres pour gérer séparément les plugins ?

La séparation des jobs n'a à mon avis de sens que si le build complet prend trop de temps, car plus une exécution est rapide, plus elle est utile (on a des retours plus rapides en cas de problèmes).
Une chose aussi : si tu utilises Maven 3, tu peux activer dans les options Maven le "build incrémental". Ainsi, Maven ne compilera que les modules ayant changé depuis la fois d'avant, évitant de recompiler tout l'ensemble.

Sinon, pour ton information, tu peux ordonner les builds dans Jenkins. Dans les "Actions post-build", tu as "Construire un autre projet". Il te suffit par exemple de configurer le plugin 1 pour qu'il démarre le plugin 2 une fois terminé.

[Elodie11]

Je pensais créer un job complet + des jobs pour chaque plugin afin que cela soit plus visible sur le tableau de bord et voir plus rapidement lequel est souvent en erreur, instable, etc.
Est-ce idiot ?

[romaintaz]

Ce n'est pas forcément idiot, c'est juste que le job global est un peu redondant avec le reste, surtout que ce dernier n'offre finalement pas d'informations supplémentaires par rapport aux autres jobs. Dans cette configuration, toute erreur sur un commit va entraîner 2 mails au(x) développeur(s) concerné(s) : 1 par le job du module, un autre par le job global.

Rien ne t'empêche de faire un job par module (avec leurs dépendances de build comme je l'avais expliqué), puis un job global qui ne sera lancé qu'une fois par jour, durant la nuit, où tu en profiteras par exemple pour lancer une analyse qualité avec Sonar...