Revision as of 06:38, 31 January 2011 (view source) Esmietti (Talk | contribs) (→OTS Worker) ← Older edit		Latest revision as of 13:43, 3 February 2011 (view source) Tvainio (Talk | contribs) (→OTS Server)
Line 85:		Line 85:
	* '''No''' extension points used in 0.8		* '''No''' extension points used in 0.8
		+
		+	==== Input Plugins ====
		+
		+	OTS 0.1 supports feeding information back to ots client(for example the build machine) with input plugins. The key features of of OTS 0.1 input plugins are:
		+
		+	* Publish testrun log url to the client in the beginning of the testrun
		+	* Publish result urls to the client
		+	* Publish result files to the client
		+	* Runtime selection of input plugin with testrun options
		+
		+	OTS 0.8 does not support input plugins but is able to do the same things with Publisher plugins. The needed steps are described below. The publisher plugin replacing an input plugin is referred as ClientPublisher.
		+
		+	* Publish URLs to clients:
		+	# All publishers can share their report urls by implementing the get_this_publisher_uris() method. For example ots.plugins.logger shares the the testrun log url by doing this. All reporting tool plugins should do the same.
		+	# ClientPublisher needs to implement set_all_publisher_uris(self, uris_dict) method. The uris_dict contains all URLs from all publishers so it's easy to send them to the client in this method. The plugin can also filter the URLs if it does not want to send all of them to the client.
		+	# The URL processing is done right after all publishers are loaded so log url gets sent in the beginning of the testrun as expected.
		+
		+	* Result file Storage
		+	# ClientPublisher gets all result files by implementing set_results(self, results). It's easy to send them to client in that method..
		+
		+	* Dynamic runtime selection of input plugins
		+	# All plugin constructors get the additional testrun options as keyword arguments. Disabling and enabling a specific ClientPublisher can be done in the constructor by checking the input parameters.
		+
		+	* get_changed_packages(self, build_id)
		+	# This should be implemented in the particular reporting tool that requires this information. OTS does not use this information in test execution so there's no need to handle this in OTS.
	== OTS Worker ==		== OTS Worker ==

---

Latest revision as of 13:43, 3 February 2011

Contents 1 OTS migration from version 0.1.x to 0.8.x 1.1 OTS Server 1.1.1 Configuring 0.8 to match 0.1 1.1.1.1 Email 1.1.1.2 Default SW configuration and SW products 1.1.1.3 Django Based server 1.1.1.4 QA-Reports 1.1.1.5 Other configurations 1.1.1.6 Input Plugins 1.2 OTS Worker

OTS migration from version 0.1.x to 0.8.x

OTS Server

• First backup all old configurations

/etc/ots-server.ini
/opt/ots.sqlite
/etc/ots_qareports_plugin.conf
Your extension configurations

• Remove 0.1.x version

sudo apt-get purge python-ots-common python-ots-server python-server python-ots-qareports-plugin python-ots-tools

or

sudo rm -fr /usr/local/lib/python2.6/dist-packages/ots*

or

sudo rm -fr /usr/lib/python2.6/site-packages/ots*

• Follow 0.8 installation instructions how to setup the server

Configuring 0.8 to match 0.1

Email

• In 0.8 the email feature is implemented as OTS server's plug-in

• It uses the server's configuration file

/etc/ots_server.ini

• In 0.1 these settings were defined in your extension config. Copy values from there.

• If you want to use your 0.1 message_body, remove line break marks '\n' from the string and put all text between the """ -marks.

Default SW configuration and SW products

• In 0.8 default SW configurations and SW products are defined in the server's configuration.

/etc/ots_server.ini

• In 0.1 these settings were defined in your extension config.

• Add one or several SW products under the 'swproducts' section.

[swproducts]
  [[meego_n900]]
    timeout = 60
    distribution_model = default
    email = on
    email-attachments = off
    emmc = ""
    input_plugin = "default"
    [[[device]]]
      devicegroup = n900

  [[meego_aava]]
    timeout = 120
    distribution_model = default
    email = on
    email-attachments = on
    emmc = ""
    input_plugin = "default"
    [[[device]]]
      devicegroup = aava

Django Based server

• Follow the logger plug-in instructions how to setup new Django server.

• Old database file /opt/ots.sqlite, is not compatible with 0.8 version.

• No custom ots_config or extension points used anymore. If want to use testrun_db, create new plug-in to OTS server.

• HTTP logging is automatically on if plug-in is installed.

QA-Reports

• No changes in 0.8, just install python-ots-plugin-qareports to your OTS server.

• Configuration file is the same

/etc/ots_qareports_plugin.conf

Other configurations

• OTS 0.8 uses mainly the server's configuration. Update values from the 0.1 configuration (/etc/ots-server.ini) to 0.8 (/etc/ots_server.ini).

• No extension points used in 0.8

Input Plugins

OTS 0.1 supports feeding information back to ots client(for example the build machine) with input plugins. The key features of of OTS 0.1 input plugins are:

• Publish testrun log url to the client in the beginning of the testrun
• Publish result urls to the client
• Publish result files to the client
• Runtime selection of input plugin with testrun options

OTS 0.8 does not support input plugins but is able to do the same things with Publisher plugins. The needed steps are described below. The publisher plugin replacing an input plugin is referred as ClientPublisher.

• Publish URLs to clients:

1. All publishers can share their report urls by implementing the get_this_publisher_uris() method. For example ots.plugins.logger shares the the testrun log url by doing this. All reporting tool plugins should do the same.
2. ClientPublisher needs to implement set_all_publisher_uris(self, uris_dict) method. The uris_dict contains all URLs from all publishers so it's easy to send them to the client in this method. The plugin can also filter the URLs if it does not want to send all of them to the client.
3. The URL processing is done right after all publishers are loaded so log url gets sent in the beginning of the testrun as expected.

• Result file Storage

1. ClientPublisher gets all result files by implementing set_results(self, results). It's easy to send them to client in that method..

• Dynamic runtime selection of input plugins

1. All plugin constructors get the additional testrun options as keyword arguments. Disabling and enabling a specific ClientPublisher can be done in the constructor by checking the input parameters.

• get_changed_packages(self, build_id)

1. This should be implemented in the particular reporting tool that requires this information. OTS does not use this information in test execution so there's no need to handle this in OTS.

OTS Worker

• First backup all old configurations

/etc/conductor.conf
/etc/conductor/
/etc/ots.ini

• Remove 0.1.x version

sudo apt-get purge python-ots-common python-ots-worker

or

sudo rm -fr /usr/local/lib/python2.6/dist-packages/ots*

or

sudo rm -fr /usr/lib/python2.6/site-packages/ots*

• Follow 0.8 installation instructions how to setup the worker

• No changes in the configuration files, just copy old ots.ini and conductor.conf to /etc.

• No changes to customflasher.