On Thu, Sep 19, 2013 at 12:36 PM, nicolas de loof
<[email protected]> 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
[email protected]
--
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.
