[jboss-dev] Hack for Continuous Integration in AS

Jason T. Greene jason.greene at redhat.com
Thu Feb 19 14:04:54 EST 2009


Andrew Lee Rubinger wrote:
> Jason T. Greene wrote:
>> Hmm. The thing I wonder though is how useful this will be if you start 
>> pulling in everyone's snapshots. You will probably end up with 
>> incompatible combinations.
> 
> We'd have to curtail this by saying "you can put SNAPSHOTs here, but on 
> a limited basis and then take 'em out".

If you pull out the updates then you don't get the "continuous" testing 
I thought you were looking for. Then its really more like a dry-run 
branch, except that it's everyone's dry run at the same time.

> For instance, right now we'd have VFS and some other related stuff in 
> Branch_5_0 only.  When those SNAPSHOTs being tested are released, the 
> snapshot override is removed.

Exactly, and that was a bad idea that has killed any productive use of 
that branch other than testing the VFS.

>> It's probably more useful if every team has their own manual or 
>> automated integration run. This could either be snapshot based via 
>> some kind of maven override, or could be a temporary branch created 
>> off the main AS branch that includes the changes.
> 
> I'd rather roll the dice on incompatible combinations than set us up for 
> even more custom runs and branches.

It would be more like playing Russian roulette with a fully loaded gun ;)

> Already we have a geometric problem:
> 
> Number of TestSuites (AS, TCK, EJB3, etc) * AS Branches

Sure, you can't automate everything. Sometimes running the testsuites 
yourself is inevitable. I think the easiest way to approach the problem 
is to break this responsibility up per team. Each team uses whatever 
approach they want to verify the AS works before they commit their 
component update. Some things, like a full TCK run, will likely always 
have limited runs. However each team can run their section against their 
component.

-- 
Jason T. Greene
JBoss, a division of Red Hat



More information about the jboss-development mailing list