-
1. Re: Build failed message
clebert.suconic Aug 19, 2008 10:49 AM (in response to timfox)I assumed that a failure on the unit testsuite is a mandatory clause for commit so a failure would abort anything and would be considered a build failure, While a failure on the other testsuites would be considered just a unit-test failure.
Notice that the other testsuites (stress, integration... etc) are not being executed on all-tests if there is a testsuite failure.
But we could change that. -
2. Re: Build failed message
timfox Aug 19, 2008 12:20 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
I assumed that a failure on the unit testsuite is a mandatory clause for commit so a failure would abort anything and would be considered a build failure, While a failure on the other testsuites would be considered just a unit-test failure.
Notice that the other testsuites (stress, integration... etc) are not being executed on all-tests if there is a testsuite failure.
But we could change that.
I'd recommend applying the change consistently across all test suites -
3. Re: Build failed message
clebert.suconic Aug 19, 2008 2:01 PM (in response to timfox)I'd recommend applying the change consistently across all test suites
I'm not sure if we should do that... a failing unit-test will abort the build...
When you run all-tests, you want the entire testsuite to run, even if you have a failure on an integration test for example. Applying the same logic would cancel the build. We talked about that when I first committed this.
We could of course change it to just show a "Build Failed" at the end, but that's not an easy thing to do with ant due to how the variables work on ant. (each ant-target call will initialize a new method.. you won't have a global variable where you could change). -
4. Re: Build failed message
jmesnil Aug 20, 2008 4:44 AM (in response to timfox)I'd keep it as it is:
- stop the build if there is a failure in the unit-tests
- process all the other tests regardless of the errors and failures
I expect failures in integration, timing or stress tests to be more "long-lived" (a few hours, a few days) than failures in unit tests (which should never occur).
Stopping the tests on the first failure in the integration tests would hide any other regressions until this 1st failure is fixed.
Moreover, since I'm developing on Mac OS X, the tests requiring libaio consistently fails.
In any case, I'd have to modify the build to be able to run all the tests but the libaio or, more simply, run the test suite without stopping on errors or failures (as it is now)