mirror of
https://github.com/ARM-software/workload-automation.git
synced 2025-01-18 12:06:08 +00:00
doc: Remove run_config
directory`
Remove auto generated run_config directory, add to .gitignore and clear on `make clean`
This commit is contained in:
parent
52b2df427e
commit
b7c70aabae
1
.gitignore
vendored
1
.gitignore
vendored
@ -28,3 +28,4 @@ libs/armeabi
|
||||
**/uiauto/app/libs/
|
||||
**/uiauto/*.properties
|
||||
doc/source/developer_reference/instrument_method_map.rst
|
||||
doc/source/runconfig/
|
||||
|
@ -50,6 +50,7 @@ clean:
|
||||
rm -rf $(BUILDDIR)/*
|
||||
rm -rf source/plugins/*
|
||||
rm -rf source/developer_reference/instrument_method_map.rst
|
||||
rm -rf source/run_config/*
|
||||
|
||||
coverage:
|
||||
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
|
||||
|
@ -1,54 +0,0 @@
|
||||
user_directory:
|
||||
type: ``'str'``
|
||||
|
||||
Path to the user directory. This is the location WA will look for
|
||||
user configuration, additional plugins and plugin dependencies.
|
||||
|
||||
default: ``'~/.workload_automation'``
|
||||
|
||||
assets_repository:
|
||||
type: ``'str'``
|
||||
|
||||
The local mount point for the filer hosting WA assets.
|
||||
|
||||
logging:
|
||||
type: ``'LoggingConfig'``
|
||||
|
||||
WA logging configuration. This should be a dict with a subset
|
||||
of the following keys::
|
||||
|
||||
:normal_format: Logging format used for console output
|
||||
:verbose_format: Logging format used for verbose console output
|
||||
:file_format: Logging format used for run.log
|
||||
:color: If ``True`` (the default), console logging output will
|
||||
contain bash color escape codes. Set this to ``False`` if
|
||||
console output will be piped somewhere that does not know
|
||||
how to handle those.
|
||||
|
||||
default: ::
|
||||
|
||||
{
|
||||
color: True,
|
||||
verbose_format: %(asctime)s %(levelname)-8s %(name)s: %(message)s,
|
||||
regular_format: %(levelname)-8s %(message)s,
|
||||
file_format: %(asctime)s %(levelname)-8s %(name)s: %(message)s
|
||||
}
|
||||
|
||||
verbosity:
|
||||
type: ``'integer'``
|
||||
|
||||
Verbosity of console output.
|
||||
|
||||
default_output_directory:
|
||||
type: ``'str'``
|
||||
|
||||
The default output directory that will be created if not
|
||||
specified when invoking a run.
|
||||
|
||||
default: ``'wa_output'``
|
||||
|
||||
extra_plugin_paths:
|
||||
type: ``'list_of_strs'``
|
||||
|
||||
A list of additional paths to scan for plugins.
|
||||
|
@ -1,137 +0,0 @@
|
||||
execution_order:
|
||||
type: ``'str'``
|
||||
|
||||
Defines the order in which the agenda spec will be executed. At the
|
||||
moment, the following execution orders are supported:
|
||||
|
||||
``"by_iteration"``
|
||||
The first iteration of each workload spec is executed one after
|
||||
the other, so all workloads are executed before proceeding on
|
||||
to the second iteration. E.g. A1 B1 C1 A2 C2 A3. This is the
|
||||
default if no order is explicitly specified.
|
||||
|
||||
In case of multiple sections, this will spread them out, such
|
||||
that specs from the same section are further part. E.g. given
|
||||
sections X and Y, global specs A and B, and two iterations,
|
||||
this will run ::
|
||||
|
||||
X.A1, Y.A1, X.B1, Y.B1, X.A2, Y.A2, X.B2, Y.B2
|
||||
|
||||
``"by_section"``
|
||||
Same as ``"by_iteration"``, however this will group specs from
|
||||
the same section together, so given sections X and Y, global
|
||||
specs A and B, and two iterations, this will run ::
|
||||
|
||||
X.A1, X.B1, Y.A1, Y.B1, X.A2, X.B2, Y.A2, Y.B2
|
||||
|
||||
``"by_spec"``
|
||||
All iterations of the first spec are executed before moving on
|
||||
to the next spec. E.g. A1 A2 A3 B1 C1 C2.
|
||||
|
||||
``"random"``
|
||||
Execution order is entirely random.
|
||||
|
||||
allowed values: ``'by_iteration'``, ``'by_spec'``, ``'by_section'``, ``'random'``
|
||||
|
||||
default: ``'by_iteration'``
|
||||
|
||||
reboot_policy:
|
||||
type: ``'RebootPolicy'``
|
||||
|
||||
This defines when during execution of a run the Device will be
|
||||
rebooted. The possible values are:
|
||||
|
||||
``"as_needed"``
|
||||
The device will only be rebooted if the need arises (e.g. if it
|
||||
becomes unresponsive.
|
||||
|
||||
``"never"``
|
||||
The device will never be rebooted.
|
||||
|
||||
``"initial"``
|
||||
The device will be rebooted when the execution first starts,
|
||||
just before executing the first workload spec.
|
||||
|
||||
``"each_spec"``
|
||||
The device will be rebooted before running a new workload spec.
|
||||
|
||||
.. note:: this acts the same as each_iteration when execution order
|
||||
is set to by_iteration
|
||||
|
||||
``"each_iteration"``
|
||||
The device will be rebooted before each new iteration.
|
||||
|
||||
allowed values: ``'never'``, ``'as_needed'``, ``'initial'``, ``'each_spec'``, ``'each_iteration'``
|
||||
|
||||
default: ``'as_needed'``
|
||||
|
||||
device:
|
||||
type: ``'str'``
|
||||
|
||||
This setting defines what specific Device subclass will be used to
|
||||
interact the connected device. Obviously, this must match your
|
||||
setup.
|
||||
|
||||
default: ``'generic_android'``
|
||||
|
||||
retry_on_status:
|
||||
type: ``'list_of_Enums'``
|
||||
|
||||
This is list of statuses on which a job will be considered to have
|
||||
failed and will be automatically retried up to ``max_retries``
|
||||
times. This defaults to ``["FAILED", "PARTIAL"]`` if not set.
|
||||
Possible values are:
|
||||
|
||||
``"OK"``
|
||||
This iteration has completed and no errors have been detected
|
||||
|
||||
``"PARTIAL"``
|
||||
One or more instruments have failed (the iteration may still be
|
||||
running).
|
||||
|
||||
``"FAILED"``
|
||||
The workload itself has failed.
|
||||
|
||||
``"ABORTED"``
|
||||
The user interrupted the workload.
|
||||
|
||||
allowed values: ``RUNNING``, ``OK``, ``PARTIAL``, ``FAILED``, ``ABORTED``, ``SKIPPED``
|
||||
|
||||
default: ``['FAILED', 'PARTIAL']``
|
||||
|
||||
max_retries:
|
||||
type: ``'integer'``
|
||||
|
||||
The maximum number of times failed jobs will be retried before
|
||||
giving up. If not set.
|
||||
|
||||
.. note:: this number does not include the original attempt
|
||||
|
||||
default: ``2``
|
||||
|
||||
bail_on_init_failure:
|
||||
type: ``'boolean'``
|
||||
|
||||
When jobs fail during their main setup and run phases, WA will
|
||||
continue attempting to run the remaining jobs. However, by default,
|
||||
if they fail during their early initialization phase, the entire run
|
||||
will end without continuing to run jobs. Setting this to ``False``
|
||||
means that WA will instead skip all the jobs from the job spec that
|
||||
failed, but continue attempting to run others.
|
||||
|
||||
default: ``True``
|
||||
|
||||
allow_phone_home:
|
||||
type: ``'boolean'``
|
||||
|
||||
Setting this to ``False`` prevents running any workloads that are marked
|
||||
with 'phones_home', meaning they are at risk of exposing information
|
||||
about the device to the outside world. For example, some benchmark
|
||||
applications upload device data to a database owned by the
|
||||
maintainers.
|
||||
|
||||
This can be used to minimise the risk of accidentally running such
|
||||
workloads when testing confidential devices.
|
||||
|
||||
default: ``True``
|
||||
|
Loading…
x
Reference in New Issue
Block a user