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
