new Blog( perso );

Le point fort de Jenkins c'est son incroyable écosystème de plugins. Le système est entièrement bâti sur des points d'extensions et de nombreux composants qui viennent y contribuer.

Un soucis que je rencontre parfois chez des clients c'est qu'un plugin apporte une fonctionnalité intéressante, mais aussi une implémentation d'un point d'extension qui s'avère contre-productive dans un contexte spécifique.

Exemple avec JENKINS-15440 : le plugin subversion contribue au point d'extension "MailAddressResolver" en cherchant dans les projets SVN de l'instance si l'un d'eux pointerait vers sourceforge ou java.net, ce qui permet de déduire l'e-mail du committer. On sent l'idée initiale, mais sur une grosse instance Jenkins d'entreprise :

1. le code n'est jamais sur sourceforge ou java.net. D'ailleurs de nos jours plus personne n'utilise ces services, ce code est donc purement là pour garantir la compatibilité
2. ce parcours de tous les projets pénalise les performances sur une instance avec des centaines de jobs.

La solution ? Ne pas utiliser subversion et le plugin associé ! C'est d'ailleurs pour cela qu'on ne l'intègre pas dans Jenkins Enterprise - non je déconne, c'est à cause de la license de svnkit.

Il y a évidement plusieurs façons de corriger ce bug, mais en attendant j'ai pensé à un contournement qui s'applique à de nombreux autres cas. Ce genre de "fonctionnalité" n'a pas forcément de sens pour tout le monde, peut être pénalisante ou dangereuse selon l'utilisation qu'on a de Jenkins. Il existe pourtant un point d'extension qui permet de filtrer les extensions (attention, StackOverflowError en vue).

Comme "Project Of The Day" j'ai donc crée le plugin Extension Filter (whaou, mais où donc vais-je chercher tout ces noms super originaux ?) qui permet de configurer les extensions et descripteurs à désactiver sur une instance Jenkins.

Ce plugin permet donc d'alléger Jenkins des points d'extension que vous n'utilisez pas et qui peuvent pénaliser votre instance. Il permet aussi d'inhiber des composants selon leur contexte. Par exemple, retirer de la configuration globale hudson.plugins.mercurial.MercurialInstallation, pour empêcher vos utilisateurs de configurer Mercurial et les obliger à passer sous Git, ou bien interdire à hudson.task.Maven$DescriptorImpl de proposer un BuildStep dans les projets de type free-style, pour imposer l'utilisation de jobs maven. On peut même désactiver la configuration du plugin lui-même comme ça personne ne pourra plus changer la conf :)

Je vous laisse imaginer des cas d'usage un peu plus sérieux pour des éléments de configuration que vous considérez superflu ou "dangereux" pour vos utilisateurs.

JavaOne, plus gros événement pour la communauté Java, se déroule en fait en marge d'un événement bien plus important : Oracle Open World ("oow" pour les intimes). Ayant un pass "Press" j'ai le privilège de pouvoir m'y promener, je suis donc aller voir de quoi il s'agissait.

OOW occupe les trois centres Moscone de San-Francisco, immenses centres de conférences, plus l'avenue qui les sépare et qui est recouverte par une tente/expo pour des démonstrations et salons privés.

Imaginez un peu le parc des expo porte de Versailles entièrement recouvert aux couleurs d'Oracle. Tous les hotels a proximités sont pré-réservés pour la conférence - a 1000$ la nuit. Le "petit" carré rouge en haut sur la carte c'est Union Square, qui est également annexé par Oracle pour installer un scène et des tentes VIP. le "petit" groupe violet/vert/bleu ciel en haut, c'est JavaOne.


Vous l'aurez compris, on ne parle pas des même dimensions. Une armée de bus fait la navette pour amener les conférenciers de leurs hotels au centre de conférence. L'une d'elle s'arrêtait devant mon hotel, la Kabuki à JapanTown, cependant j'ai vite compris qu'il valait mieux pour moi prendre les transports publics 20 mètres plus loin qui s'arrêtent pile devant le Hilton de JavaOne, plutôt que de poireauter 30 minutes pour ce bus climatisé qui passe d'abord par les Moscone - question de priorité !


 Le hall d'accueil de ces trois centres de conférence est à la hauteur de l'événement, entièrement recouvert d'affichages aux couleurs d'Oracle. Pénurie de peinture rouge à prévoir dans la vallée pendant quelques semaines.


 Dans le hall d'expo, énorme déception. Je pensais, vu l'étendue et la démesure de certains stands, qu'on aurait droit à de super goodies hors norme. Que nenni, un stylo à bille Accenture et un bonbon à la mente EMC, rien de plus.


Par contre, à ma grande surprise les exposants de ce "Oracle World" vont très au delà du monde informatique. On retrouve donc les partenaires techniques d'Oracle (éditeurs, service, ...) mais aussi tout ce qui va avec la population "Executive" qui se presse dans ces allées, comme par exemple un stand Emirates qui vous fait essayer le siège de la première classe de ses nouveaux A380 ! C'est comme si pour Devoxx on avait un stand "fnac" qui vous propose le tout dernier clavier ergonomique.

Dans le genre, le plus comique concerne le badge de Sacha Labourey, CEO de CloudBees. Avec son titre, il a eu droit à un badge "Executive Edge", qui lui permet :

• d'avoir accès à Union Square pour les repas. A noter que, même depuis JavaOne, ça fait une trote et ça monte raide, alors qu'on mange tous les sandwich certes moins bons de J1, mais dispos sur place
• d'être invité à un tournois de mini-golf sur le stand Adidas avec un sac de golf garni à la clé.

Dans mes précédents billets, je vous ai parlé de JavaOne côté technique, mais il y a un autre aspect de la conférence que vous pouvez plus difficilement vendre à votre patron pour obtenir votre billet, et qui pourtant fait pleinement partie de l'événement : les Parties ! (attention à ne pas confondre avec un autre type d'activité annexes).

Premier exemple du genre : invité par Ludovic Poitou pour un "apéro Forgerock", je viens donc prendre un verre dans un pub proche de la conférence, privatise pour l'occasion. L'occasion de rencontrer des gens en tout genre, dont quelques têtes connues