Rename the parameter to be clearer on the effect of the policy, as this
will cause WA to reset the device for each new job it runs regardless of
the iteration number.
Add support for "~~" special value that indicates that, when merging
into another set, all values from that set should in fact be dropped.
Apart from the unique merge semantics, "~~" just like any other "~"
value.
Delay the split of augmentations into instruments and output processors
until they are actually being accessed; keep them as a single set until
then. This makes tracking of merges from various configurations sources
easier
Add extra_plugin_paths setting which gets populated from WA_PLUGIN_PATHS
environment variable. This allows specifying additional locations to
scan for WA plugins.
Ensure that boot and runtime parameters always get initialized to an
obj_dict even when not explicitly specified. This will ensure they get
serialized and deserialized properly.
Catch exceptions raised when attempting to set value of a config point,
and re-raise as ConfigError with name associated with the value in the
config file.
- RebootPolicy: correctly handle being passed another instance of
RebootPolicy on creation; this a requirement for it to be usable as a
ConfigurationPoint kind.
- RebootPolicy: move static method to above __init__ (consistency).
- RunConfiguration: handle deserialization of 'device_config' entry.
- RunConfiguration: move static method to above __init__ (consistency).
Add support for loading plugins from packages that register themselves
with WA by writing their names into $WA_USER_DIRECTORY/packages.
This is functionality that existed in WA2 and was omitted in WA3 until
now.
Uses os.eviron as the default environment for creation of a
MetaConfiguration object, this allows an instance to be created without
providing any parameters and fixes re-creating an instance from pod.
--diable can now be used to disable both intruments and
result_processors from the command line (overriding configuration
files). Rename variable names to reflect this.
Replace update_enabled_instruments with update_augmentations, which
correctly splits instruments and results processors from augmentations
configuration values.
While instruments and processors are now handled uniformly in
configuration, they still need to be handled differently during actual
execution. This is the point where they get split again.
Rename ConfigurationPoint "instrumenation" to "augmentations". Unlike
WA2, in W3, instruments and result_porcessors are handled identically in
configuration (though there're still distinct pulgin types).
"instrumentation" and "result_porcessors" entries in configuration are
now aliases for the same configuration point, which is renamed to
"augmentations" to reflect the fact that it contains both types of
plugins.
This maintains the default behaviour of bailing out immediately if any workload
fails in initialize(), but adds a setting, bail_on_init_failure, to change this
behaviour optionally. This can be useful where WA is being used more as a batch
processor.
Some workloads, such as Geekbench, may phone home and report data about the
device they are running on. This poses a risk for users that are testing on
unreleased or otherwise confidential devices - perhaps they use a standard
agenda to run a large battery of tests, in which case they may forget to disable
these dangerous workloads.
This provides a mechanism to prevent running those workloads from running by
setting allow_phone_home=False in the user configuration.
When an agenda contains multiple sections, the same workload entry might
be used in construction of multiple job specs. Job spec construction may
mangle the workload entry. To prevent this from impacting other
jobs, use a deep copy of the workload entry when constructing a job
spec.
PluginCache.get_plugin_config assumes that no more configuration is to
be processed, and therefore config is final. As such, it is validating
that mandatory parameters are set. This assumption is invalid for
workload_parameters, however, as those need to be resolved on per-spec
basis, and cannot be globally cached.
This commit adds a prameter for get_plugin_config that indicates whether
or not it should consider the config to be final.
- Re-order Status entries so that higher severity entries have higher
enum values.
- Add set_status() to Job that ensures that a status is only set if it
is of higher severity (e.g. a Job that has been marked as PARTIAL by
an instrument will not be overwritten as OK by the runner).
- Retry no generates a new job, rather than re-enqueuing the existing
object; this ensures that the output status is tracked properly.
- Adjust ManagedCallback to set set job status to FAILED if it sees a
WorkloadError, and to PARTIAL other wise. The idea being that
instruments raise WorkloadError if they have a reason to believe
workload did not execute properly and indicated failure even if the
workload itself has failed to detect it (e.g. FPS instrument detecting
crashed content, where the workload might lack any feedback regarding
the crash). Other errors would indicate an issue with the instrument
itself, and so the job is marked as PARTIAL, as there is no reason to
suspect that the workload is at fault and the other results generated
for this execution may be valid.
