Eric D Nielsen a écrit :
With the latest 1.1 beta (1.1-beta-4), you don't need to run a clean
build with a checkout. All build definitions are independant and
found all changes from other builds since last execution even if
the update return nothing.
Thanks. I'll update ASAP and see how it goes.
We'll try to find a solution for this in 1.2, but your 2 nightly
builddef "clean install" + "site site:deploy" can be rewrite with
one builddef "clean install site-deploy"
I have the same issue as Tonda, I want the site built and deployed,
even if the build fails -- for instance I want the new Surefire report
and the new Cobertura report to be deployed. (For instance if a
cobertura check test or unit test failed, that should be reflected on the
site.)
I'm almost tempted to add the project multiple times to the project group,
but I'm not sure how "legit" that would be. Ie if I could add the project
times.
Instance A: With the Unit/Integration Test builds
Instance B: Nightly Builds
Instance C: Site Builds
Of course there's no way of giving a project an alias, or alternate description
from whats in the POM, so that would get confusing fast. On the upside, it
would also separate the nearly always successful site builds from masking a
failed nightly build.
I could do the same with three different project groups... all containing the
same project... Are any of these options more normal for people's continuum
configurations?
I don't recommend to add more than one instance of a project (same
groupId/artifactId/version) because it can generate some weird result like
wrong ordering or wrong dependencies check result.
Emmanuel
