On Thu, Oct 3, 2013 at 12:53 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> 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.
> 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.
> 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?
> 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?
--
Les Mikesell
lesmikes...@gmail.com
--
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/groups/opt_out.
