Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure preconditions for Checker Bundle run and workflow termination options #43

Open
andreaskern74 opened this issue May 6, 2024 · 1 comment
Labels
effort:Unclear isState:Accepted An issue that has been accepted by the group, which needs to be assigned to a responsible isType:Feature An issue that adds new features to the project.
Milestone

Comments

@andreaskern74
Copy link
Collaborator

andreaskern74 commented May 6, 2024

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.

@andreaskern74 andreaskern74 added isType:Feature An issue that adds new features to the project. isState:New A new issue that needs to be classified to a type. labels May 6, 2024
@andreaskern74 andreaskern74 added this to the Wish List milestone May 6, 2024
@MatteoRagni
Copy link
Collaborator

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>

@andreaskern74 andreaskern74 added isState:Accepted An issue that has been accepted by the group, which needs to be assigned to a responsible and removed isState:New A new issue that needs to be classified to a type. labels May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort:Unclear isState:Accepted An issue that has been accepted by the group, which needs to be assigned to a responsible isType:Feature An issue that adds new features to the project.
Projects
Status: No status
Development

No branches or pull requests

2 participants