mirror of
https://github.com/ARM-software/workload-automation.git
synced 2025-01-18 20:11:20 +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:
Marc Bonnici
setrofim
parent
52b2df427e
commit
b7c70aabae
1
.gitignore
vendored
1
.gitignore
vendored
@ -28,3 +28,4 @@ libs/armeabi
|
|||||||
**/uiauto/app/libs/
|
**/uiauto/app/libs/
|
||||||
**/uiauto/*.properties
|
**/uiauto/*.properties
|
||||||
doc/source/developer_reference/instrument_method_map.rst
|
doc/source/developer_reference/instrument_method_map.rst
|
||||||
|
doc/source/runconfig/
|
||||||
|
|||||||
@ -50,6 +50,7 @@ clean:
|
|||||||
rm -rf $(BUILDDIR)/*
|
rm -rf $(BUILDDIR)/*
|
||||||
rm -rf source/plugins/*
|
rm -rf source/plugins/*
|
||||||
rm -rf source/developer_reference/instrument_method_map.rst
|
rm -rf source/developer_reference/instrument_method_map.rst
|
||||||
|
rm -rf source/run_config/*
|
||||||
|
|
||||||
coverage:
|
coverage:
|
||||||
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/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