On Thu, Sep 19, 2013 at 12:36 PM, nicolas de loof
<nicolas.del...@gmail.com> wrote:
>
>> > The very first time I read about Build Flow I also thought it to be a
>> > DSL
>> > for specifying complex steps in a job.
>>
>> Maybe it was wishful thinking, because that seems to be what I need.
>
>
> It's not, it's a tool to orchestrate workflows (so the name) based on jobs,
> as a replacement for parameterized build trigger + join + downstream + ...
> plugins
>
> If you need to do advanced build script, use groovy system script or
> scriptler plugin

I think that's what I need, but I'm not a groovy expert.   Is there
any way to incorporate the flow DSL operations into a generic groovy
build step?  And does it have to be 'system'?

>> The perception was boosted by the version I am using having access to
>> all of the usual build trigger options, a visible workspace, and the
>> usual post-build options.
>
>
> First implementation didn't offered this, and BuildFlow just extended Job.
> For simplicity and avoid code copy/paste it extends Project, but isn't an
> actual Project as FreeStyle Job is.

It just seems confusing to me, and I think it would be to others to
not have the expected triggers and archive capabilities.  How did the
version that extended Job mesh the details of running on a slave node
with its system operations - or does that matter?

>> > Subversion, then in the simplest case using SVN Tracking plugin will
>> > suffice.
>>
>> If that's the plugin I think, it says it should be used with commit
>> hooks, not polling - and I don't understand quite how it would work if
>> builds of different revisions ran concurrently.   If one set of builds
>> hasn't completed before they are started/queued for another revisions,
>> I still want each set to complete and stay consistent.
>
>
> This is an issue I'm investigating. I'd like plugin to be triggered by a git
> post-commit hook, then pass the incoming revision as parameter to other jobs

I'm not really clear on how matrix jobs handle this either - which is
part of the reason I'm looking for more explicit control of the child
jobs.

-- 
   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.

Reply via email to