ansible/test/integration
2016-10-21 20:17:42 +02:00
..
group_vars
host_vars breaks testing in non virtual envs, since env var can be used in those 2015-11-12 09:40:43 -08:00
roles Migrate Windows CI roles to test targets. (#18005) 2016-10-13 18:03:19 +01:00
targets tests: check that handlers are able to use 'include' 2016-10-21 20:17:42 +02:00
vars Split integration tests out from Makefile. (#17976) 2016-10-12 14:57:53 -07:00
amazon.yml Switch tests from sudo to become. (#17694) 2016-09-21 13:58:35 -07:00
azure.yml add azure integration tests 2015-05-04 23:45:03 -04:00
cleanup_azure.py add azure integration tests 2015-05-04 23:45:03 -04:00
cleanup_ec2.py Support print() function in test/ 2015-08-27 22:15:57 +03:00
cleanup_gce.py Support print() function in test/ 2015-08-27 22:15:57 +03:00
cleanup_rax.py Fix assert statement syntax 2015-08-27 22:15:57 +03:00
cloudflare.yml Add integration tests for the cloudflare_dns module 2016-03-25 21:22:29 +01:00
cloudstack.yml cloudstack: new integration tests test_cs_resourcelimit 2016-03-15 21:41:08 +01:00
consul.yml Initial commit of Ansible support for the Consul clustering framework (http://consul.io). 2015-01-24 01:09:03 +00:00
consul_inventory.yml Initial commit of Ansible support for the Consul clustering framework (http://consul.io). 2015-01-24 01:09:03 +00:00
consul_running.py Support print() function in test/ 2015-08-27 22:15:57 +03:00
credentials.template Changes to enable make gce to run. Added sys import so libcloud error is displayed; renamed credentials keys in template file so they work properly with gce_credentials.py. (#16607) 2016-09-16 10:02:18 -04:00
destructive.yml Migrate Linux CI roles to test targets. (#17997) 2016-10-13 09:09:25 -07:00
exoscale.yml exo_dns: new module utils and integration tests for exoscale DNS (#17230) 2016-08-30 21:48:28 +02:00
galaxy_playbook.yml
galaxy_playbook_git.yml [hotfix] add missed playbook file 2016-01-21 14:08:26 +02:00
galaxy_roles.yml Add tests for #10620 2015-11-18 20:47:54 +10:00
galaxy_rolesfile Add tests for #10620 2015-11-18 20:47:54 +10:00
gce.yml Integration Playbook for Google Cloud DNS module. (#17698) 2016-09-22 14:40:57 -04:00
gce_credentials.py Integration Playbook for Google Cloud DNS module. (#17698) 2016-09-22 14:40:57 -04:00
integration_config.yml epdb doesn't work on python3 so we need a different package to test pip 2016-10-17 18:44:51 -07:00
inventory Add binary module tests to Windows CI. (#16914) 2016-08-02 10:42:07 -07:00
inventory.remote.template Add support for OS X CI on Shippable. (#17160) 2016-08-23 10:49:46 -07:00
inventory.winrm.template Add binary module tests to Windows CI. (#16914) 2016-08-02 10:42:07 -07:00
jenkins.yml jenkins_job: add integration tests (#17499) 2016-09-13 16:03:58 +02:00
Makefile Make the test run when used on a local system (#18050) 2016-10-17 20:32:50 -07:00
non_destructive.yml Migrate Linux CI roles to test targets. (#17997) 2016-10-13 09:09:25 -07:00
rackspace.yml Add tests for rax_scaling_group 2015-06-18 13:08:35 -05:00
README.md Remove run_tests.sh and update docs. (#17719) 2016-09-22 23:51:53 -07:00
setup_gce.py Support print() function in test/ 2015-08-27 22:15:57 +03:00
test_win_group1.yml Migrate Windows CI roles to test targets. (#18005) 2016-10-13 18:03:19 +01:00
test_win_group2.yml Migrate Windows CI roles to test targets. (#18005) 2016-10-13 18:03:19 +01:00
test_win_group3.yml Migrate Windows CI roles to test targets. (#18005) 2016-10-13 18:03:19 +01:00

Integration tests

The ansible integration system.

Tests for playbooks, by playbooks.

Some tests may require credentials. Credentials may be specified with credentials.yml.

Tests should be run as root.

Quick Start

To get started quickly using Docker containers for testing, see Tests in Docker containers.

Configuration

Making your own version of integration_config.yml can allow for setting some tunable parameters to help run the tests better in your environment. Some tests (e.g. cloud) will only run when access credentials are provided. For more information about supported credentials, refer to credentials.template.

Prerequisites

The tests will assume things like hg, svn, and git are installed and in path.

(Complete list pending)

Non-destructive Tests

These tests will modify files in subdirectories, but will not do things that install or remove packages or things outside of those test subdirectories. They will also not reconfigure or bounce system services.

Run as follows:

make non_destructive

You can select specific tests with the --tags parameter.

TEST_FLAGS="--tags test_vars_blending" make

Destructive Tests

These tests are allowed to install and remove some trivial packages. You will likely want to devote these to a virtual environment. They won't reformat your filesystem, however :)

make destructive

Cloud Tests

Cloud tests exercise capabilities of cloud modules (e.g. ec2_key). These are not 'tests run in the cloud' so much as tests that leverage the cloud modules and are organized by cloud provider.

In order to run cloud tests, you must provide access credentials in a file named credentials.yml. A sample credentials file named credentials.template is available for syntax help.

Provide cloud credentials: cp credentials.template credentials.yml ${EDITOR:-vi} credentials.yml

Run the tests: make cloud

WARNING running cloud integration tests will create and destroy cloud resources. Running these tests may result in additional fees associated with your cloud account. Care is taken to ensure that created resources are removed. However, it is advisable to inspect your AWS console to ensure no unexpected resources are running.

Windows Tests

These tests exercise the winrm connection plugin and Windows modules. You'll need to define an inventory with a remote Windows 2008 or 2012 Server to use for testing, and enable PowerShell Remoting to continue.

Running these tests may result in changes to your Windows host, so don't run them against a production/critical Windows environment.

Enable PowerShell Remoting (run on the Windows host via Remote Desktop): Enable-PSRemoting -Force

Define Windows inventory: cp inventory.winrm.template inventory.winrm ${EDITOR:-vi} inventory.winrm

Run the tests: make test_winrm

Tests in Docker containers

If you have a Linux system with Docker installed, running integration tests using the same Docker containers used by the Ansible continuous integration (CI) system is recommended.

Using Docker Engine to run Docker on a non-Linux host is not recommended. Some tests, such as those that manage services or use local SSH connections are known to fail in such an environment. For best results, install Docker on a full Linux distribution such as Ubuntu, running on real hardware or in a virtual machine.

Running Integration Tests

To run all integration test targets with the default settings in a Centos 7 container, run make integration from the repository root.

You can also run specific tests or select a different Linux distribution. For example, to run the test test_ping from the non_destructive target on a Ubuntu 14.04 container:

  • go to the repository root
  • and execute make integration IMAGE=ansible/ansible:ubuntu1404 TARGET=non_destructive TEST_FLAGS='--tags test_ping'

Container Images

Use the prefix ansible/ansible: with the image names below.

Running make integration will automatically download the container image you have specified, if it is not already available. However, you will be responsible for keeping the container images up-to-date using docker pull.

Python 2

Most container images are for testing with Python 2:

  • centos6
  • centos7
  • fedora-rawhide
  • fedora23
  • opensuseleap
  • ubuntu1204 (requires PRIVILEGED=true)
  • ubuntu1404 (requires PRIVILEGED=true)
  • ubuntu1604

Python 3

To test with Python 3 you must set PYTHON3=1 and use the following images:

  • ubuntu1604py3

Additional Options

There are additional environment variables that can be used. A few of the more useful ones:

  • KEEP_CONTAINERS=onfailure - Containers will be preserved if tests fail.
  • KEEP_CONTAINERS=1 - Containers will always be preserved.
  • SHARE_SOURCE=1 - Changes to source from the host or container will be shared between host and container. CAUTION: Files created by the container will be owned by root on the host.