Examplar has reached about the 2/3rds completion mark.
Parsed ‘/home/phanes/Development/internal/Examplar/conf/config.json’ with 2 element(s).
Parsed ‘/home/phanes/Development/internal/Examplar/conf/units/all_test.units’ with 1 element(s).
Added unit "independent test 1" to Suite.
Added unit "independent test 2" to Suite.
Added unit "dependent test" to Suite.
Parsed ‘/home/phanes/Development/internal/Examplar/conf/plans/test.plan’ with 1 element(s).
Added task "independent test 1" to Plan.
Added task "independent test 2" to Plan.
Added dependency "independent test 1" to task "dependent test".
Added task "dependent test" to Plan.
Loaded definition "independent test 1" for task "independent test 1".
Loaded definition "independent test 2" for task "independent test 2".
Loaded definition "dependent test" for task "dependent test".
Ready to execute all tasks in Plan.
Process finished with exit code 0[/code]
At this point I’m ready to start implementing the execution of tasks in the plan.
I’ll need to decide on the behaviour of execution.
Currently it executes the executable at
units[i].target. If that returns a non-0 or does not print what is in
units[i].output to STDOUT, then it will check if
units[i].rectify is set — if it is, then it will execute a heal attempt at filepath
So far it’s a pretty concrete process.
There is a decision to make. Should it execute
rectifier and then
target again to see if it passed, or should it assume
rectifier heals the broken condition? I believe the former is the case: It should alternate between
rectifier until a 0 exit code with
output printed to STDOUT. However, I would prefer to avoid an infinite loop in cases that, for whatever reason a user’s
rectifier script is not healing the condition that causes
target to fail.
Without intervention, I will have it execute
rectifier on fail, and then
target again before checking
units[i].required. If that bool is set to true it should halt the entire plan. If not, it should note it and move on.
This behaviour will be important later in determining how dependencies really work in Examplar. If a dependency is listed in a Task, and that dependency failed but has a
required attribute of
false, then we’d be overriding that
required attribute by checking for the
completion flag of that failed dependency and simply halting. This may be desired behaviour. I am seeking feedback on this.
Data Integrity Assurance
There’s still some work to do with data integrity assurance during linking of tasks and units but it is currently working reliably when fed intact files.
The exceptions will need reworked eventually. They are accurate but somewhat lacking in references. Don’t want to do that to anyone who would end up supporting this. Luckily I’ve used strict OOP designs in this so it should be pretty easy to rework the exception later when the time comes.
I’ve moved to Doxygen style documentation for all classes and methods.
We’re at a point where logging patterns should be considered.