Jeff Jensen wrote: > Perhaps a different CI job structuring? This has worked well for me > at many > customers: Have a CI job for only compile and unit tests - this > maintains the most important very fast turnaround. Have a second CI > job for (longer > running) IT tests that only runs with success of the first. > Have a third job for coverage, standalone or as part of a full system > site gen or using Sonar or other...
Sounds nice, but this doesn't meet my requirement, that the tests with coverage-checks (and only one time, not twice) should run, when the developers do "mvn test". We have a quite small difference between coverage-threshold and actual coverage, so I think it's important, that the developers check their coverage during development, so they can react early. Another problem to your solution is, that we unfortunately don't use a regular CI-server but a bunch of shellscripts and cron-jobs. So it's not as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
