2013/9/19 Les Mikesell <[email protected]>
> 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'?
>
it's just about using the adequate jenkins API
Jenkins.instance.getItemByFullName("job").scheduleBuild(...)
>
> >> 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?
>
As I said, was set to avoid code duplication, but will rollback to remove
them, as it's indeed confusing.
Archive capability is a generic post-build action, no way to filter it
afaik.
>
> >> > 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.
>
Matrix head has a workspace, and all axes are sub-directories in this
workspace
>
> --
> 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.
>
--
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.
