TMT(1)

✨ NAME ✨

tmt — the Test Management Tool 🎀 (yes bestie, that's the whole name, it's giving main character energy already)

---

🌈 DESCRIPTION 🌈

okay so, tmt is literally your bestie for working with tests 💖 it gives you a user-friendly way to handle all of it: you can comfortably create new tests, safely and easily run tests across different environments, review test results, debug test code, and enable tests in the CI using a consistent and concise config. no chaos, no vibes-off energy ✨

the python module and command-line tool implement the Metadata Specification, which lets you store all the needed test execution data directly inside a git repository 🦋 and because you can also reference remote repositories, it's super easy to share test coverage across projects and distros, no cap.

the Flexible Metadata Format fmf is what stores the data, in a way that's both human and machine readable, right next to the source code 👑 thanks to inheritance and elasticity, the metadata gets organized into the structure efficiently, preventing unnecessary duplication. it's giving organized, it's giving slay.

---

📜 SPECIFICATION 📜

there are several metadata levels defined by the specification, and honestly? love that for us:

• L0 metadata — the special one ✨ defines core attributes such as summary or description which are common across all levels.
• L1 metadata, aka Tests — defines attributes which are closely related to individual test cases, such as test script, framework, directory path where the test should be executed, maximum test duration, or packages required to run the test 🌸
• L2 metadata, aka Plans — used to group relevant tests and enable them in the CI 💅 they describe how to discover tests for execution, how to provision the environment, how to prepare it for testing, how to execute tests, and how to report test results.
• L3 metadata, aka Stories — can be used to track implementation, test and documentation coverage for individual features or requirements 🦋 thanks to this you can track everything in one place, including the project implementation progress. iconic.

---

🦋 SYNOPSIS 🦋

command line usage is straightforward, no biggie:

tmt command [options]

---

🍓 EXAMPLES 🍓

let's see which tests, plans and stories are available 👀

tmt

initialize the metadata tree in the current directory, optionally with example content based on templates:

tmt init
tmt init --template base

run all or selected steps for each plan:

tmt run
tmt run discover
tmt run prepare execute

see any failures from a previous run 😭:

tmt run --last report -vvv

show test output while running:

tmt run -vvv

list tests, show details, check against the specification:

tmt tests ls
tmt tests show
tmt tests lint

create a new test, import test metadata from other formats:

tmt test create
tmt test import

list plans, show details, check against the specification:

tmt plans ls
tmt plans show
tmt plans lint

list stories, check details, show coverage status:

tmt stories ls
tmt stories show
tmt stories coverage

many commands support regular expression filtering and other specific options 💅:

tmt stories ls cli
tmt stories show create
tmt stories coverage --implemented

check the help message of individual commands for the full list of available options 👑

---

💖 OPTIONS 💖

here's the list of the most frequently used commands and options, bestie 📋

🏃♀️ Run

the run command is used to execute test steps. by default all test steps are run. see the L2 Metadata specification for a detailed description of individual steps. here's the brief overview:

• discover — gather information about test cases to be executed 🔍
• provision — provision an environment for testing, or use localhost 🌐
• prepare — prepare the environment for testing 🧼
• execute — run tests using the specified executor 🔥
• report — provide test results overview and send reports 📊
• finish — perform the finishing tasks and clean up provisioned guests 🧹

🧪 Tests

