=============
80.0 Parasite
=============
The Avocado team is proud to present another release: Avocado 80.0,
AKA "Parasite", is now available!
This release (and the previous one) contains mainly internal changes
in preparation for the N(ext) Runner architecture to replace the
current one, and for the Job API to become a fully supported feature.
It's expected that release 81.0 will be the last release containing
major changes before a "pre-LTS release". This way, development
sprint #82 will focus on stabilization, culminating in an 82.0 LTS
release.
Release documentation: `Avocado 80.0
`_
Users/Test Writers
==================
* The Avocado configuration that is logged during a job execution is
now the dictionary that is produced by the
:mod:`avocado.core.future.settings` module, instead of the
configuration file(s) content. This is relevant because this
configuration contains the result of everything that affects a job,
such as defaults registered by plugins, command line options, all
in addition to the configuration file. The goal is to have more
consistent behavior and increased job "replayability".
* As explained in the previous point, an Avocado Job is now configured
by the configuration set by the :mod:`avocado.core.future.settings`
code. Because of the way this module works, options need to be
registered, before the content on the config files can be considered
valid values for a given option. This has been done for a large
number of Avocado features, but be advised that some configuration
may not yet be seen by the job, because of the lack of option
registration. We're working to identify and enable complete feature
configuration on the next release.
* The "log level" of an Avocado is now defined using the standard
Python level names. If you have a custom configuration for this
setting, you may need to adjust it (usually only a matter of
lowercase to uppercase).
* The runner that will be used in a job can now be defined in the
command line (in addition to being previously supported by a
configuration entry). If you want to try out the experimental
N(ext) Runner, for instance, you should be able to use a command
such as ``avocado run --test-runner=nrunner /path/to/my/tests``.
* The N(ext) Runner received support for job timeouts, and won't
run further tests if the timeout expires.
* The N(ext) Runner now users the same Test ID that the current test
runner uses, both in the to-be-removed ``avocado nrun`` and in the
``avocado run --test-runner=nrunner`` scenario.
* A brand new command, ``jobs`` enables users to, among other things
to list information about previously executed jobs. A command such
as ``avocado jobs show`` will show the latest job information.
* The "standalone jobs" feature has been **deprecated**. This feature
allows users to write a test, that contains a builtin job executor
for such a test that allows the test file to be executable. This
will be replaced by the Job API, which transparently supports the
specification of the **same** file as a source of tests.
* The ``avocado run --loaders ?`` command to list available loaders
has been removed. This command line usage pattern is not consistent
across Avocado (or follows the POSIX guidelines), and with the
N(ext) Runner architecture depending on the
:mod:`avocado.core.resolver` feature set, one will be able to see
the resolvers with the ``avocado plugins`` command.
* The lower level :class:`avocado.core.job.Job`, instead of the
``avocado run`` command, is now responsible for generating result
files, such as the JSON (``results.json``), xUnit (``results.xml``),
etc. This allows users of the Job API, as well as users of the
``avocado run`` command to have results generated as intended.
* The lower level :class:`avocado.core.job.Job`, instead of the
``avocado run`` command, is now also responsible for collecting the
job-level system information (AKA ``sysinfo``). This allows users
of the Job API, as well as users of the ``avocado run`` command to
have this feature available.
Bug Fixes
=========
* The ``avocado sysinfo`` command reverts to the pre-regression
behavior, and now creates a directory following the
``sysinfo-$TIMESTAMP`` pattern and uses that for the content of the
sysinfo output, instead of using the current directory by default.
* An incorrect configuration key name of the ``result_upload`` command,
as part of the "results_upload" plugin, was fixed.
* :func:`avocado.utils.disk.get_disks` now supports all block devices,
like multipaths, LVs, etc. Previously it used to return only
``/dev/sdX`` devices.
Utility APIs
============
* All of the :class:`avocado.utils.gdb` APIs are now back to a working
state, with many fixes related to bytes and strings, as well as
buffered I/O caching fixes.
* :mod:`avocado.utils.pmem` now supports the ``all`` namespace behavior
for newer versions of the ``ndctl`` utility.
* :mod:`avocado.utils.software_manager` support for the Zypper package
manager was improved to support the installation of package build
dependencies.
Internal Changes
================
* Refactors for the :class:`avocado.core.nrunner.BaseRunnerApp` that
made the list of commands available as a class attribute avoiding
multiple resolutions and string manipulation when a command needs to
be resolved.
* The N(ext) Runner received some foundation work for the persistence
and retrieval of test generated artifacts. The work takes into
consideration that tests may be run disconnected of the the overall
test job, and the job can retrieve those at a later time.
* The N(ext) Runner spawner selection is on the ``avocado nrun``
command is now done by means of the ``--spawner=`` option that takes
a spawner name, instead of the previous ``--podman-spawner`` option.
This logic should be kept on the ``avocado run`` implementation and
allow for new spawners to be used transparently.
* Internal reliability improvements to the N(ext) Runner status server
implementation.
* The ``avocado nrun`` command now respects the ``--verbose`` command
line option, producing less output if it's not given.
* The core sysinfo implementation received cleanups and now makes now
distinction between collection at job or test time, and works on
both or at any other moment.
* The :mod:`avocado.core.future.settings` now allows command line
parsers to be added to previously registered options. This allows
features that don't require a command line to register options, and
plugins that want to control such options with a command line to do
so in a decoupled and extensive way.
* A new plugin interface, :class:`avocado.core.plugin_interfaces.Init`,
was introduced to allow plugins that need to initialize themselves
very early (and automatically) on Avocado. Such plugins have no
knowledge of the current configuration, but may use that interface
to register new options (among other things).
* An Avocado Job is now run as part of the selftests suite, and more
can be added. This is intended to avoid breakage of the Job API as
it gets closer to become a supported feature.
For more information, please check out the complete
`Avocado changelog
`_.