Feature #7239
closedKlever fails if it cannot build only one module
0%
Description
If Klever cannot build one module, it will terminated with status 'Failed' for all modules.
Example 1. We want to check all drivers (directory "drivers"), and if one of them cannot be built, we would like to check the other drivers.
Example 2. If we specifies several modules to verify ("m1", "m2", "m3") and one of them cannot be built, we would like to check the other modules.
Updated by Ilja Zakharov almost 8 years ago
- Priority changed from Normal to High
It occludes running relatively big test sets, since core stops if test fails to build. So to find all problems in a set you need to run collection again each time or split it into smaller sets.
Updated by Evgeny Novikov almost 8 years ago
- Tracker changed from Bug to Feature
- Category set to Infrastructure of Core
Your first example does look strange. How can we check other modules if we even can't build them?.. Using some ugly workarounds to isolate broken modules look awful and hard-to-implement for me. Continuing checking already built modules also don't look well, since we still will miss unpredictable number of modules.
The second example is likely the same as explained by Ilja.
I guess that the root reason of this issue is broken versions of the Linux kernel or/and broken tests. For the former I can just suggest to get good versions of the Linux kernel somehow and drop off those broken ones. For the latter we can automatically "recover" in the following way. If some sub-job fails we can proceed to other. At least we will reveal all issues at once. This shouldn't be done by default, just if the user asked so or/and in the development mode. Is it enough for you?
Updated by Ilja Zakharov almost 8 years ago
Imagine that you want to try an existing test suite (for example tests for environment model specifications) with the new version of the Linux kernel. Due to this bug you have to check the whole test suite again and again fixing each time per one module which is incompatible with the chosen kernel. You cannot get any feedback to estimate how many times you should repeat that. I agree with you that if you have any fixed version of the kernel and trusted test set this behaviour is Ok, but test development and experiments with different configurations or versions of the Linux kernel is a pain in the neck with the existing approach. Each test is always developed for the particular version of the kernel but we will not do that for each kernel version, so the problem anyway will happen many times, so it is better to solve it earlier.
Updated by Evgeny Novikov almost 8 years ago
But as I suggested if we will proceed to other sub-jobs if some sob-job will fail it will be okay for you, won't be? You will see all unknowns at once.
Updated by Ilja Zakharov almost 8 years ago
Yeah, but describing my use case I wanted to highlight that it is necessary to have list of all failed modules with logs containing errors. In this case it is a nice solution.
Updated by Evgeny Novikov almost 8 years ago
- Priority changed from High to Urgent
The priority is quite high since specification tests are under active development.
Updated by Evgeny Novikov almost 8 years ago
- Status changed from New to Closed
- Published in build set to bf77190
The feature was implemented in bf77190. By default in the development mode failed sub-jobs will be ignored and the whole job will be decided. In the production mode one will need to turn on the corresponding setting when starting job decision.
Note that nothing requested originally was implemented - see comments. If you will still think that you need something from those, please, open other issues.