On Thu, Oct 3, 2013 at 2:24 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> 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.
> 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,
--
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.