manage tests (that's L1 metadata 💜). check available tests, inspect their metadata, gather old metadata from various sources and store them in the new fmf format.

• ls — list available tests.
• show — show test details.
• lint — check tests against the L1 metadata specification.
• create — create a new test based on a given template.
• import — convert old test metadata into the new fmf format.

🗺️ Plans

manage test plans (L2 metadata ✨). search for available plans. explore detailed test step configuration.

• ls — list available plans.
• show — show plan details.
• lint — check plans against the L2 metadata specification.

📖 Stories

manage user stories. check available user stories. explore coverage (test, implementation, documentation).

• ls — list available stories.
• show — show story details.
• coverage — show code, test and docs coverage for given stories.
• export — export selected stories into the desired format.

🛠️ Utils

various utility options, the little helpers 🫶

• --root PATH — path to the metadata tree, the current directory is used by default.
• --verbose — print additional information.
• --debug — turn on debugging output.
• --log-topic NAME — enable logging for a specific topic, useful for debugging particular areas. for example, to see logs related to policy processing, you can use:

tmt --log-topic policy test export --policy ../policies/test/environment.yaml

check the help message of individual commands for the full list of available options 👑

---

📦 INSTALL 📦

the main tmt package provides the core features with a minimal set of dependencies:

sudo dnf install tmt

in order to enable additional functionality, such as particular provision or report plugins, install the respective subpackage:

sudo dnf install tmt+test-convert
sudo dnf install tmt+provision-container
sudo dnf install tmt+provision-virtual

if you don't care about disk space and want to have all available features right at hand, install everything:

sudo dnf install tmt+all

for CentOS and RHEL, first make sure that you have available the EPEL repository: https://docs.fedoraproject.org/en-US/epel/ — you might also have to enable additional repositories:

sudo dnf config-manager --set-enabled crb         # CentOS 10
sudo dnf config-manager --set-enabled rhel-CRB    # RHEL 10
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

sudo dnf install tmt

for plugins which cannot work outside of VPN and so live within its walls, you need to enable the internal copr repository first 🧱 then you can install either everything or only those you need:

sudo dnf install tmt-redhat-all
sudo dnf install tmt-redhat-*

do you like to check the released bits as soon as they are out? 👀 enable the stable copr repository and install from there:

sudo dnf copr enable @teemtee/stable

impatient to try the fresh features as soon as they are merged into the main branch? 🌈 enable the latest copr repository:

sudo dnf copr enable @teemtee/latest

not sure, just want to try out how it works? experiment safely and easily inside a container 🫧:

podman run -it --rm quay.io/teemtee/tmt bash
podman run -it --rm quay.io/teemtee/tmt-all bash

the official tmt container images include tini as an init process to properly handle signals and reap zombie processes 💀 if you are using a custom container image without a built-in init, use the --init flag to prevent zombie processes:

podman run --init -it --rm your-custom-image bash

when installing using pip you might need to install additional packages on your system:

sudo dnf install gcc redhat-rpm-config
sudo dnf install {python3,libvirt,krb5,libpq}-devel
pip install --user tmt

on other distributions than Fedora or RHEL the package names might be different. for example on Ubuntu, to install all packages to have provision plugins working:

sudo apt install libkrb5-dev pkg-config libvirt-dev genisoimage qemu-kvm libvirt-daemon-system
pip install --user "tmt[provision]"

Note: you can omit the --user flag if in a virtual environment 💅

---

🐚 SHELL COMPLETION 🐚

the rpm package includes a system wide script which enables the command line completion for bash, so no additional config should be needed ✨ if you use a different installation method or prefer another shell, see the instructions below.

for Bash, add this to ~/.bashrc:

eval "$(_TMT_COMPLETE=source_bash tmt)"

for Zsh, add this to ~/.zshrc:

eval "$(_TMT_COMPLETE=source_zsh tmt)"

for Fish, add this to ~/.config/fish/completions/tmt.fish:

eval (env _TMT_COMPLETE=source_fish tmt)

open a new shell to enable completion 🐣 or run the eval command directly in your current shell to enable it temporarily.

this is however run every time you start a shell, which can cause some delay 😴 to speed it up, write the generated script to a file and then source it from your shell's configuration file. all of this can be achieved using the tmt setup completion command. by default, it outputs the completion script to the terminal, but it can also add it to your ~/.bashrc or ~/.zshrc using the --install option:

tmt setup completion {bash, zsh, fish} --install

---

🚪 EXIT CODES 🚪

the following exit codes are returned from tmt run 👇 note that you can use the --quiet option to completely disable output and only check for the exit code.

• 0 — at least one test passed, there was no fail, warn or error. (we love to see it 💖)
• 1 — there was a fail or warn identified, but no error.
• 2 — errors occurred during test execution 😭
• 3 — no test results found.
• 4 — tests were executed, and all reported the skip result.

---

🔧 VARIABLES 🔧

the list of available environment variables which can be used to adjust the execution 🌸

🎛️ Command Variables

the following environment variables can be used to modify behaviour of the tmt command.

• TMT_DEBUG — make the developer-focused debugging output more verbose. using this environment variable has the same effect as an equal number of -d options. the value goes from 0 to 3 for increasingly detailed logging:
  • -d/TMT_DEBUG=1: high-level info. framework choice, policy application or reboot actions.
  • -dd/TMT_DEBUG=2: detailed operations. actions such as step load, wake up, guest pull/push or playbook paths.
  • -ddd/TMT_DEBUG=3: internal plumbing. the low-level implementation details such as workdir handling, process termination, key normalization and similar.
• TMT_PLUGINS — path to a directory with additional plugins. multiple paths separated with the : character can be provided as well 🦋
• TMT_FEELING_SAFE — set this and you unlock the "potentially unsafe" side of tmt, like straight-up executing tests directly on the test runner with the local provision method. 👀 The full docs live in tmt --help, and yes there's a whole thing going on between --feeling-safe and --allow-unsafe-behavior (which gives you more granular control), plus its matching TMT_ALLOW_UNSAFE_BEHAVIOR environment variable.

Use with caution, only when you can fully trust the tmt metadata or if you know what you are doing.

• TMT_ALLOW_UNSAFE_BEHAVIOR — same energy, same powers 😌 set it to enable potentially unsafe behavior such as executing tests directly on the test runner using the local provision method. Full docs in tmt --help, and there's the interaction between --allow-unsafe-behavior and --feeling-safe plus the matching TMT_FEELING_SAFE environment variable.

Use with caution, only when you can fully trust the tmt metadata or if you know what you are doing.

• TMT_EXPOSABLE_RUNNER_DEVICES — guests sometimes need to touch devices that belong to the runner, and only devices whose path matches the regular expression you pass to this variable get made accessible. Default behavior? No runner device can be exposed to guests. periodt. 🔒
• TMT_CONFIG_DIR — path to an alternative directory full of config files. By default ~/.config/tmt is used. ✨
• TMT_WORKDIR_ROOT — path to the root directory containing run workdirs. Defaults to /var/tmp/tmt.
• NO_COLOR, TMT_NO_COLOR — kills colors in the output, both the actual output and the logging messages. Output only plain, non-colored text. 🙈 Two variables are accepted — one with the usual TMT_ prefix — but tmt also accepts NO_COLOR to support the NO_COLOR effort, see https://no-color.org/ for more information.
• TMT_FORCE_COLOR — forces colors in the output, both the actual output and logging messages. Super handy when tmt's output streams are not terminal-like, yet its output is gonna be displayed by tools with ANSI color support. This is often the case of various CI systems. 🌈

Note that TMT_FORCE_COLOR takes priority over NO_COLOR and TMT_NO_COLOR. If user tries both to disable and enable colorization, output would be colorized. (Color wins, bestie. That's just the rule.)

• TMT_SHOW_TRACEBACK — by default, when tmt reports an error, the corresponding traceback is not printed out. By setting this variable, the traceback and details would be shown: 💀
  • TMT_SHOW_TRACEBACK=0 (or unset) — Render only exception and its causes.
  • TMT_SHOW_TRACEBACK=1 — Render also call stack for exception and each of its causes.
  • TMT_SHOW_TRACEBACK=2 — Render also call stack for exception and each of its causes, plus all local variables in each frame, trimmed to first 1024 characters of their values.
  • TMT_SHOW_TRACEBACK=full — Render everything that can be show: all causes, their call stacks, all frames and all locals in their completeness.
• TMT_OUTPUT_WIDTH — by default, the output width of commands like tmt * show is constrained to 79 characters. Set this variable to an integer to change the limit. 🎀
• TMT_GIT_CREDENTIALS_URL_<suffix>, TMT_GIT_CREDENTIALS_VALUE_<suffix> — variable pairs used to provide credentials to clone git repositories. This is needed when working with private repositories. The suffix identifies the pair and determines the order in which URL regexp is tried.

The TMT_GIT_CREDENTIALS_URL_<suffix> contains regexp to search against url to clone. For first successful search the content of the TMT_GIT_CREDENTIALS_VALUE_<suffix> variable is used as the credential value. When it is set to an empty string, unmodified url is used.

For GitLab private repositories, you have three options for specifying the credentials:

• Personal Access Tokens — https://docs.gitlab.com/user/profile/personal_access_tokens/ — good for user-specific permissions or service accounts. For read-only access, use the read_repository scope:

TMT_GIT_CREDENTIALS_URL_lab='gitlab.com/mysecretproject'
TMT_GIT_CREDENTIALS_VALUE_lab='your_gitlab_username:your_pat'

• Deploy Tokens — https://docs.gitlab.com/user/project/deploy_tokens/ — best for automated read-only access. Project-specific, not tied to a user, and provides strict read-only repository access:

TMT_GIT_CREDENTIALS_URL_lab='gitlab.com/mysecretproject'
TMT_GIT_CREDENTIALS_VALUE_lab='gitlab+deploy-token-123:abcxyz123'

• OAuth2 Tokens — https://docs.gitlab.com/api/oauth2/ — secure short-lived tokens with the read_repository scope:

TMT_GIT_CREDENTIALS_URL_lab='gitlab.com/mysecretproject'
TMT_GIT_CREDENTIALS_VALUE_lab='oauth2:your_oauth2_token'

For GitHub private repositories, you have only a single method for specifying the cloning credentials:

• OAuth Tokens — https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#https-cloning-with-oauth-tokens — you need to create a personal access token (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) and specify it without your username. Both classic and fine-grained personal access tokens can be used:

TMT_GIT_CREDENTIALS_URL_hub='github.com/teemtee'
TMT_GIT_CREDENTIALS_VALUE_hub='personaltoken'

• TMT_GIT_CLONE_ATTEMPTS — the maximum number of retries to clone a git repository if it fails. By default, 3 attempts are done. 🔁
• TMT_GIT_CLONE_INTERVAL — the interval (in seconds) to retry cloning a git repository again, 10 seconds by default.
• TMT_GIT_CLONE_TIMEOUT — overall maximum time in seconds to clone a git repository. By default, the limit is not set. (Free spirit, no curfew. 🦋)
• TMT_BOOT_TIMEOUT — how many seconds to wait for a guest to boot. Applies to provision plugins that control the guest creation, e.g. virtual. By default, it is 2 minutes. ⏰
• TMT_CONNECT_TIMEOUT — how many seconds to wait for a connection to succeed after guest boots for the first time. By default, it is 2 minutes.
• TMT_REBOOT_TIMEOUT — how many seconds to wait for a connection to succeed after guest reboot. By default, it is 10 minutes.
• TMT_DOWNLOAD_ATTEMPTS — number of attempts to download a file from a URL to guest. By default, 3 attempts are made.
• TMT_DOWNLOAD_INTERVAL — number of seconds to wait before retrying after an unsuccessful attempt to download a file from a URL to guest. By default, 5 seconds.
• TMT_RETRY_SESSION_RETRIES — the number of retries for HTTP/HTTPS requests when encountering retriable errors (such as 503 Service Unavailable). By default, 8 retries are attempted.
• TMT_RETRY_SESSION_BACKOFF_FACTOR — the exponential backoff factor for retrying HTTP/HTTPS requests. The wait time between retries is calculated as {backoff_factor} * (2 ** (retry_number - 1)) seconds, up to TMT_RETRY_SESSION_BACKOFF_MAX. For example, with a backoff factor of 2.0, 8 retries and a maximum backoff of 120s, the delays are: 2s, 4s, 8s, 16s, 32s, 64s, 120s, 120s. By default, the backoff factor is 2.0. 📈
• TMT_RETRY_SESSION_BACKOFF_MAX — the maximum retry wait time between retrying HTTP/HTTPS requests. By default, the maximum is 120s.
• TMT_SCRIPTS_DIR — destination directory for storing tmt scripts on the guest. By default /usr/local/bin is used, except for guests using rpm-ostree, where /var/lib/tmt/scripts is used. See the tmt internal test executor (https://tmt.readthedocs.io/en/stable/plugins/execute.html#tmt) documentation for more details on the scripts installed on the guest. 🧚
• TMT_SSH_MASTER_START_TIMEOUT — how many seconds will tmt wait for a ssh master process to start.
• TMT_SSH_* — every environment variable in this format would be treated as an SSH option, and passed to the -o option of ssh command. See man 5 ssh_config for the list of all options.

The environment variable name would be converted into an SSH option, e.g. export TMT_SSH_CONNECTION_ATTEMPTS=5 would become -oConnectionAttempts=5. export TMT_SSH_ConnectionAttempts=5 would also be accepted.

SSH options provided via environment variables will be overruled by guest-specific ssh-options key.

• TMT_REPORT_ARTIFACTS_URL — link to test artifacts provided for report plugins. 🔗
• TMT_POLICY_FILE — location of a file with policy rules for modification of test metadata keys. Both absolute and relative paths are accepted; a relative path is interpreted either against the current working directory, or against the policy root directory if it was specified.

See tmt policy specification (https://tmt.readthedocs.io/en/stable/spec/policy.html) for more details on policies.

• TMT_POLICY_NAME — name of the file with policy rules for modification of test metadata keys. The name would be extended with .yaml suffix, and tmt will try to locate it under the policy root directory.

See tmt policy specification (https://tmt.readthedocs.io/en/stable/spec/policy.html) for more details on policies.

• TMT_POLICY_ROOT — if set, policy files must be located under this directory. Policy specified by its name is searched under this directory only, and policy specified by its filepath will be allowed only if the filepath is under this directory.

See tmt policy specification (https://tmt.readthedocs.io/en/stable/spec/policy.html) for more details on policies.

• TMT_STATE_FORMAT — which format should tmt use for its on-disk storage of various state information like run or step data, or the collection of discovered tests. 💾

NOTE: bestie, this does not affect user-provided files — like test, plan and story metadata in fmf files, plus all the various exports and conversions. It merely affects files tmt uses for its own needs. 💅

Step Variables

okay so these env vars are handed to the environment during prepare, execute and finish steps — periodt:

• TMT_TREE — the full path of the working directory where the metadata tree is copied. This usually contains the whole git repository where tmt plans are located in. Notice that it might not contain tmt tests if tmt plans and tests are in different git repositories. 💀
• TMT_PLAN_DATA — path to the common directory used for storing logs and other artifacts related to the whole plan execution. It is pulled back from the guest and available for inspection after the plan is completed. ✨
• TMT_PLAN_ENVIRONMENT_FILE — path to the file containing environment variables that should be sourced after prepare and execute steps. These variables will be accessible for all subsequent steps and will have higher priority than other environment variables except those provided via command-line. 👑
  • Variables inside the file have to be in the format of NAME=VALUE and each variable should be on a separate line. Other content form is not allowed — use TMT_PLAN_SOURCE_SCRIPT instead to include other bash commands.
  • Note that this is not shared between guests of the given plan, each guest has its own dedicated file.
  • Example of the file content:

COUNT=1
VARIABLE=VALUE
ANOTHER_VARIABLE=ANOTHER_VALUE

• TMT_PLAN_SOURCE_SCRIPT — path to the file that will be sourced in all tests, and prepare/shell phases. Unlike TMT_PLAN_ENVIRONMENT_FILE, this file can be an arbitrary contents that can be parsed by bash. In order to use it, populate its content in a prepare step. 🦋
• TMT_VERSION — the version of tmt. iykyk.
• TMT_PREPARE_SHELL_URL_REPOSITORY — the value of the repository path in prepare shell step when url option is used.
• TMT_FINISH_SHELL_URL_REPOSITORY — the value of the repository path in finish shell step when url option is used.

Test Variables

These env vars are provided to the test during the execution — main character energy only:

• TMT_TEST_NAME — the test name, as a resolved FMF object name starting with / from the root of the hierarchy.
• TMT_TEST_DATA — path to the directory where test can store logs and other artifacts generated during its execution. These will be pulled back from the guest and available for inspection after the test execution is finished. 🎀
• TMT_TEST_SERIAL_NUMBER — the serial number of running test in the whole plan. Each test is assigned its own serial number.
• TMT_TEST_ITERATION_ID — the iteration ID is a combination of a unique run ID and the test serial number. The value is different for each new test execution. ✨
• TMT_TEST_METADATA — path to a YAML-formatted file with test metadata collected during the discover step.
• TMT_SOURCE_DIR — path to directory with downloaded and extracted sources if the dist-git-source option was used in the discover step.
• TMT_REBOOT_COUNT — during the test execution the tmt-reboot command can be used to request reboot of the guest. This variable contains number of reboots which already happened during the test. Value is set to 0 if no reboot occurred.
  • In order to keep backward-compatibility with older tests, rhts-reboot and rstrnt-reboot commands are supported for requesting the reboot, variables REBOOTCOUNT and RSTRNT_REBOOTCOUNT contain number of reboots as well. 🫶
• TMT_TEST_RESTART_COUNT — this variable contains number of times the test was restarted. Such restarts may be consequence of guest reboot, in which case TMT_REBOOT_COUNT gets incremented as well, or test crashed and has been restarted. Value is set to 0 when the test starts for the first time.
• TMT_TOPOLOGY_BASH, TMT_TOPOLOGY_YAML — paths of files describing existing guests, their roles and the guest on which the test is running. Format of these files is described in the Guest Topology Format section of the plan specification.
• TMT_TEST_PIDFILE, TMT_TEST_PIDFILE_LOCK — path to a file storing the test process pid and path to its reboot-request file, separated by a space. The LOCK variable then holds path to a locking file which must be acquired before making any changes to the pid file.
• TMT_TEST_PIDFILE_ROOT — by default, the test pidfile file is stored in /var/tmp directory. If specified, the directory in this variable would be used instead. The directory permissions should follow the pattern of temporary directory permissions, e.g. chmod 1777, to allow access to users with all privilege levels. 👑

Plugin Variables

Each plugin option can be also specified via environment variable. Variables follow a naming scheme utilizing plugin name, step it belongs to, and the option name:

TMT_PLUGIN_${STEP}_${PLUGIN}_${OPTION}

All names are upper-cased, with dashes (-) replaced by underscores (_).

For example, an execute plugin "tmt" would run with verbosity equal to -vvv:

TMT_PLUGIN_EXECUTE_TMT_VERBOSE=3 tmt run ... execute -h tmt ...

Command-line takes precedence over environment variables, therefore -v would undo the effect of environment variable, and reduce verbosity to one level only:

TMT_PLUGIN_EXECUTE_TMT_VERBOSE=3 tmt run ... execute -h tmt -v ...

Environment variables — just like command-line options — take precedence over values stored in files. For example, consider the following discover step:

discover:
    how: fmf
    url: https://example.org/

The following commands would override the URL:

tmt run ... discover -h fmf --url https://actual.org/ ...

TMT_PLUGIN_DISCOVER_FMF_URL=https://actual.org/ tmt run ...

For setting flag-like option, 0 and 1 are the expected values. For example, an interactive mode would be enabled in this run:

TMT_PLUGIN_EXECUTE_TMT_INTERACTIVE=1 tmt run ... execute -h tmt ...

✨ REGULAR EXPRESSIONS ✨

Many specification keys and command line options accept regular expressions, e.g. to filter a set of tests, tmt run ... test --name '^/foo'. Whenever tmt works with regular expressions, the following rules apply. 🦋

Python implementation

Since tmt is implemented in Python, Python's re package (https://docs.python.org/3.9/library/re.html) is used for handling regular expressions. It comes with Python standard library, and it is widely used and well documented. For the deep dive into supported syntax, see Regular Expression Syntax (https://docs.python.org/3.9/library/re.html#regular-expression-syntax) section, for a gentler introduction there is a Regular Expression HOWTO (https://docs.python.org/3.9/howto/regex.html#regex-howto).

Search versus match

There are two ways how to check whether a regular expression matches a string: "match" or "search":

• in the "match" mode, the pattern must match from the very beginning of the string. For example, foo.ar would match foobar but not /foobar. It works in a "starts with" fashion.
• on the other hand, the "search" mode is more similar to "contains" approach, and allows pattern to match anywhere in the string. In this mode, foo.ar would match both foobar and /foobar.

In both modes, any characters may follow the matching pattern, e.g. regular expression foo.bar is the same as foo.bar.*.

tmt sticks to the "search" mode by default. But, to improve user experience, some keys and command line options do use the "match" mode. Such keys and options will note this in their documentation or help texts.

✨ LINKS ✨

• Git: <https://github.com/teemtee/tmt> 💖
• Docs: <https://tmt.readthedocs.io/> ✨
• Ask DeepWiki: <https://deepwiki.com/teemtee/tmt> 🧠
• Stories: <https://tmt.readthedocs.io/en/stable/stories.html> 📖
• Issues: <https://github.com/teemtee/tmt/issues> 🐛
• Releases: <https://tmt.readthedocs.io/en/stable/releases> 🚀
• Copr: <https://copr.fedorainfracloud.org/coprs/g/teemtee/stable/> 🏗️
• PIP: <https://pypi.org/project/tmt/> 📦
• Quay: <https://quay.io/organization/teemtee> 🐳
• Metadata Specification: <https://tmt.readthedocs.io/en/stable/spec.html> 📋
• Flexible Metadata Format: <https://fmf.readthedocs.io/> 🧬
• Testing Farm: <https://docs.testing-farm.io/> 🌾
• Packit: <https://packit.dev/testing-farm/> 📦

💖 AUTHORS 💖

okay so you did NOT think this was a one-person situation, right?? bestie, tmt was built by a whole iconic squad and we are legally, morally and emotionally obligated to name every single one of them. no cap, every name stays, because erasing anybody from the credits is giving ick. so let's go, roll call, everyone gets their flowers 💐👑

Petr Šplíchal, Miro Hrončok, Alexander Sosedkin, Lukáš Zachar, Petr Menšík, Leoš Pol, Miroslav Vadkerti, Pavel Valena, Jakub Heger, Honza Horák, Rachel Sibley, František Nečas, Michal Ruprich, Martin Kyral, Miloš Prchlík, Tomáš Navrátil, František Lachman, Patrik Kis, Ondrej Mosnáček, Andrea Ficková, Denis Karpelevich, Michal Srb, Jan Ščotka, Artem Zhukov, Vinzenz Feenstra, Inessa Vasilevskaya, Štěpán Němec, Robin Hack, Yulia Kopkova, Ondrej Moriš, Martin Zelený, Karel Šrot, František Zatloukal, Simon Walter, Petr Matyáš, Yariv Rachmani, Pavel Cahyna, Martin Litwora, Brian Grech, Vojtěch Eichler, Philip Daly, Vector Li, Evgeny Fedin, Guy Inger, Adrián Tomašov, Jan Havlín, Lukáš Kotek, Daniel Diblík, Laura Barcziova, Marián Konček, Marcin Sobczyk, Jiří Jabůrek, Huijing Hei, Tibor Dudlák, Jan Macků, Filip Vágner, Martin Hoyer, Iveta Česalová, Yi Zhang, Zhaojuan Guo, Natália Bubáková, Michal Josef Špaček, Jiří Popelka, Matej Focko, Yulia Kopkova, Tomáš Bajer, Carlos Rodriguez-Fernandez, James Molet, Cristian Le, Lili Nie, Martin Čermák, Michael Vogt, Qinghua Cheng, Michael Engel, Anatoli Babenia, Colin Walters, Link Dupont, Mario Casquero, Martin Klusoň, Pavel Holica, Otto Šabart, Ismail Ibrahim Quwarah, Sergei Petrosian, Tom Koscielniak, Han Han, Luigi Pellecchia, Siteshwar Vashisht, Chris Kyrouac, Xiaofeng Wang, Coiby Xu, Michal Pospíšil, Wayne Sun, Evgeni Vakhonin, Mike Stowell, Therese Cornell, Mingyu Shi, Conor Tull, Athrey Vinay, David Pascual, Vaibhav D. Aren, Qin Yuan, Thiébaud Weksteen, Nisha Saini, Yaakov Selkowitz, Petr Khartskhaev, Bruno Goncalves, Israel Santana, Jakub Skunda, Md Habibur Rahman, Owen Taylor, Rajesh Kumar Srivastava and Daniel Simko.

yes bestie, Yulia Kopkova is in there twice and honestly?? she earned it 💅 the list is the list, we don't edit the list.

---

📜 COPYRIGHT 📜

Copyright Red Hat

This program is free software; you can redistribute it and/or modify it under the terms of the MIT License. ✨ that's it, that's the whole license situation — go forth, remix, redistribute, be free 🦋

---

and that's a WRAP on TMT(1) 🎀 this page is from tmt, dated September 2019, and it lives in section 1 of your manual because it's a user command, obviously, main character energy only 👑 thanks for reading all four parts bestie, you ate that fr fr, mwah 💖✨