Quick Start Guide
Are you eager to try out how the Fedora CI tests work? Do you want to get a quick hands-on experience without having to read too much documentation? This quick introduction for the impatient will show you a minimal set of steps to execute existing tests as well as provide useful links to resources where you can learn more.
Install the following essential packages on your system (consider using a virtual machine for safe experimenting):
sudo dnf install fedpkg standard-test-roles
fedpkg to clone the package git repository. See the
Guide for more info about the tool.
fedpkg clone -a bash
Tests are defined according to the
Standard Test Interface in the
Test coverage to be executed together with the basic set of metadata is
described in the
ansible-playbook to run all available tests for the classic
environment on the local host (needs to be run as root):
ansible-playbook --tags=classic tests.yml
From the ansible output you can directly see an overall summary of the
testing. If you see
failed=0 at the end of the log then all tests passed:
localhost: ok=29 changed=11 unreachable=0 failed=0
For more detailed test results check the
test.log and other files in the
That’s it! You just executed test coverage for the Bash package :)
To execute tests against different test subjects we need to prepare the
environment. Let’s store the detailed test results in
dynamic inventory as defined by the Standard
Test Roles and download the latest Atomic Host image.
export TEST_ARTIFACTS=/tmp/artifacts export ANSIBLE_INVENTORY=/usr/share/ansible/inventory curl -Lo /tmp/atomic.qcow2 https://getfedora.org/atomic_qcow2_latest
Now let’s try to run tests against all supported test subjects.
Run tests against classic rpms installed on the system:
export TEST_SUBJECTS='' ansible-playbook --tags=classic tests.yml
See Classic for detailed docs.
For testing containers there is an additional dependency needed:
sudo dnf install standard-test-roles-inventory-docker
Run tests in a docker container:
export TEST_SUBJECTS=docker:docker.io/library/fedora:latest ansible-playbook --tags=container tests.yml
See Container for detailed docs.
Run tests against the Atomic Host:
export TEST_SUBJECTS=/tmp/atomic.qcow2 ansible-playbook --tags=atomic tests.yml
See Atomic for detailed docs.
Would you like to investigate why a test failed? Enable debugging to easilly connect to running Atomic or Container to investigate:
export TEST_DEBUG=1 ansible-playbook --tags=atomic tests.yml
See Debug for details about debugging.
Are you interested in contributing a new test coverage? You are most welcome! As you have seen Executing a test is quite easy. Writing a new test or Wrapping an existing one is quite simple as well. Here’s a few recommendations for creating a new pull request.
Unless you are maintainer of the package, who has direct commit access, create a fork of the package git repository using the Fork button in Pagure web interface and add your private fork as a new remote. Create a branch for your new tests. For example:
git remote add fork ssh://email@example.com/forks/psss/rpms/bash.git git checkout -b tests
If you are not a Fedora packager, use
fedpkg command to clone you fork and
set up the git repo config so that you are able to push to it. See
pull_requests.adoc for more detailed info.
fedpkg clone -a forks/psss/rpms/bash git checkout -b tests
Create new test coverage under the
tests directory, update the
file accorgingly or create a new one. Run tests and verify they are stable
and working fine in all supported environments. Add files to git, commit
git add tests.yml test1 test2 test3 git commit -m "Add CI tests using the Standard Test Interface" git push fork tests:tests
It is a good idea to include more details and links in the commit message to make the pull request easier for review:
Create a new pull request from your
tests branch against the master branch
in the Pagure web
interface. You might want to include an additional info about the tests
Once the pull request is created CI Pipeline will detect it and execute tests. Once the test execution is finished you will see results of the testing on the pull request page. See the Pipeline page for the list of active pipelines and result examples.
Currently gating the package on test results is an opt-in feature. In order
to enable gating for you component create a
gating.yaml file in the root
of your component dist git repository. See Gating for