Merge pull request avocado-framework#4908 from clebergnu/switch_defau…

…lt_runner_v2

Switch default runner [v2]

.cirrus.yml

@@ -30,9 +30,9 @@ redhat_egg_task:
        - python3 setup.py bdist_egg
        - mv dist/avocado_framework-*egg /tmp
        - python3 setup.py clean --all
-       - python3 -c 'import sys; import glob; sys.path.insert(0, glob.glob("/tmp/avocado_framework-*.egg")[0]); from avocado.core.main import main; sys.exit(main())' run /bin/true
+       - python3 -c 'import sys; import glob; sys.path.insert(0, glob.glob("/tmp/avocado_framework-*.egg")[0]); from avocado.core.main import main; sys.exit(main())' run --test-runner=runner /bin/true
        - cd /tmp
-       - python3 -c 'import sys; from pkg_resources import require; require("avocado-framework"); from avocado.core.main import main; sys.exit(main())' run /bin/true
+       - python3 -c 'import sys; from pkg_resources import require; require("avocado-framework"); from avocado.core.main import main; sys.exit(main())' run --test-runner=runner /bin/true
     container:
         matrix:
           - image: fedora:33
@@ -58,9 +58,9 @@ debian_egg_task:
        - python3 setup.py bdist_egg
        - mv dist/avocado_framework-*egg /tmp
        - python3 setup.py clean --all
-       - python3 -c 'import sys; import glob; sys.path.insert(0, glob.glob("/tmp/avocado_framework-*.egg")[0]); from avocado.core.main import main; sys.exit(main())' run /bin/true
+       - python3 -c 'import sys; import glob; sys.path.insert(0, glob.glob("/tmp/avocado_framework-*.egg")[0]); from avocado.core.main import main; sys.exit(main())' run --test-runner=runner /bin/true
        - cd /tmp
-       - python3 -c 'import sys; from pkg_resources import require; require("avocado-framework"); from avocado.core.main import main; sys.exit(main())' run /bin/true
+       - python3 -c 'import sys; from pkg_resources import require; require("avocado-framework"); from avocado.core.main import main; sys.exit(main())' run --test-runner=runner /bin/true
     container:
         matrix:
           - image: debian:10.10

.github/workflows/ci.yml

@@ -35,7 +35,7 @@ jobs:
       - name: Avocado version
         run: avocado --version
       - name: Avocado smoketest
-        run: python -m avocado run passtest.py
+        run: python -m avocado run examples/tests/passtest.py
       - name: Tree static check, unittests and fast functional tests
         env:
           AVOCADO_LOG_DEBUG: "yes"

avocado/plugins/list.py

@@ -234,17 +234,31 @@ def configure(self, parser):
                                  positional_arg=True)
         loader.add_loader_options(parser, 'list')
 
-        help_msg = ('What is the method used to detect tests? If --resolver '
-                    'used, Avocado will use the Next Runner Resolver method. '
-                    'If not the legacy one will be used.')
+        help_msg = ('Uses the Avocado resolver method (part of the nrunner '
+                    'architecture) to detect tests. This is enabled by '
+                    'default and exists only for compatibility purposes, '
+                    'and will be removed soon. To use the legacy (loader) '
+                    'method for finding tests, set the "--loader" option')
         settings.register_option(section='list',
-                                 key='resolver',
+                                 key='compatiblity_with_resolver_noop',
                                  key_type=bool,
-                                 default=False,
+                                 default=True,
                                  help_msg=help_msg,
                                  parser=parser,
                                  long_arg='--resolver')
 
