continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Ruisma" <>
Subject build failures, warnings and continuum
Date Wed, 14 Mar 2007 10:47:07 GMT
Hello all,

I'm not quite sure if this is a continuum or a Maven question, but I thought
to post first on the Continuum mailing list.

In our company-wide settings I want that project sites are generated, and
artifacts get deployed to our internal repository even when there are some
unit tests that fail. We also want that a mail is send when there are test
failures, with some kind of indication that their was a problem during the

How would you set this up ?

We've had some ideas but none of them seems the respond to our questions.
Perhaps we're missing something here?

Currently, the nightly build is fails if there are test failures, so the
site is not published, the artifact is not deployed, ... I think these are
the default settings.

One idea was to use the variable "maven.test.failure.ignore=true" for all
continuum builds => if the test fails, the site is published and the
artifact is deployed.
BUT the build result is successfull and no mail is sent to the development
team => The development team doesn't know they are test failures ... unless
they look at the surefire report. We prefer to send a mail in this case with
a clear indications that there is a problem.

Another idea was to use the command line parameter --fail-at-end in all
continuum build definitions example: mvn clean deploy site

BUT this is not a good solution as the tests are also executed when calling
the site goal, so this goal fails before it's able to do the deployment.
Another idea was to provide an extra build definition inside continuum.
A) clean deploy site site:deploy --batch-mode  -
  Result: the artifact is deployed and the site is generated, but the build
is successfull (no mail sent)
B) clean test --batch-mode
  Result: nothing is done, and the build fails when there are test failures
(mail is sent to development team)

Any other ideas are highly appreciated.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message