Configure preconditions for Checker Bundle run and workflow termination options

[andreaskern74]

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):

<Config>

    <Param name="InputFile" value="myTrack.xodr">
    
    <CheckerBundle application="ASAMOdrChecker">
        <Checker checkerId="..." .../>
        <Checker checkerId="..." .../>
        (...)
        <TerminateCondition max_errors="0"/>  <!-- don't call other Checker Bundles if more errors found -->
    </CheckerBundle>
    
    <CheckerBundle application="Internal1">  <!-- no preconditions here -->
        <Checker checkerId="MostImportantCheck" .../>
        (...)
    </CheckerBundle>
    
    <CheckerBundle application="Internal2">  <!-- all preconditions (with links to other Checker Bundles and Checkers)
	                                          need to be fulfilled to start the execution of this Checker Bundle -->
        <PreCondition no_errors_in="ASAMOdrChecker"/>   
        <PreCondition no_errors_in="Internal1/MostImportantCheck"/>
        (...)
    </CheckerBundle>
    
    <ReportModule application="TextReport">
	
</Config>

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.

[MatteoRagni]

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:

1. The checker bundle are executed following the ordering specified in the configuration, without parallel executions
2. 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">
   
</Config>

I'm pointing this out to avoid this situation:

<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>