|
|
| (67 intermediate revisions by 11 users not shown) |
| Line 1: |
Line 1: |
| Tests are stored in [[Package_maintenance_guide|package git repositories]]. You can use the <code>fedpkg</code> tool to
| | Moved to: https://docs.fedoraproject.org/en-US/ci/tests/ |
| checkout a package git repository. If a <code>tests/</code> subdirectory exists, then the repository contains tests. The files ending in <code>.yml</code> in the <code>tests/</code> subdirectory each represent a test or a part of a test.
| |
| | |
| The tests are wrapped or written as [http://docs.ansible.com/ansible/playbooks.html Ansible playbooks] and
| |
| [https://fedoraproject.org/wiki/Changes/InvokingTests invoked according to this specification]. To invoke the tests you need the following dependencies (as described by the specification) installed on a modern Fedora system:
| |
| | |
| <pre>
| |
| $ sudo dnf install ansible python2-dnf libselinux-python standard-test-roles
| |
| </pre>
| |
| | |
| For the following documentation we'll checkout the <code>gzip</code> tests:
| |
| | |
| <pre>
| |
| $ fedpkg clone gzip
| |
| $ cd gzip/tests/
| |
| $ sudo -s
| |
| </pre>
| |
| | |
| {{admon/important|Work in progress|The upstreaming of tests is currently ongoing.
| |
| Use the following command until the end of Summer 2017.}}
| |
| | |
| <pre>
| |
| $ git clone https://upstreamfirst.fedorainfracloud.org/gzip.git
| |
| $ cd tests/
| |
| $ sudo -s
| |
| </pre>
| |
| | |
| Although some playbooks may function without sudo, tests are always invoked as root. The test
| |
| itself may set up users and/or drop permissions if a part of that test. But in general be sure
| |
| to be root when invoking tests.
| |
| | |
| == Running tests ==
| |
| | |
| You can always invoke the tests locally. Many tests modify or change the system they are run against, so take that into account when looking at how to invoke tests. The following tests invoke tests against the same system that the package git repository is checked out on. Below there are further options for invoking tests against another fully formed and integrated system, such as an Atomic Host or container image ''test subject''.
| |
| | |
| There may be more than one test present in a package git repository, but the file <code>tests.yml</code> is the main entry point. To run it use the following command:
| |
| | |
| <pre>
| |
| # ansible-playbook tests.yml
| |
| </pre>
| |
| | |
| You can find output artifacts of the tests in the current directory or specify a specific directory like this:
| |
| | |
| <pre>
| |
| # ansible-playbook -e artifacts=/tmp/output tests.yml
| |
| </pre>
| |
| | |
| When run by a CI System the tests are [[Changes/InvokingTests|invoked according to a specification]]. Look there for more details and standard invocation variables.
| |
| | |
| === Running against specific RPMs ===
| |
| | |
| When you run the tests as above, the tests assume that the system to be tested is the same as the system invoking the tests. In particular, the test assumes that the thing to be tested is already installed.
| |
| | |
| A ''test subject'' is what we call the thing to be tested. RPMs are a particular kind of ''test subject''. To turn a test subject into a launched, installed system to be tested, we use [http://docs.ansible.com/ansible/intro_inventory.html# Ansible dynamic inventory]. Lets invoke the tests with an inventory and a specific version of gzip:
| |
| | |
| <pre>
| |
| # ANSIBLE_INVENTORY=$(test -e inventory && echo inventory || echo /etc/ansible/inventory)
| |
| # curl -o gzip.rpm https://kojipkgs.fedoraproject.org//packages/gzip/1.8/2.fc26/x86_64/gzip-1.8-2.fc26.x86_64.rpm
| |
| # TEST_SUBJECTS=gzip.rpm
| |
| # ansible-playbook tests.yml
| |
| </pre>
| |
| | |
| You'll notice that the RPM is installed into the testable system before invoking the tests. Some tests contain their own inventory, that is their own instructions for turning a ''test subject'' into one or more testable systems. But in this case we use the default <code>standard-test-roles</code> inventory in <code>/etc/ansible/inventory</code> to do this.
| |
| | |
| === Running tests against an Atomic Host ===
| |
| | |
| The former example may seem a bit contrived, but the concept of a ''test subject'' starts to make more sense when you want to test a fully formed and integrated deliverable, such as Atomic Host. The ''test subject'' again represents the thing to be tested. The ''test subject'' in this case is a QCow2 image. To turn a test subject into a launched system ready to be tested, we use [http://docs.ansible.com/ansible/intro_inventory.html# Ansible dynamic inventory].
| |
| | |
| <pre>
| |
| # ANSIBLE_INVENTORY=$(test -e inventory && echo inventory || echo /etc/ansible/inventory)
| |
| # curl -Lo atomic.qcow2 https://ftp-stud.hs-esslingen.de/pub/Mirrors/alt.fedoraproject.org/atomic/stable/Fedora-Atomic-26-20170707.1/CloudImages/x86_64/images/Fedora-Atomic-26-20170707.1.x86_64.qcow2
| |
| # TEST_SUBJECTS=atomic.qcow2
| |
| # ansible-playbook tests.yml
| |
| </pre>
| |
| | |
| If you watch closely you'll see that the Atomic Host image is booted, and the tests run against the launched image. Not all tests are able to function in the somewhat different environment of Atomic Host, in fact for certain cases the software to be tested may not be included in the Atomic Host ''test subject''. But most of the tests in core packages should work here.
| |
| | |
| Some tests contain their own inventory, that is their own instructions for turning a
| |
| ''test subject'' into one or more testable systems. But in this case we use the default
| |
| <code>standard-test-roles</code> inventory to do this.
| |
| | |
| === Running the tests against a Container Image ===
| |
| | |
| TODO
| |
