Test Request
Requesting testing is easiest via our CLI tool. |
tmt
Plan Filter
Testing Farm allows to use tmt plan filter.
The feature allows to filter out plans with a help of tmt filtering and regex.
The specified plan filter will be used in tmt plan ls --filter <YOUR-FILTER>
command.
By default enabled: true
filter is applied.
See tmt documentation for more information.
Test Filter
Testing Farm allows to use tmt test filter.
The feature allows to filter out tests in plans with a help of tmt filtering and regex.
The specified plan filter will be used in tmt run discover plan test --filter <YOUR-FILTER>
command.
See tmt documentation for more information.
Timeout
Testing Farm allows users to set the timeout for their requests in minutes. The default is 720 (12 hours). If a job is expected to take a short amount of time, setting a shorter timeout will benefit the user as they will not wait long to timeout on infrastructure issues for example.
Hardware Requirements
Testing Farm allows users to define hardware requirements for the testing environment. These hardware requirements are used to provision appropriate resources on supported infrastructures.
The CLI examples are shortened for brevity and concentrate only on the hardware selection. Additional required options will be required if you use them. |
The hardware selection is currently supported only on the Red Hat Ranch. Support for Public Ranch is coming in Q2/2023. |
Selection by hostname
Testing Farm provides an ability to provision a guest with a specific hostname. Ability to request a hostname matching a filter is also needed, because of guests of similar nature often sharing (sub)domain.
RAM size selection
Testing Farm provides an ability to provision a guest with specified amount of RAM. Most often, a specific amount of RAM is needed to accommodate a memory-hungry test, making the minimal requirement the most demanded one.
Disk size selection
Testing Farm provides an ability to provision a guest with specified disk size. The guest will get the disk size according to one of the suitable flavors:
-
🎩 Red Hat Ranch flavors (RH only link)
The default disk size is:
-
50 GiB
for 🌍 Public Ranch -
250 GiB
for 🎩 Red Hat Ranch
Selection by TPM version
Testing Farm provides an ability to provision a guest with specified Trusted Platform Modue (TPM) version.
Selecting systems by their boot method - BIOS
Testing Farm provides an ability to provision a guest supporting a specific boot method. The most common ones are (legacy) BIOS and UEFI, but some architectures may support their own specific methods as well.
Examples
testing-farm
CLI$ testing-farm request --hardware boot.method='bios'
$ testing-farm request --hardware boot.method='!= bios'
...
{
"environments": {[
"hardware": {
"boot": {
"method": "bios"
}
}
]}
}
...
...
{
"environments": {[
"hardware": {
"boot": {
"method": "!= bios"
}
}
]}
}
...
Selecting systems by their compatible distro
Testing Farm provides an ability to provision a guest supporting selected distributions (OS). It is possible to select a HW that is able to run a list of selected distributions.
Examples
testing-farm
CLI$ testing-farm request --hardware compatible.distro='rhel-7' --hardware compatible.distro='rhel-8'
This functionality is currently broken with CLI. See the issue here. |
...
{
"environments": {[
"hardware": {
"compatible": {
"distro": [
"rhel7",
"rhel8"
]
}
}
]}
}
...
Selection by the model name of processor
Testing Farm provides an ability to provision a guest with a CPU of a particular model name.
Selection by the model of processor
Testing Farm provides an ability to provision a guest with a CPU of a particular model.
Selection by the number of processors
Testing Farm provides an ability to provision a guest with a given (minimal) number of logical processors.
Selecting virtualized guests by their hypervisor
Testing Farm provides an ability to provision a guest that powered by a particular hypervisor.
Cancelling a Request
In some cases you want to prematurely cancel your request. Cancelling is straight forward.
Use the cancel
CLI command and provide the request ID or a string containing it.
testing-farm
CLI$ testing-farm cancel 9baab88b-aca6-4652-ad93-8d954e109a25
$ testing-farm cancel https://api.dev.testing-farm.io/v0.1/requests/a0f18d55-2dd5-466d-b2b8-6bd4a60ca12e
$ testing-farm cancel https://artifacts.dev.testing-farm.io/a0f18d55-2dd5-466d-b2b8-6bd4a60ca12e
If you prefer using our API, submit a request via the DELETE
method of the requests
endpoint and pass your token in the body of the request.
http DELETE https://api.dev.testing-farm.io/v0.1/requests/a0f18d55-2dd5-466d-b2b8-6bd4a60ca12e api_key=<YOUR_API_KEY>
Multihost Testing
Since release 2023-10.1, Testing Farm supports tmt
multihost testing.
This feature is introduced as a new Testing Farm pipeline, and it is not used by default.
Enable Multihost Pipeline
Multihost pipeline is currently opt-in using a feature flag in the test request. To enable it, the user has to fill the following field in the request JSON:
...
{
"settings": {
"pipeline": {
"type": "tmt-multihost"
}
}
}
...
The CLI supports this via the option --pipeline-type tmt-multihost
, which is available for request
and restart
commands:
testing-farm
CLI$ testing-farm request --pipeline-type tmt-multihost --git-url https://gitlab.com/testing-farm/tests --plan /testing-farm/multihost --compose Fedora-Rawhide
$ testing-farm restart --pipeline-type tmt-multihost REQUEST_ID
Feel free to submit a request yourself using the command above to try it out! |
Current Limitations
-
In the Testing Farm API, the fields
pool
,hardware
,artifacts
,settings
, andkickstart
from theenvironments
are ignored. -
Test environment preparation is not performed.
-
In the Testing Farm API, the
compose
field forces a single compose for all guests in the multihost environment, i.e. overwriting what is in the plan. -
The multihost testing is not available in Public Ranch, use Red Hat Ranch for testing.
Artifact Installation Order
While installing artifacts, Testing Farm follows the order described below.
-
repository-file -
10
-
repository -
20
-
fedora-copr-build -
30
-
redhat-brew-build -
40
-
fedora-koji-build -
50
You can change the order by setting the order
parameter of an artifact in the artifacts
section of the environments
definition.
The order of the installation is from lowest to the highest.