RfC: Test group separation / module reorganisation

Heiko W.Rupp hrupp at redhat.com
Wed Nov 3 10:02:13 UTC 2010


Hi,

Am 28.10.2010 um 20:59 schrieb John Sanda:

> heiko and I were chatting about this, and I remarked that I feel that 
> our build is too monolithic. Let's say for example that I make a change 
> in some plugin code. As far as our CI process goes, we will build the 
> entire source tree. This results in delayed feedback from the CI process 
> as it already takes a considerable amount of time to run a full build. 


I just got the idea of what if we have one job only building the complete project,
but not running tests. And then having separate test jobs on top of it that
get triggered with various test profiles.

> Let's say we have separate hudson builds for the server and for the 
> plugins. Then I make some changes in server/jar. Since the plugins is a 
> downstream dependency, they only need to get built if the changes I make 
> in server/jar result in a successful server build. This approach would 

+1
And actually agent plugins don't depend on server or gui at all, so there
is no need to rebuild those when there are only changes in server or gui.

Also there is no point in running the expensive GWT compile every time
a change has occurred in any plugin.

> build is already painfully slow. Adding long, running performance tests 
> only exacerbates the problem. Lastly, the perf test hudson job as it is 

This is why I've put them in group PERF

Also after looking at stuff more, we should move from
<excludeGroups> in tests to <groups> to explicitly include 
tests.
But then the latter exhibits the danger of missing tests because they 
are in no group. 

  Heiko

P.S.: what is this filtered-resources stuff?
-- 
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera



More information about the rhq-devel mailing list