On Thu, Sep 19, 2013 at 10:41 AM, Schalk W. Cronjé <ysb...@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 was only when I started to play
> with it that I came to realise that it was actually a tool for the
> orchestrating multiple jobs. So you are not alone in your I initial
> perceptions.
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.
> As to answering another question you had, I know that if you are using
> 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.
> If you need something more complex you may need to use a revision parameter
> on the downstream jobs. You'll then to append @${REVISION} to your SVN URLs.
> (Assuming param was called REVISION).
Yes, I can do this within build flow with $SVN_REVISION with the
version where the svn polling trigger works. Not sure if later
versions will have an equivalent. I'm beginning to think that what I
really need is some boilerplate groovy code or library to do the same
operations as the build flow plugin but in an ordinary build step.
Would the 'run other jobs in parallel' feature be possible there?
--
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.
