Test Environment
This page describes details about the test environment.
Supported Architectures
Epel
Before Testing Farm starts installing artifacts into the test environment, it adds the EPEL repositories to the system.
Epel repository is added only for CentOS Stream distributions tested via the 🌍 Public ranch.
For RHEL the repository is not added by default, as this is not considered a best practice when testing RHEL.
For enabling the repository for RHEL you can use:
-
a tmt prepare step running a shell command as described in EPEL quickstart guide
-
in case you are a Beakerlib user, you can use the BeakerLib epel library
Tag Repository
Before Testing Farm starts installing artifacts into the test environment, it adds the "tag repository" to the system.
This repository contains all builds tagged with -candidate (i.e. which passed gating) that are not yet present in the nightly repository.
It’s currently necessary as landing in nightly can take an indefinite amount of time due to the manual "pre-validation" and "attach to erratum" steps.
Adding this repository greatly reduces the number of artifact installation failures.
The tag repository is auto-generated by the build system - Koji or Brew. As a package maintainer you might know it under the name brew/koji buildroot repository.
The base URL of the repository is set up according to the test environment operating system.
Tag repository is added:
-
for RHEL, CentOS Stream and Fedora based distributions
-
when testing on VM or Bare Metal, i.e. for container testing the setup is skipped
-
the tag repository is enabled during test execution, see Disabling section if you would like to disable the repository during your testing
Public Ranch
Tag repository details:
-
repository name:
testing-farm-tag-repository -
priority:
9(higher than system repos)
Red Hat Ranch
In Red Hat ranch we are adding mainline and z-stream repositories by default, to mitigate complications choosing the correct one according to the provided artifacts.
This should work well, and make sure the dependencies of the packages are fulfilled as needed.
See TFT-3563 for details.
Tag repository details:
-
repositories:
-
testing-farm-tag-mainline-repositoryandtesting-farm-tag-z-stream-repository(enabled by default) -
testing-farm-tag-mainline-repository-i386andtesting-farm-tag-z-stream-repository-i386(disabled by default)
-
-
priority:
999(lower than system repos)
Disabling
If you would like to disable the tag repository during test execution add below adjust rule to your tmt plan.
This can be useful if the tag repository is causing issues for your testing.:W!
-
Fedora
adjust: - when: distro == fedora prepare+: - how: shell order: 20 script: dnf config-manager --set-disabled testing-farm-tag-repository because: Don't use Testing Farm tag repository. -
CentOS Stream
adjust: - when: distro == centos-stream prepare+: - how: shell order: 20 script: dnf config-manager --set-disabled testing-farm-tag-repository because: Don't use Testing Farm tag repository. -
RHEL
adjust: - when: distro == rhel prepare+: - how: shell order: 20 script: | dnf config-manager --set-disabled testing-farm-tag-repository-mainline dnf config-manager --set-disabled testing-farm-tag-repository-z-stream because: Don't use Testing Farm tag repository.
Composes
Testing farm supports a variety of composes, depending on the ranch being used. The lists of composes for every ranch are available below:
When Compose YUM repositories are removed upstream, the composes become almost useless.
If you would like to keep a compose for longer than the default time, you will need to request that it be tagged with by ENGCMP with do-not-remove.
You will also need to change the keep_until date in variables-composes-yaml.
Either request this from Testing Farm team or make a merge request.
Test Artifacts Repository
Certain test workflows may require making available a set of artifacts as dependencies for the tested artifact(s), however cannot be installed in full due to conflicting packages or other reasons.
To facilitate this, all artifacts regardless of their install flag are collected into a single local test-artifacts repository.
This repository is then available during the installation of all subsequent artifacts.
The test-artifacts repository remains available in the test environment and can be used to perform (re-)installation of packages from downloaded artifacts during the test execution.
Upgrading System Packages from Artifacts
After the base artifact installation, it is possible to perform only the upgrade of packages already present system from the provided artifacts.
This option can be enabled by setting .environments[].settings.pipeline.update_from_artifacts: true in the request.
The action is executed only after all artifacts are downloaded to the system and a unified repository is constructed. System packages, whose newer versions are provided by any of the artifacts is upgraded to the latest version provided by any of the artifacts specified for the environment.
| === This option allows only to update all packages present on the base system that are present in the collection of all artifacts. === |
Reserved Directories
This section describes special reserved directories in the testing environment. Your tests should avoid touching these, or unexpected failures can happen.
/var/share/test-artifacts
This directory contains a repository of all downloaded artifacts.
Environment Variables
Testing Farm
Testing Farm exposes these environment variables to the tests.
-
TESTING_FARM_REQUEST_ID- An UUID4 string uniquely identifying the Testing Farm request. -
TESTING_FARM_TEST_TYPE- Test type format requested,fmfin case of tmt tests,stiin case of STI tests. -
TESTING_FARM_GIT_URL- The URL of the git repository. -
TESTING_FARM_GIT_REF- Branch, tag or commit specifying the desired git revision.
Packit
Packit exposes certain environment variables to the tests. Follow the official documentation for more information.