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.