Danny Angus wrote:
On 01/08/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Furthermore I see that gump always run the integration test based on
trunk for all the dependencies, I don't know how this is configured but
I don't like this for james. I don't want to have a broken build because
current velocity trunk is broken and so on (I saw this many times in
gump results for james-server)
Thats the whole point of CI, to give you early warning of changes
which will break your project.
When you're at the end of a long food chain like James is it gets a
bit boring though.
Setting up nightly builds, not CI ones, is a more appropriate solution
to all of the things you want to do.
I don't agree with this.
Elaborating on your point your should do CI under the latest version of
the kernel on the latest hardware architecture every time ;-)
You have to define what is the "World" that you want to integrate.
I personally don't care if commons-collection create a new jar that will
not work with James. Instead I would like to know if jspf or postage
starts being incompatible with the latest trunk.
Furthermore when (if) we'll move to multi-module for james it will also
test the integration between the modules.
And I don't really want to have my builds broken by non-working velocity
as we don't use it and don't need it.
About our nightly build we currently don't run unit-tests before
creating them, we don't create reports, we don't publish other
informations. It would really better to have such things done.
I don't care about defining what CI is or is not, but I care about
results: I don't need to test the latest velocity, but I really need a
continous build (maybe done each hour or less) that run a full
build/test/report generation/packaging and alert me if something goes wrong.
Currently if I commit something that builds but break tests no one
notice this: this is not good.
Stefano
