On Thursday, 3 October 2013, Les Mikesell wrote: > On Thu, Oct 3, 2013 at 2:24 PM, Stephen Connolly > <[email protected] <javascript:;>> wrote: > > > >> How so? Requiring different build commands/options/targets seems very > >> normal across the same code's version history and branches. > > > > > > Typo I meant coupling your source code to your CI too tightly is not a > good > > thing... I think Jenkins is best, but I want users to reach that > conclusion > > themselves by trying Jenkins and other options. > > Sure, but having the files there doesn't force you to use jenkins - > anything else would just ignore them. > > >> > From my PoV this is all obvious *now* but that's the thing about good > >> > ideas, > >> > they are always obvious when you look back after discovering them. > >> > > >> > There are a lot more subtleties to literate but I don't think people > are > >> > quite ready for the brain melt if I start explaining them now ;-) > >> > >> This thread probably isn't the right place, but I've always preferred > >> the 'think first, then act' approach and would like to see that > >> explanation. In particular, how direct/complete is the relationship > >> between what you can pass in the controlling file and the full jenkins > >> api? If you want to do anything unusual, will you end up doing it in > >> groovy anyway? > > > > > > Publishers are completely 1:1 mapped > > > > Build steps turn into shell commands (or batch on windows) > > That brain melt thing you mentioned is starting to happen. Is there, > or can there be, a groovy build step option? > > > Heavy intra-build coordination... I have a different idea for that... > Likely > > my different idea will not get approval for being OSSed (hey I'm happy to > > have set this one free) > > Likewise, having an option to run a system groovy steps at the top > level would give you fine-grained control when you need it.
This is not the solution you want. > > > After that most of the interactions will need branch properties provided > by > > the plugins so things like build wrappers and job properties are not > defined > > in the literate build... I may find ways to pull them in but it needs > > thinking or the solution will uglify > > Abstractions are nice as long as the person who wrote them anticipated > exactly what you need to describe. But somehow that isn't always the > case, so having a way to work around missing parts would be a good > thing, I think you just haven't got the change fully absorbed > > -- > Les Mikesell > [email protected] <javascript:;> > > -- > 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 [email protected] <javascript:;>. > For more options, visit https://groups.google.com/groups/opt_out. > -- Sent from my phone -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
