From b7c70aabae02617df8a8a9e441cbfc43290aad99 Mon Sep 17 00:00:00 2001 From: Marc Bonnici Date: Tue, 15 May 2018 13:38:08 +0100 Subject: [PATCH] doc: Remove `run_config` directory` Remove auto generated run_config directory, add to .gitignore and clear on `make clean` --- .gitignore | 1 + doc/Makefile | 1 + doc/source/run_config/Meta_Configuration.rst | 54 -------- doc/source/run_config/Run_Configuration.rst | 137 ------------------- 4 files changed, 2 insertions(+), 191 deletions(-) delete mode 100644 doc/source/run_config/Meta_Configuration.rst delete mode 100644 doc/source/run_config/Run_Configuration.rst diff --git a/.gitignore b/.gitignore index 0a4f86fd..8566dccd 100755 --- a/.gitignore +++ b/.gitignore @@ -28,3 +28,4 @@ libs/armeabi **/uiauto/app/libs/ **/uiauto/*.properties doc/source/developer_reference/instrument_method_map.rst +doc/source/runconfig/ diff --git a/doc/Makefile b/doc/Makefile index 92d38550..994c75a1 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -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 diff --git a/doc/source/run_config/Meta_Configuration.rst b/doc/source/run_config/Meta_Configuration.rst deleted file mode 100644 index 1a606763..00000000 --- a/doc/source/run_config/Meta_Configuration.rst +++ /dev/null @@ -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. - diff --git a/doc/source/run_config/Run_Configuration.rst b/doc/source/run_config/Run_Configuration.rst deleted file mode 100644 index 3fe7d508..00000000 --- a/doc/source/run_config/Run_Configuration.rst +++ /dev/null @@ -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`` -