Hi Baptiste, See my comments within your text.
Thanks for your observations, this is much appreciated 😊 Cheers, Vincent Le 20 août 2014 18:06, "Baptiste Mathus" <m...@batmat.net> a écrit : > > Hi all, > > I've recently been playing with the Literate plugin. As the plugin is still young, I thought I'd drop some random lines here about my findings/thoughts. Maybe this can yield some debate about views/future of the plugin. > > ################## > # Works as advertised > Might sound obvious, but I actually managed to install it and tinker with it quite quickly on our internal jenkins preprod server. That's not always the case :-). Congrats to the developers for that (Stephen & Vincent, we're looking at you :-)). > Thanks, but it is mostly Stephen's work 😉 > # Labels/text used in the README.md : tying to some server > In the .md you have to put things like: > * `rhel` and `maven-3.1.0` > - `jdk-1.7.0_64bits` > - `jdk-1.8.0_64bits` > > IMO, this somehow ties the sources to an actual server and its labels. > > What is your feeling about it? Is it maybe planned to add some form of label mapping between what's in a project descriptor and the actual labels in a jenkins instance? It could be done (the right abstraction already exists), but I'm not sure it would be such a great idea. If everyone comes in with a different naming for the same concepts (no convention) it could quickly become a mess to manage (yet another mapping layer). Alternatively I had in mind to use the implied labels plugin in order to manage these aliases (although it wouldn't work yet with tools installations) > > ################## > # Common values > Having to manage an averagely large Jenkins install (~400 jobs), I often find myself doing the same things many times, using variables and so on. > > Namely, in the case of literate-plugin, I'd see some form of : > > # Build > > $standardMvnBuild > > useful to share between builds (or even through inheritance, mixing in like Job DSL offers, etc.). > Though I agree it may also defeat some principles of the plugins or worsen the coupling between sources and the actual server. > This is actually possible through 'languages' using the yaml flavor of literate. You specify something like Language: java Then it loads default values for build commands depending on what you have in your source tree (pom.XML, build. Gradle or build.XML) However the referential for such conventions is still to be properly defined. At the moment they are buried in code and a proper extension mechanism is lacking. > ################## > # Integration with workflow-plugin / coordinating multiple jobs > I've not yet seen how to trigger other builds. I'm not even sure I see clearly how this would be done in a literate-style without again falling onto the above issue about tying things. > You'd have for example to define a name of job to trigger, and stick to it. In Jenkins, the naming updates somehow automatically. > With only text, this would quickly become out-of-date. The way I see it, you could have a workflow calling several steps stored on different scms, each step defined using literate. Then the workflow has the global view so is able to orchestrate the different components. Additionally, with additional maven integration, you could have something similar to the current 'trigger on snapshot dependency update' between literate jobs using the same branch name for example. > > ################## > > OK, let's call it a first shot. > > Hope I was clear enough. If not just tell me. I hope this will help us discuss about this very interesting work. > > Thanks again. > > Cheers > > -- > Baptiste > > -- > You received this message because you are subscribed to the Google Groups "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
