Open andreaskern74 opened 4 months ago
I'm wondering if also this solution, with named preconditions, creates some sort of dependency graph. As long as I think that, in the future of the project, we will need to support what we called the dependency nightmare, as MVP we can simplify this further considering the folllowing:
The preconditions no_errors_in
fails if the links refer to something that is listed later.
E.g.: framework executes alpha
and then beta
, because of declaration order. Preconditions for alpha
fails, execution terminates immediately.
<Config>
<Param name="InputFile" value="myTrack.xodr">
<CheckerBundle application="alpha">
<PreCondition no_errors_in="beta"/> <!-- fails because beta has not run yet -->
(...)
</CheckerBundle>
<CheckerBundle application="beta">
(...)
</CheckerBundle>
<ReportModule application="TextReport">
I'm pointing this out to avoid this situation:
```xml
<Config>
<Param name="InputFile" value="myTrack.xodr">
<CheckerBundle application="alpha">
<PreCondition no_errors_in="beta"/>
(...)
</CheckerBundle>
<CheckerBundle application="beta">
<PreCondition no_errors_in="alpha"/> <!-- please, no T.T -->
(...)
</CheckerBundle>
<ReportModule application="TextReport">
</Config>
Is your feature request related to a problem? Please describe.
In real-world situations there are many situations where some Checker or Checker Bundle runs are only meaningful, if some other Checkers were successful. Within one Checker Bundle, the handling is very easy. But across Checker Bundles, or even across Checker Libraries, it is difficult to model the dependency graph and implement solutions working on this graph.
Example: An project internal Checker Bundle can only create valuable results if the file is ASAM standard compliant. So, the user should be notified, or should be able to read from the result, that empty results from the internal Checker Library here are not a good sign.
Describe the solution you'd like
Possibility to add preconditions for Checker Bundles run and/or termination options in the configuration of the framework workflow, so that the whole execution can be stopped, if preconditions are not fulfilled. This will prevent a report with a result like "Issues from internal checks: 0".
Example (logic, details need to be defined later):
Describe alternatives you've considered
Many discussions here, but we came to the conclusion that this solution have the very best ration of value to effort.