[Scanner] Extend execution scanner framework with an entity type param #3402
Conversation
mkolodezny
changed the title
| @@ -83,16 +83,21 @@ const ( | |||
|
|
|||
| // The following are types related to Invariant. | |||
| type ( | |||
| // Execution is an execution which should be checked or fixed. | |||
| // Execution is a base type for executions which should be checked or fixed. | |||
| Execution struct { | |||
There was a problem hiding this comment.
Another idea is turn Execution into an interface with Getter method for each field and let concrete and current records extend this interface to include more methods. Then we can be more specific when writing function signatures and don't need to use interface{} everywhere. I think this can also address @andrewjdawson2016 's comments
This method should take in common.ConcreteExectuion. Invariants for concrete execution cannot be applied on current execution (and the reverse is also true) so at this level in code I don't think it makes sense to still be dealing with interfaces (or even dealing with union types at this level if we go with that path).
There was a problem hiding this comment.
Yeah, I like that proposal cc @meiliang86 Lets try to do it in the next change for step "introduce current execution type APIs".
mkolodezny
changed the title
…-workflow#3402) * Extend execution scanner workflow to handle multiple entity types
What changed?
This is the first step to have a separate scanner workflow for current executions (and for other types in the future).
The next steps are:
How did you test it?
unit tests