fix(docs/testrunner): remove double definition of testrunner args

These can be found in the in-code documentation.

Signed-off-by: Nadja Brix Koch <[email protected]>

Author: NaddiNadja

docs/source/testrunner/index.rst

@@ -55,43 +55,16 @@ In a :ref:`workflow <sec-resources-workflows>` the :ref:`core.testrunner
        random_order: false
        run_local: false
 
-Here you see three "special" arguments to the testrunner:
-
-args
-  These arguments are passed verbatim to **pytest**, resulting in the following
-  invocation:
-
-  .. code-block:: bash
-
-    pytest \
-      --config cijoe-config.toml \
-      --output output \
-      -k "filtering" my_tests
-
-  The key difference between invoking the ``pytest`` command-line tool directly
-  and using the **cijoe** script :ref:`core.testrunner <sec-packages-core-testrunner>`
-  in the **cijoe** workflow is that the latter integrates the **pytest** report into 
-  **cijoe**, producing a cohesive and standalone report.
-
-random_order
-  This option **scrambles** the order in which tests are executed. It is
-  generally recommended, as it helps reduce inter-test dependencies and
-  assumptions about the environment's state.
-
-run_local
-  This option can take some time to understand fully. It controls where
-  **pytest** is executed.
-
-  - When ``run_local: false``, the behavior is "normal" — the
-    **pytest** command-line tool is executed on the **initiator**, and
-    the :ref:`configuration-file <sec-resources-configs>` provided to the
-    **cijoe** command-line tool is passed verbatim to **pytest**.
-
-  - When ``run_local: true``, this behavior changes. The **pytest**
-    command-line tool is executed on the **target** instead. Before execution,
-    the provided :ref:`configuration-file <sec-resources-configs>` is cloned,
-    modified by removing the transport section, and then transferred to the
-    **target**. Once transferred, **pytest** is executed on the **target** using
-    the modified configuration file. Finally, the **pytest** report generated on
-    the **target** is transferred back to the **initiator** for integration into
-    the **cijoe** report.
+This will result in the following invocation on the initiator:
+
+.. code-block:: bash
+
+  pytest \
+    --config cijoe-config.toml \
+    --output output \
+    -k "filtering" my_tests
+
+The key difference between invoking the ``pytest`` command-line tool directly
+and using the **cijoe** script :ref:`core.testrunner <sec-packages-core-testrunner>`
+in the **cijoe** workflow is that the latter integrates the **pytest** report into 
+**cijoe**, producing a cohesive and standalone report.

src/cijoe/core/scripts/testrunner.py

@@ -33,13 +33,13 @@ def test_foo(cijoe):
 by ``args.run_local``, with boolean value True / False. The default is
 True.
 
-* args.run_local: True
+* ``args.run_local: True``
 
   This is the most common, invoking pytest locally, which in turn will be using
   the same config as all other cijoe-scripts. To clarify, cijoe will execute
   'pytest' in the same environment/system where the ``cijoe`` cli was executed.
 
-* args.run_local: False
+* ``args.run_local: False``
 
   This is a special-case, where a collection of pytests uses cijoe, but only the
   configuration, the that the pytest verify is Python code / statements /
@@ -81,9 +81,15 @@ def __call__(self, parser, namespace, values, option_string=None):
         choices=["true", "false"],
         default=True,
         action=StringToBoolAction,
-        help="Whether the tests should be run in random order",
+        help=(
+            "Whether the tests should be run in random order. "
+            "This is generally recommended, as it helps reduce inter-test "
+            "dependencies and assumptions about the environment's state"
+        ),
+    )
+    parser.add_argument(
+        "--args", type=str, help="Additional arguments passed verbatim to 'pytest'."
     )
-    parser.add_argument("--args", type=str, help="Additional args given to 'pytest'")
 
 
 def pytest_cmdline(args, config_path, output_path, reportlog_path):