Hi Baptiste, I shall now trample over Vincent's comments!
On 21 August 2014 15:58, Vincent Latombe <vincent.lato...@gmail.com> wrote: > 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 😉 > Thanks! I had some help from KK & JG also > > # 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). > So the abstraction already exists for this *because* it is actually a good idea. For most people you are fine mapping labels directly, but there is a environment -> label/build tool mapping stage because you might be using a travis.yml build descriptor that uses different labels from your labels, or maybe you are following an external project that has its own build labels etc. The challenge is to create a good UI for this so that it doesn't become a mess > 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. > Yeah I am somewhat against this as the idea at least for the README style is that the readme should be useful to users. If somebody sees your github repo and doesn't see the actual command to build your project in the Build section of the README... well then thats a crappy README. For alternative formats such as Vincent's yaml then fair enough. > > ################## > > # 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. > Yeah my answer to the evil job type should resolve some of my vision in this regard > > > > ################## > > > > 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. > -- 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.
