[Avocado-devel] Avocado 0.24.0 released!

[Lucas Meneghel Rodrigues]

We are proud to announce the new Avocado 0.24.0 release! This time, we 
had made a number of API changes to reflect some good practices in API 
development, and changes to the multiplexer, that is making large steps 
towards a production ready state. Let's break down the changes:

Core/General API isolation

In order to avoid user confusion, now the avocado API has a clear 
separation with regards to what it's supposed to be used by test 
developers, and what is supposed to be used by plugin/core application 
developers:

avocado.core is restricted to plugin/core app developers
avocado can be used by both test developers and plugin/core app 
developers
Breakdown of changes:

avocado.core.data_dir -> avocado.data_dir
avocado.plugins -> avocado.core.plugins
avocado.remote -> avocado.core.remote
avocado.job -> avocado.core.job
avocado.job.main -> avocado.main
avocado.loader -> avocado.core.loader
avocado.output -> avocado.core.output
avocado.loader -> avocado.core.loader
avocado.parser -> avocado.core.parser
avocado.runner -> avocado.core.runner
avocado.sysinfo -> avocado.core.sysinfo
avocado.external.gdbmi_parser -> avocado.core.gdbmi_parser
avocado.external.spark -> avocado.core.spark
avocado.cli.app -> avocado.core.app
avocado.exceptions -> avocado.core.exceptions
Multiplexer

The multiplexer has gone through changes on the parameters retrieval 
API. The new way of retrieving params is through the get API, that has 
the form::

get(key, path, default)
The avocado.test.Test.params object is no longer a dictionary, and it's 
not possible to refer to the values through the shortcut 
avocado.test.Test.params.key anymore.

Example of old usage::

c_file = self.get_data_path(self.params.get('source', 'doublefree.c'))
This statement has to be updated to::

c_file = self.get_data_path(self.params.get('source', 
default='doublefree.c'))
Otherwise the default doublefree.c value will be taken as the retrieval 
path, then c_file would be None.

The multiplexer file format also has a new !mux tag, that means to 
recursively multiplex all nodes below the specified tag. By default 
now, we don't multiplex until the !mux tag is specified. Let's consider 
the following file::

hw:
    cpu:
    intel:
        cpu_CFLAGS: '-march=core2'
    amd:
        cpu_CFLAGS: '-march=athlon64'
    arm:
        cpu_CFLAGS: '-mabi=apcs-gnu -march=armv8-a -mtune=arm8'
    disk:
    scsi:
        disk_type: 'scsi'
    virtio:
        disk_type: 'virtio'
distro:
    fedora:
    init: 'systemd'
    mint:
    init: 'systemv'
env:
    debug:
    opt_CFLAGS: '-O0 -g'
    prod:
    opt_CFLAGS: '-O2'
Here, the nodes cpu, disk, distro and env are the ones we actually want 
to combine, whilehw is just for organization purposes (we don't want to 
combine hw with distro, really).

New version, with !mux:

hw:
    cpu: !mux
    intel:
        cpu_CFLAGS: '-march=core2'
    amd:
        cpu_CFLAGS: '-march=athlon64'
    arm:
        cpu_CFLAGS: '-mabi=apcs-gnu -march=armv8-a -mtune=arm8'
    disk: !mux
    scsi:
        disk_type: 'scsi'
    virtio:
        disk_type: 'virtio'
distro: !mux
    fedora:
    init: 'systemd'
    mint:
    init: 'systemv'
env: !mux
    debug:
    opt_CFLAGS: '-O0 -g'
    prod:
    opt_CFLAGS: '-O2'
This way we can keep using hw as a organization label, not interfering 
with our final purpose of combining only cpu, disk, distro and env. The 
variants generated with the new tag arrangement are:

Variant 1:    /hw/cpu/intel, /hw/disk/scsi, /distro/fedora, /env/debug
Variant 2:    /hw/cpu/intel, /hw/disk/scsi, /distro/fedora, /env/prod
Variant 3:    /hw/cpu/intel, /hw/disk/scsi, /distro/mint, /env/debug
Variant 4:    /hw/cpu/intel, /hw/disk/scsi, /distro/mint, /env/prod
Variant 5:    /hw/cpu/intel, /hw/disk/virtio, /distro/fedora, /env/debug
Variant 6:    /hw/cpu/intel, /hw/disk/virtio, /distro/fedora, /env/prod
Variant 7:    /hw/cpu/intel, /hw/disk/virtio, /distro/mint, /env/debug
Variant 8:    /hw/cpu/intel, /hw/disk/virtio, /distro/mint, /env/prod
Variant 9:    /hw/cpu/amd, /hw/disk/scsi, /distro/fedora, /env/debug
Variant 10:    /hw/cpu/amd, /hw/disk/scsi, /distro/fedora, /env/prod
Variant 11:    /hw/cpu/amd, /hw/disk/scsi, /distro/mint, /env/debug
Variant 12:    /hw/cpu/amd, /hw/disk/scsi, /distro/mint, /env/prod
Variant 13:    /hw/cpu/amd, /hw/disk/virtio, /distro/fedora, /env/debug
Variant 14:    /hw/cpu/amd, /hw/disk/virtio, /distro/fedora, /env/prod
Variant 15:    /hw/cpu/amd, /hw/disk/virtio, /distro/mint, /env/debug
Variant 16:    /hw/cpu/amd, /hw/disk/virtio, /distro/mint, /env/prod
Variant 17:    /hw/cpu/arm, /hw/disk/scsi, /distro/fedora, /env/debug
Variant 18:    /hw/cpu/arm, /hw/disk/scsi, /distro/fedora, /env/prod
Variant 19:    /hw/cpu/arm, /hw/disk/scsi, /distro/mint, /env/debug
Variant 20:    /hw/cpu/arm, /hw/disk/scsi, /distro/mint, /env/prod
Variant 21:    /hw/cpu/arm, /hw/disk/virtio, /distro/fedora, /env/debug
Variant 22:    /hw/cpu/arm, /hw/disk/virtio, /distro/fedora, /env/prod
Variant 23:    /hw/cpu/arm, /hw/disk/virtio, /distro/mint, /env/debug
Variant 24:    /hw/cpu/arm, /hw/disk/virtio, /distro/mint, /env/prod
The tree representation also changed to print the !mux points of 
branching, to further help the user to understand the structure of the 
tree::

$ scripts/avocado multiplex --tree examples/mux-environment.yaml
Config file tree structure:

        /-intel
       |
     /cpu-<>--amd
    |      |
  /hw       \-arm
 |  |
 |  |        /-scsi
 |   \disk-<>
 |           \-virtio
-|
 |          /-fedora
 |-distro-<>
 |          \-mint
 |
 |       /-debug
  \env-<>
     \-prod
The more detailed breakdown of the 145 commits can be seen here:

0.23.0...0.24.0

Happy testing!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20150519/bc6da63e/attachment.htm>