Il y a parfois des coincidences.
Je publiais hier un billet expliquant pourquoi j'abandonne le build-flow plugin au bon soins de la communauté. Quelques heures plus tard Kohsuke annonçait sur la mailing list jenkins son plugin de workflow.
Nous nous serions concertés pour faire un lancement produit nous n'aurions pas fait mieux ! Mais non, c'est juste une coincidence :P
Ce nouveau plugin n'est pas à proprement parler la continuité du build-flow, même s'il en partage certains aspects. On retrouve un DSL qui décrit le workflow, mais ici l'unité de base n'est plus un job, mais un build-step, qu'on va exécuter sur un slave donné.
Le plugin est encore assez jeune mais permet déjà de définir des choses comme :
je ne doute pas que KK ai prévu tout le nécessaire pour que chaque plugin jenkins puisse ajouter ses propres mot clé au DSL et l'enrichir...
En regardant les slides de présentation, je me demande si ce même DSL (réduit) ne pourrait pas être utilisé pour définir le build via un fichier à la travis, autrement dit un .jenkins stocké dans le SCM dans lequel vous définiriez les étapes de build et tout ce qui va bien pour votre project, ne déclarant dans jenkins que la partie SCM.
A réfléchir ...
Je publiais hier un billet expliquant pourquoi j'abandonne le build-flow plugin au bon soins de la communauté. Quelques heures plus tard Kohsuke annonçait sur la mailing list jenkins son plugin de workflow.
Nous nous serions concertés pour faire un lancement produit nous n'aurions pas fait mieux ! Mais non, c'est juste une coincidence :P
Ce nouveau plugin n'est pas à proprement parler la continuité du build-flow, même s'il en partage certains aspects. On retrouve un DSL qui décrit le workflow, mais ici l'unité de base n'est plus un job, mais un build-step, qu'on va exécuter sur un slave donné.
Le plugin est encore assez jeune mais permet déjà de définir des choses comme :
git.checkout( repo: “git@sm.com:app.git”, branch: “master”) mvn “install”
je ne doute pas que KK ai prévu tout le nécessaire pour que chaque plugin jenkins puisse ajouter ses propres mot clé au DSL et l'enrichir...
En regardant les slides de présentation, je me demande si ce même DSL (réduit) ne pourrait pas être utilisé pour définir le build via un fichier à la travis, autrement dit un .jenkins stocké dans le SCM dans lequel vous définiriez les étapes de build et tout ce qui va bien pour votre project, ne déclarant dans jenkins que la partie SCM.
A réfléchir ...
4 commentaires:
Ca serait super cool d avoir un systeme a la travis, moi je prefere passer par un fichier de config c'est plus portable.
+1
C'est par ou que l'on contribue ?
Et ca serait cool de pouvoir definir ces environnement
(BD, serveur applicatif, etc...)
Bonjour Nicolas,
1 an apres, où en est on ? Pour des choses simples (jobs paralleles par exemple) que vaut il mieux utiliser ? Le "build-flow-plugin" ou le "workflow-plugin" ? Et lequel est le plus pérenne dans le temps ?
Par rapport au fait de stocker un .jenkins dans le SCM, cela est il envisageable maintenant ? As-tu des pointeurs vers des docs ?
Merci d'avance !
Francois
oublie le build-flow-plugin (mais ce n'est que mon avis). Il est toujours maintenu par la communauté mais amha va mourrir gentiment.
workflow-plugin marche très bien et pour de nombreux cas, et est activement développé (je viens encore de pousser une pull-request pour rendre un plugin compatible).
Quand à stocker un .jenkins, KK a annoncé qu'il bossait la dessus lors de la keynote JUC, mais je ne sais pas où ça en est précisément.
Merci pour les infos ! :)
Enregistrer un commentaire