~cprov/uci-engine/tarmac-multienv

Local Development

-----------------

Development environments can be set of using the setup.py files in the

projects you wish to work on. The easiest approach is to use python-virtualenv.

Since most projects require the ci-utils project, that should almost always

get setup first.

Another quick way to get started is to look at the tarmac.sh script which

sets up a quick environment to run component testing under.

There are two types of services written in this project, Django and Restish.

Development varies slightly between the two.

Ticket System

~~~~~~~~~~~~~

::

  # setup the ticket system project

  sudo apt-get install python-virtualenv libssl-dev libapt-pkg-dev libffi-dev python-dev

  ./testing/venv.py /tmp/venv

  . /tmp/venv/bin/activate

  ./ci-utils/setup.py develop

  ./ticket_system/setup.py develop

Unit-testing can be done with::

  # via setuptools

  ./ticket_system/setup.py test

  # directly via django

  ./manage.py test  # this tests everything (including django)

  ./manage.py test ticket # just test the project

  ./manage.py test ticket.APIUpdateSubTicketStatuses #test one class

  ./manage.py test ticket.APIUpdateSubTicketStatuses.test_delete_subticket_not_allowed # test one method

CLI

~~~

::

  # setup the CLI project

  ./testing/venv.py /tmp/venv

  . /tmp/venv/bin/activate

  ./ci-utils/setup.py develop

Unit-testing can be done with::

  ./cli/setup.py test

Restish

~~~~~~~

::

  ./testing/venv.py /tmp/venv

  . /tmp/venv/bin/activate

  ./ci-utils/setup.py develop

  ./branch-source-builder/setup.py develop

Unit-testing can be done a couple of ways:

  # using setuptools:

  ./image-builder/setup.py test

  # python unittest directly

  python -m unittest discover -s branch-source-builder

Running under the python wsgi server can be done with::

  ./branch-source-builder/bsbuilder/wsgi.py

Running under gunicorn can be done with::

  # need gunicorn:

  pip install gunicorn

  # TIP: by setting max-requests=1 you can make changes to the source code

  # and they'll be picked up in the next http request you make!!

  gunicorn --max-requests 1 bsbuilder.wsgi:app

Juju Testing

------------

Each service should include a juju-deployer config under the juju-deployer

directory.

To deploy them all, run `./juju-deployer/deploy`

Install pre-requisites:

$ sudo apt-get install juju juju-deployer python-httplib2

Configure juju for canonistack (or whatever you feel is appropriate), make

sure you select the region there (see OS_REGION_NAME/NOVA_REGION):

$ . ~/.canonistack/novarc

Create a proper ~/.juju/environments.yaml, example:

environments:

  ## https://juju.ubuntu.com/docs/config-openstack.html

  lcy02:

    type: openstack

    admin-secret: <your admin secret, juju can auto-create it>

    # Globally unique swift bucket name

    control-bucket: <you control-bucket secret, juju can auto-create it>

    # Usually set via the env variable OS_REGION_NAME, but can be specified here

    region: lcy02

$ juju bootstrap --constraints="mem=1G"

Get the IP address of the juju state server from 'nova list --name machine-0':

$ nova list --name machine-0 --fields networks

+--------------------------------------+-------------------------+

| ID                                   | Networks                |

+--------------------------------------+-------------------------+

| 0463d358-750c-4fc4-b38b-a618e2e7d034 | canonistack=10.55.32.64 |

+--------------------------------------+-------------------------+

Start sshuttle in the foreground from a different terminal where you've sourced your credentials (we need a way to get that in a more script friendly way):

$ sshuttle -r ubuntu@10.55.32.64 10.55.0.0/16

You'll need to interrupt this command once you're run 'juju destroy-environment' to ensure you didn't leave pending connections to juju instances that should not exist anymore.

Running all tests

-----------------

Run all tests (unit and integration) with the following command:

$ JUJU_ENV=<env_name> ./run-tests [regexp]

It will build and deploy charms if necessary for the selected tests.

You can specify test name regexps like '^tests.'.

Also note that it will leave deployed instances behind (which are useful for subsequent test runs).

Running some tests

------------------

'run-tests' uses regexps to select tests.

A single test (note the '^' and '$' anchors to ensure a single test is

selected:

$ ./run-tests ^testing.test_style.TestPep8.test_pep8_conformance$

All the tests defined under a given directory:

$ ./run-tests ^cli

All style tests:

$ ./run-tests test_style

'^.*\.test_style\..*$' is pedantically more precise but in practice the

simplest form above is enough.

Several subsets to cover all tests related to the test runner component:

$ ./run-tests ^test_runner ^tests.test_test_runner

Excluding tests:

$ ./run-tests -X ^tests

will run all tests except the ones under the ./tests directory (which are

known to require a deployment and to be far slower than the others).