-
Notifications
You must be signed in to change notification settings - Fork 0
CI Tests
Juju has many Continuous Integration (CI) tests that run whenever new code is checked in. These are long-running integration tests that do actual deploys to clouds, to ensure that juju works in real-world environments.
These instructions assume you're running on Ubuntu, they may be different on other platforms.
First we need to get the code. The CI tests are python scripts that are hosted on launchpad, so we'll use bzr to check them out.
sudo apt-get install bzr
Now we can get the CI tests:
bzr branch lp:juju-ci-tools
cd juju-ci-tools
bzr branch lp:juju-ci-tools/repository
And once we have the code, we can run the Makefile to install all the deps you need to run the tests.
make install-deps
juju-ci-tools
is where the actual tests live, the repository repo is a collection of charms used by some of the tests.
The scripts under juju-ci-tools are generally divided into three categories:
- The CI tests themselves, that get run by jenkins and show pass/fail. These scripts have the prefix "assess", i.e. assess_recovery.py.
- Unit tests of code in the CI tests and the helper scripts. These scripts have the prefix "test", i.e. test_assess_recovery.py.
- Helper scripts used by the CI tests. These are generally any file without one of the aforementioned prefixes.
The unit tests are written using python's unittest module.
To run all the tests, run make test
. To run the tests for a particular test file, run python -m unittest <module_name>
. For example, to run the unit tests in test_assess_recovery.py, run python -m unittest test_assess_recovery
.
The CI tests are just normal python files. Their return value indicates success or failure (0 for success, 1 for failure). You can just run the file, and it'll tell you the arguments it expects. In general, the tests will expect that you have a working juju binary and an environments.yaml file with usable environments. Most of the scripts ask for the path to your local juju binary and the name of an environment in your environments.yaml. The script will use these to bootstrap the indicated environment and run its tests.
If the test needs to deploy a test charm, you'll need to set the JUJU_REPOSITORY environment variable to the path where you checked out lp:juju-ci-tools/repository.
For example, to run the assess_log_rotation CI test using the local environment on your machine, the incantation would look like this (note that the './logs' directory must already exist):
~/juju-ci-tools$ JUJU_REPOSITORY=./repository ./assess_log_rotation.py machine $GOPATH/bin/ local ./logs
This will bootstrap an environment, deploy a test charm, call some actions on the charm, and then assess the results.
That's it. You've just run your first juju CI test. That's really about it.
Follow the example of assess_log_rotation.py, and don't forget unit tests!
Make sure everything passes make lint
(sudo apt-get install python-flake8
). We suggest you use autopep8 to make this process less painful (though it can't fix everything).
Testing
Releases
Documentation
Development
- READ BEFORE CODING
- Blocking bugs process
- Bug fixes and patching
- Contributing
- Code Review Checklists
- Creating New Repos
-
MongoDB and Consistency
- [mgo/txn Example] (https://github.com/juju/juju/wiki/mgo-txn-example)
- Scripts
- Update Launchpad Dependency
- Writing workers
- Reviewboard Tips
Debugging and QA
- Debugging Juju
- [Faster LXD] (https://github.com/juju/juju/wiki/Faster-LXD)