On Thursday, 3 October 2013, Les Mikesell wrote: > On Thu, Oct 3, 2013 at 12:53 PM, Stephen Connolly > <[email protected] <javascript:;>> wrote: > > Because you probably don't want to couple your source code too strongly > to > > your SCM. > > 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. > > > Of course the breakthrough from my PoV is that you always want a README > in > > SCM that says what the build command(s) is/are (hopefully it's a single > > command, but sometimes you need a couple of them) > > > > Hijacking the README to infer the build command thus is much better IMHO > > than reading an 80 page spec and deciphering a pile of different "magic" > > defaults based on what values you put in a config file. > > Putting it in README is a nice touch and invokes the 'literate > programming' concept, but the functionality of controlling the build > and targets within the versioned project is the part that intrigues > me. > > > The .jenkins directory is thus more about giving Jenkins some metadata > about > > the build output, it doesn't interfere if you want to change CI system, > and > > it is not critical for a build+test verification build. If you want to > try > > another CI system the .jenkins directory should not get in your way. > > I haven't gotten that far yet. And maybe I can't on the stable builds > - I don't see it as an available plugin. Any plugin with alpha or beta is hidden from the regular update centres... You need to configure the experimental update centre to see them > > > Finally the marker file is all about identifying the branches to build > > without having to visit the UI... And since we have that file we can use > it > > (if non empty) as a replacement for the README if you want to tweak the > CI > > build > > How do you find 'branches' in subversion which doesn't really have > branches - or more accurately, treats any place you copy something as > a branch? You declare a root and a set of patterns to search, if the marker file is found => it's a branch Works quite well and ends up being faster than you think due to how I prune the path search. Warning the beta version of the subversion plugin does not migrate credentials fully yet, so not advised to upgrade your production server to the 2.0 version of subversion plugin *yet* > > 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) 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) Maven stuff... I have a strong opinion on the right way to solve the maven problem... It will be quite elegant and work well with literate... Just have a few small tweaks first 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 > > -- > 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.
