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...
On Thu, Jan 13, 2011 at 5:14 AM, Stevo Slavić <ssla...@gmail.com> wrote: > IMO solution is simple - discipline your developers to run verify > before commiting. CI should help you determine whom to blame when > build is broken and then you can apply disciplinary meassures. > > Regards, > Stevo. > > On Thu, Jan 13, 2011 at 11:24 AM, Stefan Schulze <algr...@gmx.de> wrote: > > Stephen Connolly wrote: > >> [...] > >> Run the damn tests at least twice. > > > > Ok, I see your point. But I never tried to run the tests only > instrumented. I just want to execute the more-likely-failing tests earlier > in the lifecycle and the not-so-likely-failing tests later. > > So of course I want to execute both uninstrumented _and_ instrumented > tests. > > -- > > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > >
