The very first time I read about Build Flow I also thought it to be a DSL for
specifying complex steps in a job. 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.
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 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).
An alternative is to write the revision info into a fike which is published as
an artifact. Utilising the Pre_SCM_BuildStep plugin you can download the file
and use the Environment Injector plugin to set the url, revision etc. Similar
to the previous example you will need to ${PARAM}s in your SVN setup
--
Schalk W. Cronjé
[Sent from mobile phone]
-------- Original message --------
From: Les Mikesell <lesmikes...@gmail.com>
Date: 19/09/2013 16:01 (GMT+00:00)
To: jenkinsci-users <jenkinsci-users@googlegroups.com>
Subject: Re: Build Flow Plugin and artifacts management in the DSL
On Thu, Sep 19, 2013 at 8:28 AM, nicolas de loof
<nicolas.del...@gmail.com> wrote:
> build flow is a flightweight task, supposed to orchestrate jobs, not to
> archive content or manage a workspace.
> It can be triggered by commit hooks, best option.
I guess I don't understand having a jenkins job that isn't really a
jenkins job and intentionally doesn't do the things I want jenkins to
do... Is there some other plugin or approach that would be better to
accomplish this? In general that would be to poll a subversion
repository, and when a change is detected, build the same revision
across serveral platfoms (even if there are subsequent commits before
all builds happen), optionally run some tests, and optionally archive
some of the results for subsequent optional promotion. I, and many
of the other users here are not java/groovy experts so your DSL is
appealing, but it doesn't seem to match all of the job we need to
describe. Is there some way to import its methods into a generic
groovy build step to be able to use them in a less restricted context?
I don't think triggering a build on every commit would work in our
situation - they are mostly hourly or nightly polls. If there is no
other way to do it, should I think in terms of running one platform's
builds with the stock svn polling, then having that job kick off the
build flow job for the rest? And if I did that, can I pass the
triggering SVN_REVISION through to its child jobs so that the builds
and tests are consistent?
--
Les Mikesell
lesmikes...@gmail.com
--
You received this message because you are subscribed to a topic in the Google
Groups "Jenkins Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/jenkinsci-users/0vVMVDNAkRo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
jenkinsci-users+unsubscr...@googlegroups.com.
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 jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
