J'ai enfin trouvé le temps de publier la première release du plugin Jenkins "build graph view". Ce plugin permet de visualiser de manière graphique les builds impliqués par un build initial. La mise en place d'un workflow complexe sur Jenkins implique en effet souvent de distribuer le travail dans plusieurs jobs, liés les uns aux autre par des relations "upstream-downstream" orchestrées par une série de plugins.
Le plugin build-pipeline existe déjà sur ce créneau et est très populaire, mais se limite à des exécutions statiques, comprenez que les jobs impliqués sont toujours les mêmes à chaque exécution.
Dans de nombreux cas, cet ordre peut évoluer, certains jobs étant lancés de manière conditionnelle, et on peut aboutir à des chemins d'exécution complètement différents. Build Graph View plugin aborde donc le problème en proposant un graphe dédié à chaque exécution :
Ce n'est "qu'une" 1.0, ce qui signifie que de nombreux liens entre builds ne sont pas supportés à ce stade (plugin join, copy-artifact, promoted builds...). Cependant elle couvre déjà pas mal de cas, et le plugin est facilement extensible, contributions are welcome ;)
Le code de ce plugin est issue d'un autre de mes plugin, le build-flow. Ayant enfin pu finaliser l'extraction dans un plugin dédié, en ajouté les bouts de code qui assurent la complémentarité entre ces deux plugins, j'enchaine avec la release 0.10 de celui-ci. Build Flow va dans le même sens, en constatant que définir un workflow complexe dans Jenkins est bien compliqué, à base de plugins en tout genre pour gérer le passage de paramètres, l'exécution concurrente, etc. L'orchestration des jobs est donc confiée à un DSL, chargé de lancer les jobs. On a ainsi une séparation entre les tâches élémentaires et le wrokflow de plus haut niveau, sans que ce dernier soit dispatché un peu partout et difficile à gérer.
Rien de fondamentalement nouveau dans cette release, désolé pour ceux qui espéraient de grand changements, et surtout pour ceux qui espéraient que cette version soit une 1.0, car on en est pas là ... Ce qui manque au build flow ?
Le plugin build-pipeline existe déjà sur ce créneau et est très populaire, mais se limite à des exécutions statiques, comprenez que les jobs impliqués sont toujours les mêmes à chaque exécution.
Dans de nombreux cas, cet ordre peut évoluer, certains jobs étant lancés de manière conditionnelle, et on peut aboutir à des chemins d'exécution complètement différents. Build Graph View plugin aborde donc le problème en proposant un graphe dédié à chaque exécution :
Le code de ce plugin est issue d'un autre de mes plugin, le build-flow. Ayant enfin pu finaliser l'extraction dans un plugin dédié, en ajouté les bouts de code qui assurent la complémentarité entre ces deux plugins, j'enchaine avec la release 0.10 de celui-ci. Build Flow va dans le même sens, en constatant que définir un workflow complexe dans Jenkins est bien compliqué, à base de plugins en tout genre pour gérer le passage de paramètres, l'exécution concurrente, etc. L'orchestration des jobs est donc confiée à un DSL, chargé de lancer les jobs. On a ainsi une séparation entre les tâches élémentaires et le wrokflow de plus haut niveau, sans que ce dernier soit dispatché un peu partout et difficile à gérer.
Rien de fondamentalement nouveau dans cette release, désolé pour ceux qui espéraient de grand changements, et surtout pour ceux qui espéraient que cette version soit une 1.0, car on en est pas là ... Ce qui manque au build flow ?
- Un sandboxing du DSL groovy. En effet, les droits "RUN_SCRIPT" (administrateur) sont nécessaire pour éditer le DSL, sans quoi un utilisateur standard pourrait accéder aux API Jenkins et à la JVM sans contrôle ... ce qui rend le plugin assez inutilisable dans un contexte d'entreprise avec un Jenkins mutualisé. A part un SecurityManager bien trempé je ne vois pas de solution viable pour le moment
=> JENKINS-16980.
- L'exécution asynchrone du DSL. Actuellement, le DSL est lancé comme un simple script, et de ce fait ne peut être interrompu ou relancé. Groovy ne propose pas de "Continuations" qui permettraient de capturer la call-stack pour la relance plus tard. La piste que j'envisage pour le moment est de rendre le script "rejouable" à volonté, les étapes déjà exécutées se transformant alors en NOP. Autre solution pas triviale, utiliser les AST Transformation pour convertir le script impératif dans un format CPS ... Si vous avez la super solution idée du siècle, je suis preneur.
=> JENKINS-19118
0 commentaires:
Enregistrer un commentaire