Releases
tmt-1.32.2
Set priorities for package manager discovery. They are now probed
in order: rpm-ostree
, dnf5
, dnf
, yum
, apk
, apt
.
This order picks the right package manager in the case when the
guest is ostree-booted
but has the dnf installed.
tmt-1.32
The hardware specification for disk has been
extended with the new keys driver
and model-name
. Users
can provision Beaker guests with a given disk model or driver using
the beaker provision plugin.
The virtual provision plugin gains support
for TPM hardware requirement. It is limited
to TPM 2.0 for now, the future release of testcloud, the
library behing virtual
plugin, will extend the support to more
versions.
A new watchdog test check has been added. It monitors a guest running the test with either ping or SSH connections, and may force reboot of the guest when it becomes unresponsive. This is the first step towards helping tests handle kernel panics and similar situations.
Internal implementation of basic package manager actions has been
refactored. tmt now supports package implementations to be shipped as
plugins, therefore allowing for tmt to work natively with distributions
beyond the ecosystem of rpm-based distributions. As a preview, apt
,
the package manager used by Debian and Ubuntu, rpm-ostree
, the
package manager used by rpm-ostree
-based Linux systems and apk
,
the package manager of Alpine Linux have been included in this release.
New environment variable TMT_TEST_ITERATION_ID
has been added to
Test Variables. This variable is a combination of a unique
run ID and the test serial number. The value is different for each
new test execution.
New environment variable TMT_REPORT_ARTIFACTS_URL
has been added
to Command Variables. It can be used to provide a link for
detailed test artifacts for report plugins to pick.
Beaker provision plugin gains support for System z cryptographic adapter HW requirement.
The dist-git-source apply patches now using
rpmbuild -bp
command. This is done on provisioned guest during
the prepare
step, before required packages are installed.
It is possible to install build requires automatically with
dist-git-install-builddeps
flag or specify additional
packages required to be present with dist-git-require
option.
tmt-1.31
The provision step is now able to perform provisioning of multiple guests in parallel. This can considerably shorten the time needed for guest provisioning in multihost plans. However, whether the parallel provisioning would take place depends on what provision plugins were involved, because not all plugins are compatible with this feature yet. As of now, only artemis, connect, container, local, and virtual are supported. All other plugins would gracefully fall back to the pre-1.31 behavior, provisioning in sequence.
The prepare step now installs test requirements only on guests on which the said tests would run. Tests can be directed to subset of guests with a where key, but, until 1.31, tmt would install all requirements of a given test on all guests, even on those on which the said test would never run. This approach consumed resources needlessly and might be a issue for tests with conflicting requirements. Since 1.31, handling of require and recommend affects only guests the test would be scheduled on.
New option --again
can be used to execute an already completed
step once again without completely removing the step workdir which
is done when --force
is used.
New environment variable TMT_REBOOT_TIMEOUT
has been added to
Command Variables. It can be used to set a custom reboot
timeout. The default timeout was increased to 10 minutes.
New hardware specification key zcrypt has been defined. It will be used for selecting guests with the given System z cryptographic adapter.
A prepare step plugin feature has been
implemented. As the first supported feature, epel
repositories
can now be enabled using a concise configuration.
The report plugin report has received new options.
Namely option --launch-per-plan
for creating a new launch per each
plan, option --suite-per-plan
for mapping a suite per each plan,
all enclosed in one launch (launch uuid is stored in run of the first
plan), option --launch-description
for providing unified launch
description, intended mainly for suite-per-plan mapping, option
--upload-to-launch LAUNCH_ID
to append new plans to an existing
launch, option --upload-to-suite SUITE_ID
to append new tests
to an existing suite within launch, option --launch-rerun
for
reruns with ‘Retry’ item in RP, and option --defect-type
for
passing the defect type to failing tests, enables report idle tests
to be additionally updated. Environment variables were rewritten to
the uniform form TMT_PLUGIN_REPORT_REPORTPORTAL_${option}
.
tmt-1.30
The new tmt try command provides an interactive session which allows to easily run tests and experiment with the provisioned guest. The functionality might still change. This is the very first proof of concept included in the release as a tech preview to gather early feedback and finalize the outlined design. Give it a try and let us know what you think! :)
Now it’s possible to use Custom Templates when creating new tests, plans and stories. In this way you can substantially speed up the initial phase of the test creation by easily applying test metadata and test script skeletons taylored to your individual needs.
The contact key has been moved from the Tests specification to the Core attributes so now it can be used with plans and stories as well.
The container provision plugin enables a network accessible to all containers in the plan. So for faster Multihost Testing it’s now possible to use containers as well.
For the purpose of tmt exit code, info
test results are no
longer considered as failures, and therefore the exit code of tmt
changes. info
results are now treated as pass
results, and
would be counted towards the succesful exit code, 0
, instead
of the exit code 2
in older releases.
The polarion report now supports the
fips
field to store information about whether the FIPS mode
was enabled or disabled on the guest during the test execution.
The name
field of the check specification
has been renamed to how
, to be more aligned with how plugins
are selected for step phases and export formats.
A new tty boolean attribute was added to the
Tests specification. Tests can now control if they
want to keep tty enabled. The default value of the attribute is
false
, in sync with the previous default behaviour.
See the full changelog for more details.
tmt-1.29
Test directories can be pruned with the prune
option usable in
the fmf plugin. When enabled, only
test’s path and required files will be kept.
The dist-git-source option
download-only
skips extraction of downloaded sources. All
source files are now downloaded regardless this option.
Environment variables can now be also stored into the
TMT_PLAN_ENVIRONMENT_FILE
. Variables defined in this file are
sourced immediately after the prepare
step, making them
accessible in the tests and across all subsequent steps. See
the Step Variables section for details.
When the tmt-report-result
command is used it sets the test
result exclusively. The framework is not consulted any more. This
means that the test script exit code does not have any effect on
the test result. See also Report test result.
The tmt-reboot
command is now usable outside of the test
process. See the Reboot during test section for usage
details.
The provision step methods gain the become
option which allows to use a user account and execute
prepare
, execute
and finish
steps using sudo -E
when necessary.
The html report plugin now shows check results so that it’s possible to inspect detected AVC denials directly from the report.
See the full changelog for more details.
tmt-1.28
The new update-missing option
can be used to update step phase fields only when not set in the
fmf
files. In this way it’s possible to easily fill the gaps
in the plans, for example provide the default distro image.
The html report plugin now shows
provided context and link to the test data
directory so that additional logs can be easily checked.
The avc check allows to detect avc denials which appear during the test execution.
A new skip
custom result outcome has been added to the
Results Format specification.
All context dimension values are now handled in a case insensitive way.
See the full changelog for more details.