| Line 28: | Line 28: | ||
sudo easy_install minixsv | sudo easy_install minixsv | ||
| - | * Get source code from http://meego.gitorious.org/meego-quality-assurance/ots/ (tag | + | * Get source code from http://meego.gitorious.org/meego-quality-assurance/ots/ (latest tag) |
* Install ots.common: | * Install ots.common: | ||
| Line 250: | Line 250: | ||
"""Returns custom ResultBackends as a list""" | """Returns custom ResultBackends as a list""" | ||
return [QAReportsBackend()] | return [QAReportsBackend()] | ||
| + | </pre> | ||
| + | ===== Dynamic Report Control ===== | ||
| + | Starting from OTS 0.1.7 it's possible to control reporting options dynamically when triggering a testrun with "--options" command line parameter in ots_trigger: | ||
| + | <pre> | ||
| + | ots_trigger --options="qa_hwproduct:<HWPRODUCT> qa_testtype:<TESTTYPE> qa_target:<TARGET> qa_release_version:<RELEASE_VERSION>" | ||
</pre> | </pre> | ||
| Line 259: | Line 264: | ||
sudo apt-get install python-setuptools python-amqplib | sudo apt-get install python-setuptools python-amqplib | ||
| - | * Get source code from http://meego.gitorious.org/meego-quality-assurance/ots/ (tag | + | * Get source code from http://meego.gitorious.org/meego-quality-assurance/ots/ (latest tag) |
* Install ots.common: | * Install ots.common: | ||
Contents |
These instructions have been tested with Ubuntu 10.04.
Using static IP addresses on all OTS machines is strongly recommended. It is possible to setup the system also with dynamic IP addresses but it might cause problems every now and then because IP's and hostnames change.
All OTS machines need to be able to access other OTS machines based on their hostname.
sudo apt-get update sudo apt-get install python-setuptools python-amqplib python-django
sudo easy_install minixsv
cd ots/ots.common/ sudo python setup.py install
cd ots/ots.server/ sudo python setup.py install
cd ots/ots.tools/ sudo python setup.py install
sudo mkdir /var/log/ots
In [1]: from ots.server.xmlrpc.public import request_sync In [4]: program = "example_sw_product" In [5]: request = "5" In [6]: notify_list = ['tvainio@localhost'] In [7]: options = dict() In [8]: options['image'] = "http://somewhere/some_image.bin" In [9]: options['email'] = "off" In [13]: options["device"] = "devicegroup:default" # Make this match the worker In [14]: request_sync(program, request, notify_list, options) Out[14]: 'FAIL'
The result will be PASS/FAIL/ERROR. ERROR means that something went wrong in server side and testrun was not even started. FAIL means failed testrun and PASS means that everything went fine and all tests passed. Testrun logs with more information about the possible errors are available in /var/log/ots/
The previous example was not very useful. To get OTS server running as a real server you have two options. A simple xmlrpc server or a more advanced django based server. First thing you need to do is setup a custom config file.
Ots server tries to import a configuration module ots_extensions.ots_config. If it does not succeed it uses the default from ots.server.testrun_host.default_ots_config. You can set up your own ots_config by following these instructions:
mkdir my_ots_extensions
export PYTHONPATH=/full/path/to/my_ots_extensions/:$PYTHONPATH
mkdir my_ots_extensions/ots_extensions touch my_ots_extensions/ots_extensions/__init__.py
You can define default values for all options here. The example_sw_product contains and example how to define options. You cannot use an sw_product if it does not contain the default options in ots_config. Here's a small example. I'm developing a Meego based coffeemaker and creating custom software images for it. To automate the testing I create an sw_product called "my_meego_variant": TODO: Document all options
#
# Defaults for my_meego_variant
#
# Lets start with the global_defaults
default_options["my_meego_variant"] = global_defaults.copy()
# The images work only on meego coffeemakers so the default devicegroup will be "meego_coffeemaker"
default_options["my_meego_variant"]['device'] = {'devicegroup':'meego_coffeemaker'}
# Coffeemaker needs to be fast so we define a 3 minutes global timeout for the test execution.
default_options["my_meego_variant"]['timeout'] = 3
OTS uses plugins to do various things during the testrun. You can write your own plugins to add more functionality by implementing a module ots_extensions.extension_points. An example file can be found from ots/ots.server/ots/server/testrun_host/example_extension_points.py
ots_server
ots_trigger -s your_xmlrpc_host:your_xmlrpc_port -b 333 -i url_to_dummyimage -p my_meego_variant -e your_email_address
The result should be FAIL and if your email server settings are correct you should also receive an email.
2010-09-24 15:48:21,188 conductorengine ERROR Device group 'meego_coffeemaker' does not exist
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/ots.server-0.1dev-py2.6.egg/ots/server/conductorengine/conductorengine.py", line 150, in execute
self._taskrunner.run()
File "/usr/local/lib/python2.6/dist-packages/ots.server-0.1dev-py2.6.egg/ots/server/distributor/taskrunner.py", line 417, in run
(self._routing_key))
OtsQueueDoesNotExistError: No queue for meego_coffeemaker
With Django and Apache it's possible to set up a more advanced ots server.
There's for example a global logger application available in ots.server.logger. By setting up the logger it is possible to get log messages for a specific testrun from all parts of the system (ots server, ots conductor and testrunner-lite). The logs are stored into database and can be accessed with a web UI. It's also easy to implement a result db and web views for the test results.
If you are not familiar with Django you can study the basics from the tutorial: http://docs.djangoproject.com/en/1.2/intro/tutorial01/
These instructions assume that you have already done the setup described in: [[1]]
There is an example django project in ots.server.django_ots. It is possible to use that directly but in most cases you should create your own django project to be able to modify the settings.
sudo apt-get update sudo apt-get install python-django python-setuptools rabbitmq-server python-amqplib
python ots/server/django_ots/manage.py test logger testrun_db
python ots/server/django_ots/manage.py syncdb
The script asks about creating a superuser for the Django's auth system. OTS does not use the auth system at the moment but it might be useful to create the account if you start writing custom django applications or want to use django admin interface at some point.
If you get errors like "unable to open database file" make sure your user has write permissions to /opt/
sudo apt-get install apache2-mpm-prefork libapache2-mod-python
http_logging_enabled = True
<Location "/"> SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE ots.server.django_ots.settings PythonDebug On PythonPath "['ADD HERE THE PATH WHERE YOUR ots_extensions directory with CUSTOM OTS ENTRYPOINTS AND CONFIGFILE CAN BE FOUND'] + sys.path" </Location>
ots_trigger -s localhost/xmlrpc -b 333 -i url_to_dummyimage -p my_meego_variant -e your_email_address
If everything went ok you should see a succesful testrun and logs from OTS server, OTS Worker.conductor and testrunner-lite appearing in the http://localhost/logger/view/ and http://localhost/logger/view/ots/<your_testrun_id>/
If you only see log messages from your server most probably yuor hostnames are not set up correctly. The worker machine needs to be able to access the server by it's host name. Or you can try to play around with the "results_storage_config["host"]" setting in ots_config.py. It is the hostname ots_server sends to worker to use for global logging.
If you want to use different django setup you can create a custom django project. You can use ots/server/django_ots/ as an example. Django documentation contains lots of information about the features and settings: http://www.djangoproject.com/
The most important files are:
You also need to modify your apache configuration to point to your own django project instead of the default one. Also note that if you change your code, mod_python does not automatically reload the changed code so you need to restart apache to make sure you are using the right version of your code. If you do a full apache restart all ongoing testruns will fail. If you do a graceful restart ("apache2ctl graceful")the testruns won't fail but updated code is reloaded only after the testruns have fininshed.
Starting from version 0.1.6 OTS can automatically upload results to Meego QA Reports tool.
# More information about the options is available in # http://wiki.meego.com/Quality/QA-tools/QAReports/API [ots.qareports_plugin] host = "localhost" url = "/api/import" auth_token = "" release_version = "1.0" target = "Core" testtype = "Acceptance" hwproduct = "N900"
from ots.qareports_plugin.qareports_backend import QAReportsBackend
def get_resultbackends(testrun):
"""Returns custom ResultBackends as a list"""
return [QAReportsBackend()]
Starting from OTS 0.1.7 it's possible to control reporting options dynamically when triggering a testrun with "--options" command line parameter in ots_trigger:
ots_trigger --options="qa_hwproduct:<HWPRODUCT> qa_testtype:<TESTTYPE> qa_target:<TARGET> qa_release_version:<RELEASE_VERSION>"
sudo apt-get update sudo apt-get install python-setuptools python-amqplib
cd ots/ots.common/ sudo python setup.py install
cd ots/ots.worker/ sudo python setup.py install
########################################### # REPLACE `fix_me` WITH YOUR DEVICEGROUP ########################################### [Device] devicegroup = fix_me # Change this to the devicegroup this worker belongs to ############################# # Optional device properties ############################# #devicename = name of the device type # Uncomment these if you want more detailed testrun routing #deviceid = Specific HW id of the device # See http://wiki.meego.com/Quality/QA-tools/OTS/Routing for details ############################# # ADVANCED CONFIGURATION ############################# [Worker] host = your_server_address # Change this to your ots server address vhost = / port = 5672 username = guest password = guest log_file = /var/log/ots.log
More info about testrun routing is available here: Quality/QA-tools/OTS/Routing
sudo ots_worker
2010-11-08 12:55:10,790 - ots.worker.worker - DEBUG - Initialising the server
2010-11-08 12:55:10,790 - ots.worker.connection - DEBUG - Connecting to RabbitMQ
2010-11-08 12:55:10,894 - amqplib - DEBUG - Start from server, version: 8.0, properties: {u'platform': 'Erlang/OTP', u'product': 'RabbitMQ', u'version': '2.1.0', u'copyright': 'Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd.', u'information': 'Licensed under the MPL. See http://www.rabbitmq.com/'}, mechanisms: ['PLAIN', 'AMQPLAIN'], locales: ['en_US']
2010-11-08 12:55:10,935 - amqplib - DEBUG - Open OK! known_hosts []
2010-11-08 12:55:10,935 - amqplib - DEBUG - using channel_id: 1
2010-11-08 12:55:10,937 - amqplib - DEBUG - Channel open
2010-11-08 12:55:10,938 - ots.worker.worker - DEBUG - Starting the worker. server: 192.168.1.102:5672, device_properties: {'devicegroup': 'meego_coffeemaker'}
2010-11-08 12:55:10,957 - ots.worker.task_broker - INFO - consume on queue: meego_coffeemaker
2010-11-08 12:55:10,958 - ots.worker.task_broker - DEBUG - Starting main loop...