- Implemented result processor infrastructured
- Corrected some status tracking issues (differed between states
and output).
- Added "csv" and "status" result processors (these will be the default
enabled).
- Fixed up some of the signal map for instrumentation
- Changed how priorites are specified -- no longer method name prefixes
but dedicated decorators, including an easy way of specifying a custom
priority level (no longer need to manually connect signals)
- Updated ExecutionTimeInstrument to work with the new system
- Also removed some dead code
"params" is interpreted differently in section vs workload entires in
the agenda; previously, this was handled in the generic entry
construciton function by examining the ID prefix of the entry to
distinguish between the two.
This is unreliable as the user may specify their own IDs that won't have
the expected prefixes. To handle this, the "params" alias resolution for
sections is now handled in section specific part of entry processing
(workloads are handled autmatically because that is the default for
the corresponding JobConfig config point).
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Added 3 decorators to enabled methods to be executed conditionally:
- Once for each method instance.
- Once for each class.
- Only once per environment including any derived classes.
Added execution control allowing for different environments to
be used in order to determine how often decorated commands should be ran.
Added relevant unittests for the above decorators.
This had moved to now be done by plugin cache so it has been removed
from wlauto.core.configuration.configuration and any referenced to it
have been changed to use plugin cache instead.
Renamed `__configuration` to `config_points` and in the case of
RunConfiguration it was split into `config_points` and `meta_data`
where `meta_data` contains config points for run meta data like
project name/stage ect.
WA2 only supported a single config file but the way WA3's configuration
parser works there can be as many and the user needs. They will be prioritied
in the order they are specified. e.g in `wa run agenda.yaml -c 1.yaml -c 2.yaml`
`1.yaml` will be applied first and `2.yaml` will be applied on top of that.
