English French
Additional arguments for Docker
Andrei Stepanov (astepano)
Another example is to use a _test subject_ of a container image. This is also a fully formed and integrated deliverable. The _test subject_ again represents the thing to be tested. For testing containers there is an additional dependency needed:
ansible-playbook --tags=classic tests.yml
ansible-playbook --tags=container tests.yml -v
ansible-playbook --tags=container tests.yml -vvv
ansible-playbook tests.yml
A role for extracting upstream source tarball (with tests)
A role for installing additional rpms
A role for installing packages from additional yum repositories
Artifacts
*Artifacts cleanup* +
Before running tests make sure that all logs `/tmp/artifacts/test.*` are deleted.
A simple role for executing runtest.sh scripts, or other scripts in given directories
As you can see from the way how the inventory is set, tests may contain their own inventory, which defines their own instructions for turning a _test subject_ into one or more testable systems.
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_dynamic_inventory.html[Ansible dynamic inventory]. Let's invoke the tests with an inventory and a specific version of gzip:
A _test subject_ is what we call the thing to be tested. To turn a test subject into a launched, installed system to be tested, we use http://docs.ansible.com/ansible/intro_dynamic_inventory.html[Ansible dynamic inventory]. Use the following command to enable it:
Atomic
Basic
Basic role can be used for executing scripts or binaries as simple tests. For example the following `tests.yml` file will run `binary --help` as a shell command in the current directory and provide pass/fail based on its return code:
BeakerLib