While the evaluator already is flexible in the sense that arbitrary policies can be implemented in *.rules.kts files using the ORT rules DSL, these rules files need to be available as local script files or resources within ORT.
This is a bit limiting when the rules script requires access to additional data (like the OSADL compatibility matrix), or when other means tahn the rules DSL should be used to create rule violations.
To address this, the idea is to create a plugin API for something that could be named PolicyRuleChecker, whose input is an OrtResult and whose output is a list of RuleViolations. Such checkers would bundle rules and their required data, and be optionally configurable, for example to use a specific version of the OSADL compatibility matrix.
If implemented properly, I believe such an approach could (help to) address the following issues:
While the evaluator already is flexible in the sense that arbitrary policies can be implemented in
*.rules.ktsfiles using the ORT rules DSL, these rules files need to be available as local script files or resources within ORT.This is a bit limiting when the rules script requires access to additional data (like the OSADL compatibility matrix), or when other means tahn the rules DSL should be used to create rule violations.
To address this, the idea is to create a plugin API for something that could be named
PolicyRuleChecker, whose input is anOrtResultand whose output is a list ofRuleViolations. Such checkers would bundle rules and their required data, and be optionally configurable, for example to use a specific version of the OSADL compatibility matrix.If implemented properly, I believe such an approach could (help to) address the following issues: