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 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.
