25 octobre 2012

POTD - extension filter plugin

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.