-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
hudson v1.364
master: ubuntu, 1 build processor
slave 1: ubuntu
slave 2: ubuntu
slave 3: ubuntu
our build environment with hudson consists of 4 build processors which are equally equipped. the projects we integrated are java maven projects from a CVS repository and have these certain configurations:
- the projects are triggered when a SCM request returns a change (time plan is every 15 minutes)
- the projects are not bind to any node (build processor)
we could track the following behaviour with several projects and over the duration of more than 6 weeks now:
- when a project gets integrated first on hudson it will be checkout on one of the build processor nodes (randomly)
- when a checkin occurs on that project afterwards
- the SCM request returns a change and triggers a build on one build processor node
- after 15 minutes another build is triggered on the second build processor node
- after 15 minutes another build is triggered on the third build processor node
- after 15 minutes another build is triggered on the fourth build processor node
- when the first SCM request returns a change this change will be written to the changelog and on the project i can see: "Build wurde durch eine SCM-Änderung ausgelöst." (Build was triggered by a SCM change)
- the following three builds on the other build processor nodes also show the same trigger message but no changelog
conclusion:
every checkin on a project leads to 4 builds, polluting every build processor -> that is wrong in my opinion. just imagine what happens if there are downstream projects to that project.
hudson should keep cvs information on a central location and make SCM request from that location. it is wrong to let hudson choose a build processor on which the SCM request will be done.
- is related to
-
JENKINS-7945 Improve SCM polling mechanism
- Resolved