-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: Linux
I've just upgraded to hudson 1.316 and my projects no longer build properly.
I work at a commercial company with a wide range of projects, managed by Maven.
Our project is built as a multi-module project with a top-level aggregator, and
inter-module dependencies are specified in the poms as normal.
The aggregator pom is the one we build in Hudson (it lives at the root of the
project directory, with subprojects in folders underneath).
The order of events I'm seeing is this:
1) SCM update is triggered, Hudson does an SVN up, followed by triggering the
aggregator.
2) Hudson builds aggregator, "Triggering a new build" for each of the modules
3) These builds all get added to the queue with no ordering. Some get pulled off
the queue by executors.
4) Hudson "Triggering a new build" for each module's dependencies, regardless of
whether they're building or not, or dependencies of other modules. Some tests
fail as new code hasn't been compiled yet.
5) Eventually, all modules get compiled + installed (multiple times!) and all
tests pass and build status goes back to blue.
In 1.315, these builds were effectively ordered (perhaps by upstream/downstream)
and therefore only ran once.
Modules that depend on "n" other modules are being run n+1 times (once for each
of those modules and once for the top aggregator). This is making a build that
used to take 27 minutes take much, much longer.
Hudson is (still) correctly reporting these projects with upstream/downstream
dependencies, so it's strange that it's suddenly started building them like
this.
This only happens when "Build Modules in parallel" is ticked, obviously.
Also depressingly (but understandably) all these sub-module builds have to run
on the same machine that triggered them (usually Master), so our build farm is
suddenly one busy machine and two not being used.
- depends on
-
JENKINS-2736 Inefficient build order for Maven2 projects
- Closed