Skip to content

0.24.0: A Beautiful Mind
Compare
Choose a tag to compare
@lmr lmr released this 19 May 14:15
· 8493 commits to master since this release
0.24.0
40fef32

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, while hw 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!

Assets 2
Loading