avocado-framework / autils

Utility Libraries to power your tests (or general applications)

autils

Utility Libraries to power your tests (or general applications)

autils's Issues

Contributor Guide

One of the quality aspects of the autils project has to do with how contributors (ranging from first time contributions to maintainers) will cooperate.

The definition of done for this issue is to provide a contributor guide that uses inspiration from both the BP005 and from the current Avocado and Avocado-VT contribution guides.

---

Part of #1

BP005 [epic]

This is an "epic" issue, intended to keep track of the implementation of BP005.

Site with module information (from metadata)

Every utility library that is part of the autils project should be accompanied by metadata that describes it.

Within this metadata, there will be a list of "standard platform names" such as:

• Red Hat Enterprise Linux version 9 - x86_64
• Fedora 36 - aarch64

Or icons that represent the same information. Architecture information is optional and should only be given when only a specific architecture is supported. Otherwise, it's assumed that all architectures of a given platform are supported.

The definition of done for this issue is to use the metadata to produce data that can be easily parsed and displayed in a website.

---

Part of #1

API stability testing

Is your feature request related to a problem? Please describe.
We need to ensure that autils API is stable over different versions. Since the autils will be used through different projects, we must avoid changes to the API of utilities until it is really necessary. This proposal is about possibilities how to ensure that.

Describe the solution you'd like
A clear and concise description of what you want to happen.
Add PR and release testing which will run the patch or new version against the tests from master of older version to ensure there is no regression in the API.

Additional information
Add any additional information or screenshots about the feature request here.

If the API change is necessary we need to come up with suitable deprecating process for everybody to have time to adapt to such change.

Release Bot - release

The release of autils will be based on a number of criteria such as a threshold of changes and the approval by maintainers.

The definition of done for this issue is to have a bot that will take those criteria into account and perform a release, including bumping the version, tagging the new version and releasing packages.

This is a continuing work after #7, which bring the automated release voting process. This issue is about automatization of release itself in the same way how it is done in avocado.

---

Part of #1

Automated Checks: scripts and CI jobs

One of the quality aspects of the autils project has to do with automated checks that will be enforced on every single submission.

The definition of done for this issue is to provide a set of commands (be custom scripts or make targets) that cover at the very least what is described in BP005 and from the current Avocado and Avocado-VT commands. Additionally, CI jobs should be created for all of those.

---

Part of #1

Test coverage

Is your feature request related to a problem? Please describe.
Let's enable test coverage with statistical tool like codecove.io

Metadata File Layout

Every utility library that is part of the autils project should be accompanied by metadata that describes it.

The definition of done for this issue is to provide a metadata format described with validation schema, that covers at the very least what is described in BP005.

---

Part of #1

Release Bot - voting

The release of autils will be based on a number of criteria such as a threshold of changes and the approval by maintainers.

The definition of done for this issue is to have a bot that will take those criteria into account and perform a release, including bumping the version, tagging the new version and releasing packages.

---

Part of #1

Trigger tests for libraries in all supported environments

Every utility library that is part of the autils project should be accompanied by metadata that describes it.

Within this metadata, there will be a list of "standard platform names" such as:

• Red Hat Enterprise Linux version 9 - x86_64
• Fedora 36 - aarch64

Architecture information is optional and should only be given when only a specific architecture is supported. Otherwise, it's assumed that all architectures of a given platform are supported.

The definition of done for this issue is to use the metadata to run tests on all supported platforms, and produce data that can be easily parsed and displayed in a website.

---

Part of #1

[Feature request] Please add cloudinit and vmimage support to the autils

For the functional tests in QEMU, it would be great to have the cloudinit and vmimage modules from avocado.utils in the autils, so the tests that are based on this code could be used independently of the avocado test runner, too:

• https://gitlab.com/qemu-project/qemu/-/blob/v9.1.0/tests/avocado/avocado_qemu/linuxtest.py
• https://gitlab.com/qemu-project/qemu/-/blob/v9.1.0/tests/avocado/replay_linux.py

So please add the cloudinit and vmimage module to the autils (this likely also includes the iso9660 module from avocado.utils since the couldinit code is using it internally). Thanks!