+        help_msg = ('Uses the Avocado legacy (loader) method for finding '
+                    'tests. This option will exist only for a transitional '
+                    'period until the legacy (loader) method is deprecated '
+                    'and removed')
+        settings.register_option(section='list',
+                                 key='resolver',
+                                 key_type=bool,
+                                 default=True,
+                                 help_msg=help_msg,
+                                 parser=parser,
+                                 long_arg='--loader')
+
         help_msg = ('Writes runnable recipe files to a directory. Valid only '
                     'when using --resolver.')
         settings.register_option(section='list.recipes',

avocado/plugins/run.py

@@ -103,11 +103,12 @@ def configure(self, parser):
                     'installed and active implementations.  You can run '
                     '"avocado plugins" and find the list of valid runners '
                     'under the "Plugins that run test suites on a job '
-                    '(runners) section.  Defaults to "runner", which is '
-                    'the conventional and traditional runner.')
+                    '(runners) section.  Defaults to "nrunner", which is '
+                    'the new runner.  To use the conventional and traditional '
+                    'runner, use "runner".')
         settings.register_option(section='run',
                                  key='test_runner',
-                                 default='runner',
+                                 default='nrunner',
                                  help_msg=help_msg,
                                  parser=parser,
                                  long_arg='--test-runner',

docs/source/guides/contributor/chapters/plugins.rst

@@ -260,14 +260,14 @@ Resolving magic tests
 ---------------------
 
 Resolving the "pass" and "fail" references that the magic plugin knows about
-can be seen by running ``avocado list --resolver pass fail``::
+can be seen by running ``avocado list pass fail``::
 
   magic pass
   magic fail
 
 And you may get more insight into the resolution results, by adding a
 verbose parameter and another reference.  Try running ``avocado -V
-list --resolver pass fail something-else``::
+list pass fail something-else``::
 
   Type  Test Tag(s)
   magic pass
@@ -310,9 +310,9 @@ tests is through a command starting with ``avocado
 run --test-runner=nrunner``.
 
 To run both the ``pass`` and ``fail`` magic tests, you'd run
-``avocado run --test-runner=nrunner -- pass fail``::
+``avocado run -- pass fail``::
 
-  $ avocado run --test-runner=nrunner -- pass fail
+  $ avocado run -- pass fail
   JOB ID     : 86fd45f8c1f2fe766c252eefbcac2704c2106db9
   JOB LOG    : $HOME/avocado/job-results/job-2021-02-05T12.43-86fd45f/job.log
    (1/2) pass: STARTED

docs/source/guides/contributor/chapters/runners.rst

@@ -1,11 +1,11 @@
 .. _nrunner:
 
-The "nrunner" and "runner" test runner
-======================================
+The "nrunner" and "legacy runner" test runner
+=============================================
 
 This section details a test runner called "nrunner", also known as
 N(ext) Runner, and the architecture around.  It compares it with the
-older (and default) test runner, simply called "runner".
+older, legacy (no longer default) test runner, simply called "runner".
 
 At its essence, this new architecture is about making Avocado more
 capable and flexible, and even though it starts with a major internal
@@ -17,18 +17,18 @@ most of the N(ext)Runner code, but as development continues, it's
 spreading around to other places in the Avocado source tree.  Other
 components with different and seemingly unrelated names, say the
 "resolvers" or the "spawners", are also pretty much about the
-N(ext)Runner and are not used in the current (default) architecture.
+nrunner and are not used in the legacy architecture.
 
 Motivation
 ----------
 
 There are a number of reasons for introducing a different architecture
 and implementation.  Some of them are related to limitations found in
-the current implementation, that were found to be too hard to remove
+the legacy implementation, that were found to be too hard to remove
 without major breakage.  Also, missing features that are deemed
 important would be a better fit wihin a different architecture.
 
-For instance, these are the current limitations of the Avocado test
+For instance, these are the limitations of the Avocado legacy test
 runner:
 
 * Test execution limited to the same machine, given that the
@@ -58,23 +58,23 @@ implemented under a different architecture and implementation:
 * Simplified and automated deployment of the runner component into
   execution environments such as containers and virtual machines
 
-Current and N(ext) Runner components of Avocado
+NRunner and Legacy Runner components of Avocado
 -----------------------------------------------
 
 Whenever we mention the **current** architecture or implementation,
-we are talking about:
+we are talking about the nrunner.  It includes:
 
 * ``avocado list`` command
 * ``avocado run`` command
-* :mod:`avocado.core.loader` module to find tests
-
-Whenever we talk about the N(ext)Runner, we are talking about:
-
-* ``avocado list --resolver`` command
-* ``avocado run --test-runner=nrunner`` command
 * :mod:`avocado.core.resolver` module to resolve tests
 * :mod:`avocado.core.spawners` modules to spawn tasks
 
+Whenever we talk about legacy runner, we are talking about:
+
+* ``avocado list --loader`` command
+* ``avocado run --test-runner=runner`` command
+* :mod:`avocado.core.loader` module to find tests
+
 Basic Avocado usage and workflow
 --------------------------------
 
@@ -98,16 +98,17 @@ this is not a requirement.  Avocado calls those "names" given as arguments
 to ``avocado run`` "test references", because they are references that
 hopefully "point to" tests.
 
-Here we need to make a distincion between the current architecture,
-and the architecture which the N(ext)Runner introduces.  In the
-current Avocado test runner, this process happens by means of the
-:mod:`avocado.core.loader` module.  The very same mechanism, is used
-when listing tests.  This produces an internal representation of
-the tests, which we simply call a "factory"::
-
-  +--------------------+    +---------------------+
-  | avocado list | run | -> | avocado.core.loader | ---+
-  +--------------------+    +---------------------+    |
+Here we need to make a distincion between the legacy architecture, and
+the nrunner architecture.  In the legacy Avocado test runner, this
+process happens by means of the :mod:`avocado.core.loader` module.
+The very same mechanism, is used when listing tests.  This produces an
+internal representation of the tests, which we simply call a
+"factory"::
+
+  +----------------------------------+    +---------------------+
+  | avocado list --loader            | -> | avocado.core.loader |
+  | avocado run --test-runner=runner |    |                     |
+  +----------------------------------+    +---------------------+
                                                        |
     +--------------------------------------------------+
     |
@@ -134,22 +135,22 @@ the tests, which we simply call a "factory"::
 
   ...
 
-Because the N(ext)Runner is living side by side with the current
-architecture, command line options have been introduced to distinguish
-between them: ``avocado list --resolver`` and ``avocado
-run --test-runner=nrunner``.
-
-On the N(ext)Runner architecture, a different terminology and
-foundation is used.  Each one of the test references given to ``list
---resolver`` or ``run --test-runner=runner`` will be "resolved" into
-zero or more tests.  Being more precise and verbose, resolver plugins
-will produce :class:`avocado.core.resolver.ReferenceResolution`, which
-contain zero or more :class:`avocado.core.nrunner.Runnable`, which are
-described in the following section.  Overall, the process looks like::
-
-  +-------------------------+    +-----------------------+
-  | avocado list --resolver | -> | avocado.core.resolver | ---+
-  +-------------------------+    +-----------------------+    |
+Because the nrunner is now the default implementation, to distinguish
+between implementations and select the legacy implementation you must
+use: ``avocado list --loader`` and ``avocado
+run--test-runner=runner``.
+
+On the nrunner architecture, a different terminology and
+foundation is used.  Each one of the test references given to ``list``
+or ``run`` will be "resolved" into zero or more tests.  Being more
+precise and verbose, resolver plugins will produce
+:class:`avocado.core.resolver.ReferenceResolution`, which contain zero
+or more :class:`avocado.core.nrunner.Runnable`, which are described in
+the following section.  Overall, the process looks like::
+
+  +--------------------+    +-----------------------+
+  | avocado list | run | -> | avocado.core.resolver | ---+
+  +--------------------+    +-----------------------+    |
                                                               |
     +---------------------------------------------------------+
     |
@@ -193,21 +194,21 @@ a given action.  This action, within the realm of software development
 with automated testing, has to do with the output or outcome of a
 "code payload" when executed under a given controlled environment.
 
-The current Avocado architecture uses the "Test Factories" described
+The legacy Avocado architecture uses the "Test Factories" described
 earlier to load and execute such a "code payload".  Each of those test
 factories contain the name of a Python class to be instantiated, and a
 number of arguments that will be given to that class initialization.
 
-So the primary "code payload" for every Avocado test in the current
+So the primary "code payload" for every Avocado test in the legacy
 architecture will always be Python code that inherits from
 :class:`avocado.core.test.Test`.  Even when the user wants to run a
-standalone executable (a ``SIMPLE`` test in the current architecture
+standalone executable (a ``SIMPLE`` test in the legacy architecture
 terminology), that still means loading and instantiating (effectively
 executing) the Python class' :class:`avocado.core.test.SimpleTest`
 code.
 
 Once all the test factories are found by :mod:`avocado.core.loader`,
-as described in the previous section, the current architecture runs
+as described in the previous section, the legacy architecture runs
 tests roughly following these steps:
 
 1. Create one (and only one) queue to communicate with the test
@@ -239,8 +240,8 @@ architecture listed earlier.  It should be clear that:
    tests in a local process is tightly coupled and hard coded into the
    test execution code
 
-Now let's shift our attention to the N(ext)Runner architecture.  In
-the N(ext)Runner architecture, a
+Now let's shift our attention to the nrunner architecture.  In
+the nrunner architecture, a
 :class:`avocado.core.nrunner.Runnable` describe a "code payload" that
 will be executed, but they are not executable code themselves.
 Because they are **data** and not **code**, they are easily serialized
@@ -391,7 +392,7 @@ create Runnables based on the user's input from the command line::
 Runner
 ~~~~~~
 
-A Runner, within the context of the N(ext)Runner architecture, is an
+A Runner, within the context of the nrunner architecture, is an
 active entity.  It acts on the information that a runnable contains,
 and quite simply, should be able to run what the Runnable describes.
 

man/avocado.rst

@@ -87,8 +87,9 @@ Options for subcommand `run` (`avocado run --help`)::
                             installed and active implementations. You can run
                             "avocado plugins" and find the list of valid runners
                             under the "Plugins that run test suites on a job
-                            (runners) section. Defaults to "runner", which is the
-                            conventional and traditional runner.
+                            (runners) section. Defaults to "nrunner", which is the
+                            new runner. To use the conventional and traditional
+                            runner, use "runner".
       -d, --dry-run         Instead of running the test only list them and log
                             their params.
       --dry-run-no-cleanup  Do not automatically clean up temporary directories
@@ -364,9 +365,15 @@ Options for subcommand `list` (`avocado list --help`)::
 
     optional arguments:
       -h, --help            show this help message and exit
-      --resolver            What is the method used to detect tests? If --resolver
-                            used, Avocado will use the Next Runner Resolver
-                            method. If not the legacy one will be used.
+      --resolver            Uses the Avocado resolver method (part of the nrunner
+                            architecture) to detect tests. This is enabled by
+                            default and exists only for compatibility purposes,
+                            and will be removed soon. To use the legacy (loader)
+                            method for finding tests, set the "--loader" option
+      --loader              Uses the Avocado legacy (loader) method for finding
+                            tests. This option will exist only for a transitional
+                            period until the legacy (loader) method is deprecated
+                            and removed
       --write-recipes-to-directory DIRECTORY
                             Writes runnable recipe files to a directory. Valid
                             only when using --resolver.

optional_plugins/html/tests/test_html_result.py

@@ -17,8 +17,8 @@ def setUp(self):
     def test_sysinfo_html_output(self):
         html_output = "{}/output.html".format(self.tmpdir.name)
         cmd_line = ('{} run --html {} --job-results-dir {} '
-                    'passtest.py'.format(AVOCADO, html_output,
-                                         self.tmpdir.name))
+                    'examples/tests/passtest.py'.format(AVOCADO, html_output,
+                                                        self.tmpdir.name))
         result = process.run(cmd_line)
         expected_rc = exit_codes.AVOCADO_ALL_OK
         self.assertEqual(result.exit_status, expected_rc,

optional_plugins/varianter_yaml_to_mux/tests/test_functional.py

@@ -136,6 +136,7 @@ def test_run_mplex_params(self):
                             ('/run/long', 'This is very long\nmultiline\ntext.')):
             variant, msg = variant_msg
             cmd_line = ('%s run --job-results-dir %s --disable-sysinfo '
+                        '--test-runner=runner '
                         'examples/tests/env_variables.sh '
                         '-m examples/tests/env_variables.sh.data/env_variables.yaml '
                         '--mux-filter-only %s'
@@ -197,9 +198,12 @@ class DryRun(unittest.TestCase):
 
     def test_dry_run(self):
         cmd = ("%s run --disable-sysinfo --dry-run --dry-run-no-cleanup --json - "
+               "--test-runner=runner "
                "--mux-inject foo:1 bar:2 baz:3 foo:foo:a "
                "foo:bar:b foo:baz:c bar:bar:bar "
-               "-- passtest.py failtest.py gendata.py " % AVOCADO)
+               "-- examples/tests/passtest.py "
+               "examples/tests/failtest.py "
+               "examples/tests/gendata.py " % AVOCADO)
         number_of_tests = 3
         result = json.loads(process.run(cmd).stdout_text)
         log = ''