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
- The Avocado configuration that is logged during a job execution is
now the dictionary that is produced by the
avocado.core.future.settingsmodule, 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
avocado.core.future.settingscode. 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
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 nrunand in the
avocado run --test-runner=nrunnerscenario.
- A brand new command,
jobsenables users to, among other things to list information about previously executed jobs. A command such as
avocado jobs showwill 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.
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
avocado.core.resolverfeature set, one will be able to see the resolvers with the
- The lower level
avocado.core.job.Job, instead of the
avocado runcommand, 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 runcommand to have results generated as intended.
- The lower level
avocado.core.job.Job, instead of the
avocado runcommand, 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 runcommand to have this feature available.
avocado sysinfocommand reverts to the pre-regression behavior, and now creates a directory following the
sysinfo-$TIMESTAMPpattern 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_uploadcommand, as part of the “results_upload” plugin, was fixed.
avocado.utils.disk.get_disks()now supports all block devices, like multipaths, LVs, etc. Previously it used to return only
- All of the
avocado.utils.gdbAPIs are now back to a working state, with many fixes related to bytes and strings, as well as buffered I/O caching fixes.
avocado.utils.pmemnow supports the
allnamespace behavior for newer versions of the
avocado.utils.software_managersupport for the Zypper package manager was improved to support the installation of package build dependencies.
- Refactors for the
avocado.core.nrunner.BaseRunnerAppthat 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 nruncommand is now done by means of the
--spawner=option that takes a spawner name, instead of the previous
--podman-spawneroption. This logic should be kept on the
avocado runimplementation and allow for new spawners to be used transparently.
- Internal reliability improvements to the N(ext) Runner status server implementation.
avocado nruncommand now respects the
--verbosecommand 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.
avocado.core.future.settingsnow 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,
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.