Prepare Plugins

Common Keys

The following keys are accepted by all plugins of the prepare step.

name:

The name of the step phase.

order:

Order in which the phase should be handled.

Default: 50

summary:

Concise summary describing purpose of the phase.

Default: not set

when: RULE

If specified, phase is run only if any rule matches plan context.

Default: not set

where: GUEST|ROLE

Run this phase on given guest or guests with the given role only.

Default: not set

feature

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

Enable or disable common features like repositories on the guest.

Note

The plugin requires a working Ansible to be available on the test runner.

Warning

The plugin may be a subject of various limitations, imposed by the fact it uses Ansible to implement some of the features:

Ansible 2.17+ no longer supports Python 3.6 and older. Guests where Python 3.7+ is not available cannot be prepared with the feature plugin. This has been observed when Fedora Rawhide runner is used with CentOS 7 or CentOS Stream 8 guests. Possible workarounds: downgrade Ansible tmt uses, or install Python 3.7+ before using feature plugin from an alternative repository or local build.

Control enablement of various features on the guest:

prepare:
    how: feature
    epel: disabled
    crb: enabled
    fips: enabled
    ...

prepare --how feature --epel disabled --crb enabled --fips enabled ...

Note

Features available via this plugin are implemented and shipped as plugins too. The list of available features and configuration keys will depend on which plugins you have installed.

See also Common Keys accepted by the plugin.

profile

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

Prepare guest setup with a guest profile.

Note

Guest profiles are being developed, once there is an agreed upon text we could steal^Wborrow^Wreuse, we shall add it to this docstring.

Guest profiles represent a particular setup of guest environment as defined by a CI system or service. They are implemented as Ansible roles, and packaged as Ansible collections. The CI systems use profiles to set up guests before testing, and users may use the same profiles to establish the same environment locally when developing tests or reprodcing issues.

Apply a profile to the guest:

prepare:
    how: feature
    profile: testing_farm.fedora_ci

prepare --how feature --profile testing_farm.fedora_ci

profile: NAME

Apply guest profile.

Default: not set

epel

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

Control Extra Packages for Enterprise Linux (EPEL) repository.

EPEL is an initiative within the Fedora Project to provide high quality additional packages for CentOS Stream and Red Hat Enterprise Linux (RHEL).

Enable or disable EPEL repository on the guest:

prepare:
    how: feature
    epel: enabled

prepare --how feature --epel enabled

epel: enabled|disabled

Whether EPEL repository should be installed & enabled or disabled.

Default: not set

fips

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

fips: enabled

Whether FIPS mode should be enabled

Default: not set

install

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

Install packages on the guest.

Example config:

prepare:
    how: install
    copr: psss/tmt
    package: tmt-all
    missing: fail

Use copr for enabling desired Copr repository and missing to choose whether missing packages should be silently ignored (skip) or a preparation error should be reported (fail), which is the default.

In addition to package name you can also use one or more paths to local rpm files to be installed:

prepare:
    how: install
    package:
        - tmp/RPMS/noarch/tmt-0.15-1.fc31.noarch.rpm
        - tmp/RPMS/noarch/python3-tmt-0.15-1.fc31.noarch.rpm

Use directory to install all packages from given folder and exclude to skip selected packages:

prepare:
    how: install
    directory: tmp/RPMS/noarch
    exclude: tmt+provision-virtual

Note

When testing ostree booted deployments tmt will use rpm-ostree as the package manager to perform the installation of requested packages. The current limitations of the rpm-ostree implementation are:

Cannot install new version of already installed local rpm.
No support for installing debuginfo packages at this time.

Configuration

See also Common Keys accepted by the plugin.

copr: REPO

Copr repository to be enabled.

Default: not set

directory: PATH

Path to a local directory with rpm packages.

Default: not set

exclude: PACKAGE

Packages to be skipped during installation.

Default: not set

missing: ACTION

Action on missing packages, fail (default) or skip.

Default: fail

package: PACKAGE

Package name or path to rpm to be installed.

Default: not set

ansible

Run Ansible playbooks against the guest, by running ansible-playbook for all given playbooks.

Note

The plugin requires a working Ansible to be available on the test runner.

Warning

When specifying playbooks with paths:

If a metadata tree root exists, all paths must be relative to the metadata tree root.
If the metadata tree root does not exist, all paths must be relative to the current working directory.

Warning

The plugin may be a subject of various limitations, imposed by Ansible itself:

Ansible 2.17+ no longer supports Python 3.6 and older. Guests where Python 3.7+ is not available cannot be prepared with the ansible plugin. This has been observed when Fedora Rawhide runner is used with CentOS 7 or CentOS Stream 8 guests. Possible workarounds: downgrade Ansible tmt uses, or install Python 3.7+ before using ansible plugin from an alternative repository or local build.

Run a single playbook on the guest:

prepare:
    how: ansible
    playbook: ansible/packages.yml

prepare --how ansible --playbook ansible/packages.yml

Run multiple playbooks in one phase, with extra arguments for ansible-playbook:

prepare:
    how: ansible
    playbook:
      - one.yml
      - two.yml
    extra-args: '-vvv'

prepare --how ansible --playbook one.yml --playbook two.yml --extra-args '-vvv'

Remote playbooks - provided as URLs starting with http:// or https://, local playbooks - optionally starting with a file:// schema, and playbooks bundled with collections can be referenced as well as local ones, and all kinds can be intermixed:

prepare:
    how: ansible
    playbook:
      - https://foo.bar/one.yml
      - two.yml
      - file://three.yml
      - ansible_galaxy_namespace.cool_collection.four

prepare --how ansible --playbook https://foo.bar/two.yml \
                      --playbook two.yml \
                      --playbook file://three.yml \
                      --playbook ansible_galaxy_namespace.cool_collection.four

Configuration

See also Common Keys accepted by the plugin.

extra-args: ANSIBLE-PLAYBOOK-OPTIONS

Additional CLI options for ansible-playbook.

Default: not set

playbook: PATH|URL

Path or URL of an ansible playbook to run. The playbook path must be relative to the metadata tree root.

Default: not set

shell

Warning

Please, be aware that the documentation below is a work in progress. We are working on fixing it, adding missing bits and generally making it better. Also, it was originally used for command line help only, therefore the formatting is often suboptimal.

Prepare guest using shell (Bash) scripts.

Run various commands and scripts on the guest:

prepare:
    how: shell
    script:
      - sudo dnf install -y 'dnf-command(copr)'
      - sudo dnf copr enable -y psss/tmt
      - sudo dnf install -y tmt

Configuration

See also Common Keys accepted by the plugin.

script: SCRIPT

Shell script to be executed. Can be used multiple times.

Default: not set