directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: About code checking ...
Date Sat, 15 Mar 2008 08:26:08 GMT
Felix Knecht wrote:
> Emmanuel Lecharny schrieb:
> About the report creation:
> - Do we have a CI buildsystem also deploying the generated reports?
No, not yet. But this is something we want to have for years ... In 
fact, we have tried many CI systems. We currently have Teamcity almost 
setup on one of our committer's server, but we didn't put too much time 
on it. I have personnally tried Continuum a while back (not exactly a 
success with 1.0 version, much better with 1.1 version, but not 
perfect), and we tried bamboo one year ago, and we had to stop, the 
'spam' level was too high :)

There are some issues with CI we have to address:
- setup is not simple, as many CI systems does not support hierarchical poms
- we need to send spam^H^H^H^Hmails when something went wrong or when 
the build is OK, that implies a SMTP server being available for that purpose
- The build frequency should be tuned correctly. If we build on every 
commit, we may have broken builds, as commit may not be atomic, and if 
we build at fixed hours, that mean we do a svn up, and this may be seen 
as a bot by infra.
- results should be available through a web interface, but limited to 
the committers
- the best would be to use the ASF infra for that, but we have not yet 
investigated this possibility (I know that Hudson is being setup and 
used by at least a few projects at the ASF, it should be interesting to 
check this option)

Basically, I'm 100% pro using a CI. Here is what we can do :
- check Hudson on a private machine and see if it can fit our needs 
(daily builds, mails, inherited poms with externals)
- if so, check with Infra to see if we can use the instance they have 
installed
- then, check if we can produce reports on this zone, or if we need 
another space for reports

The idea about reports would be to keep only a few of them : if they are 
generated every nights, no need to keep an history. Just replace the 
previous one would be enough

I would also suggest we try to add some basic reports to our maven 
build, so that we can play them locally.

> - Some of the reports can be aggregated, others not. Whats the main 
> idea (aggregating, only reports per module)?
Well, we might want to generate reports for :
- apacheds
- daemons
- shared
- studio
- triplesec

As they are different components, it make sense to have separated 
reports, IMO.
>
> - Some (not aggregatable) reports can be 'aggregated' use the 
> dashboard plugin.
I don't know too much abiut the Maven possibility, so I would say : 
'it's up to you'. In other words : 'those who know, speak. Other, just 
listen ;)' - I'm in the 'other' category ..-
>
> Felix
>
Thanks Felix !


-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message