MeeGo wiki - User contributions [en]

Quality/QA-tools/QAReports

2012-11-20T09:03:03Z

Vesse:

= QA Reports =

<div style="padding:20px;border:2px solid red;font-size:1.1em;">This documentation is not updated anymore. For up-to-date information see [https://github.com/leonidas/qa-reports/wiki QA Reports wiki]</div>

[[File:MeeGoQAReports.png|right|415px]]

[http://qa-reports.meego.com/ MeeGo QA reports] is test reporting application for anyone testing MeeGo. Introductory screencast is available at [http://www.youtube.com/watch?v=yr_IdmqGniE YouTube]. You can also [http://dl.dropbox.com/u/10001820/QA%20Reports%20tutorial%20part%201.mp4 download the video].

== Access to MeeGo QA reports ==

Access to '''publish''' MeeGo QA reports is provided on need and request basis. If you need access please file a request at [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance MeeGo Quality Assurance > Others]

You can also create yourself a test account at [http://qa-reports.qa.leonidasoy.fi/users/register staging environment] and play around with the system.

== User Documentation ==

* [[Quality/QA-tools/QAReports/Basic_Workflow|User guide]]
* [[Quality/QA-tools/QAReports/API|API Documentation]]
* [[Quality/QA-tools/QAReports/User_FAQ|F.A.Q]]

== Administration Guide ==

* [[Quality/QA-tools/QAReports/Setting_up_the_production_environment|Setting up the production environment]]
* [[Quality/QA-tools/QAReports/Admin_FAQ|F.A.Q]]

== Environments ==

* [http://qa-reports.meego.com/ Production environment - http://qa-reports.meego.com]
* [http://qa-reports.qa.leonidasoy.fi/ Staging environment - http://qa-reports.qa.leonidasoy.fi/]

== Source code ==

* [http://meego.gitorious.org/meego-quality-assurance/qa-reports Source code in Gitorious]

== Developer information ==

* [[Quality/QA-tools/QAReports/Setting_up_the_development_environment|Setting up the development environment]]
* [[Quality/QA-tools/QAReports/Contributing_to_qa-reports|Contributing to MeeGo QA Reports]]

== Contact information ==

QA Reports is developed by [[Quality/QA-tools | QA tools team]]. You can contact us via the following channels:
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance&component=meego-qa-reports File new bugs or improvement ideas to Bugzilla]
* [http://bugs.meego.com/buglist.cgi?bug_status=NEW&bug_status=NEEDINFO&bug_status=INDEFINITION&bug_status=ASSIGNED&bug_status=ACCEPTED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=RELEASED&bug_status=VERIFIED&component=meego-qa-reports&query_format=advanced&order=priority%2Cbug_severity%2Cchangeddate%2Cbug_status%2Cassigned_to%2Cbug_id&query_based_on= Leave a comment or vote the items in our backlog]
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]

Quality/QA-tools/QAReports/Setting up the development environment

2011-12-19T11:48:38Z

Vesse: /* Set up QA Reports */

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This documentation is based on Ubuntu 10.10

==Install Ruby==

Packaged version of Ruby tends to be pretty old and won't probably won't work very well. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev libqt4-dev</tt>
# Install rvm: <tt>$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)</tt> # NOTE: if network proxy blocks cloning via git proxy, try download the script and change git to http
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install ree</tt>
# Set into use: <tt>$ rvm use ree</tt>
## If you want to use this ruby version as a default, use <tt>$ rvm --default use ree</tt>
# <tt>$ gem update --system</tt>

==Set up QA Reports==

# Install preqrequisites:
## <tt>$ sudo apt-get install libmysqlclient-dev mysql-server libxml2-dev libxslt1-dev</tt>
## <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# <tt>$ cd qa-reports</tt>
# <tt>$ bundle install --without staging production</tt> (If bundle install fails, run <tt>$ apt-get install libqt4-dev</tt> first.)
# <tt>$ cp config/database.example.yml config/database.yml</tt>

Create MySQL user and two databases, one for development and the other for executing the tests
# <tt>$ mysql -u root -p</tt>
# <tt>mysql> create user 'qa_reports'@'localhost' identified by '<password_of_your_choosing>';</tt>
# <tt>mysql> create database qa_reports_development;</tt>
# <tt>mysql> create database qa_reports_test;</tt>
# <tt>mysql> grant all on qa_reports_development.* to 'qa_reports'@'localhost';</tt>
# <tt>mysql> grant all on qa_reports_test.* to 'qa_reports'@'localhost';</tt>
# <tt>mysql> exit</tt>

Configure QA Reports to use MySQL databases by editing <tt>config/database.yml</tt> as shown below
<code>
development:
adapter: mysql2
encoding: utf8
reconnect: false
database: qa_reports_development
pool: 5
username: qa_reports
password: <password_of_your_choosing>
socket: /var/run/mysqld/mysqld.sock

test:
adapter: mysql2
encoding: utf8
reconnect: false
database: qa_reports_test
pool: 5
username: qa_reports
password: <password_of_your_choosing>
socket: /var/run/mysqld/mysqld.sock
</code>

Run the migrations
# <tt>$ bundle exec rake db:migrate</tt>

Add a release and a profile to the database
# <tt>$ mysql -u <user> -p qa_reports_development</tt>
# <tt>mysql> INSERT INTO releases(name, sort_order) VALUES('1.3', 0);</tt>
# <tt>mysql> INSERT INTO profiles(name, sort_order) VALUES('Core', 0);</tt>
# <tt>mysql> exit</tt>

==Run the tests and start the server==
# <tt>$ bundle exec rake spec</tt>, all unit tests should pass
# <tt>$ bundle exec rake cucumber</tt>, all integration tests should pass
# Start the server: <tt>$ bundle exec rails server</tt>
# Register a new user for yourself: <tt>http://localhost:3000/users/register</tt>

Quality/QA-tools/QAReports/Setting up the development environment

2011-12-19T11:47:53Z

Vesse: /* Set up QA Reports */ Added instructions for adding a release and a profile since at least one of each is required

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This documentation is based on Ubuntu 10.10

==Install Ruby==

Packaged version of Ruby tends to be pretty old and won't probably won't work very well. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev libqt4-dev</tt>
# Install rvm: <tt>$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)</tt> # NOTE: if network proxy blocks cloning via git proxy, try download the script and change git to http
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install ree</tt>
# Set into use: <tt>$ rvm use ree</tt>
## If you want to use this ruby version as a default, use <tt>$ rvm --default use ree</tt>
# <tt>$ gem update --system</tt>

==Set up QA Reports==

# Install preqrequisites:
## <tt>$ sudo apt-get install libmysqlclient-dev mysql-server libxml2-dev libxslt1-dev</tt>
## <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# <tt>$ cd qa-reports</tt>
# <tt>$ bundle install --without staging production</tt> (If bundle install fails, run <tt>$ apt-get install libqt4-dev</tt> first.)
# <tt>$ cp config/database.example.yml config/database.yml</tt>

Create MySQL user and two databases, one for development and the other for executing the tests
# <tt>$ mysql -u root -p</tt>
# <tt>mysql> create user 'qa_reports'@'localhost' identified by '<password_of_your_choosing>';</tt>
# <tt>mysql> create database qa_reports_development;</tt>
# <tt>mysql> create database qa_reports_test;</tt>
# <tt>mysql> grant all on qa_reports_development.* to 'qa_reports'@'localhost';</tt>
# <tt>mysql> grant all on qa_reports_test.* to 'qa_reports'@'localhost';</tt>
# <tt>mysql> exit</tt>

Configure QA Reports to use MySQL databases by editing <tt>config/database.yml</tt> as shown below
<code>
development:
adapter: mysql2
encoding: utf8
reconnect: false
database: qa_reports_development
pool: 5
username: qa_reports
password: <password_of_your_choosing>
socket: /var/run/mysqld/mysqld.sock

test:
adapter: mysql2
encoding: utf8
reconnect: false
database: qa_reports_test
pool: 5
username: qa_reports
password: <password_of_your_choosing>
socket: /var/run/mysqld/mysqld.sock
</code>

Run the migrations
# <tt>$ bundle exec rake db:migrate</tt>

Add a release and a profile to the database
# <tt>$ mysql -u <user> -p qa_reports_development</tt>
# <tt>mysql> INSERT INTO releases(name, sort_order) VALUES('1.3', 0);</tt>
# <tt>mysql> INSERT INTO profiles(name, sort_order) VALUES('Core', 0);</tt>
# <tt>mysql> exit

==Run the tests and start the server==
# <tt>$ bundle exec rake spec</tt>, all unit tests should pass
# <tt>$ bundle exec rake cucumber</tt>, all integration tests should pass
# Start the server: <tt>$ bundle exec rails server</tt>
# Register a new user for yourself: <tt>http://localhost:3000/users/register</tt>

Quality/QA-tools/QAReports/Setting up the production environment

2011-06-21T08:08:14Z

Vesse: /* Configuring data flow to QA Dashboard */

= Overview =

Running and deploying QA Reports relies heavily on automated deployment scripts and version control repository. At high level, deployment process is following:

# Log in to your workstation and update QA Reports working tree
# Run Capistrano deployment script on your workstation
# Capistrano script connects to the production server and updates the deployment by
## Connecting to version control system from production server and updating the source code on the production server
## Running the migrations and updating the database schema on production server
## Restarting the application on production server

Capistrano enables you to automate also other administrative tasks like
# Rolling back to previous deployment
# Exporting data from production environment to your development environment

To achieve all the goodness, you should [[Quality/QA-tools/QAReports/Setting up the development environment|set up the development environment]] on your workstation before continuing.

= Setting up the production server =

This guide has been written for vanilla Ubuntu 10.04 installation. You need to be logged in to the production server and have sudo rights to continue.

== Install dependencies ==

<code>$ sudo aptitude install curl build-essential git-core openssh-server zlib1g-dev libssl-dev libreadline5-dev libcurl4-openssl-dev</code>

== Install Ruby ==

# Install [http://rvm.beginrescueend.com/ Ruby Version Manager] as root (to have system-wide install) <code>$ bash < <(curl -B http://rvm.beginrescueend.com/install/rvm)</code>
# Set up .bashrc as instructed by RVM installer: The whole content into an if section, and after that loading of RVM. Here's an example [http://gist.github.com/822216 .bashrc]
# Run: $ source ~/.bashrc
# Add your account and the deployment account to <code>rvm</code> group, e.g. <code>$ sudo adduser jakeskik rvm</code>
# Source your .bashrc to enable rvm <code>$ source ~/.bashrc</code>
# Install Ruby Enterprise Edition <code>$ rvm install ree</code>
# Set the default Ruby interpreter <code>$ rvm use --default ree</code>
# Install bundler <code>$ gem install rails bundler --no-ri --no-rdoc</code> #if you have proxy problem, plz refer to http://docs.rubygems.org/read/chapter/13#page51

Finally, enable rvm and Ruby Enterprise Edition to your deployment account, e.g. www-data

# Edit <code>/etc/passwd</code> and change <code>www-data</code>'s shell from <code>sh</code> to <code>bash</code>. You might want to change the home directory also from <code>/var/www</code> to e.g. <code>/home/www-data</code> as shown below <code>www-data:x:33:33:www-data:/home/www-data:/bin/bash</code>
# Enable RVM as shown below
<code>
$ sudo adduser www-data rvm
$ sudo -iu www-data
$ cp ~jakeskik/.profile .
$ cp ~jakeskik/.bashrc .
$ exit
</code>

== Install Apache and Phusion Passenger ==

<code>
$ sudo apt-get install apache2 apache2-prefork-dev libapr1-dev libaprutil1-dev
$ gem install passenger --no-ri --no-rdoc
$ rvmsudo passenger-install-apache2-module # Follow the on-screen instructions and edit apache.conf
$ sudo service apache2 restart
</code>

== Install MySQL ==

<code>
$ sudo apt-get install mysql-server libmysqlclient-dev
</code>

== Install Postfix ==

QA Reports sends email notifications for system administrators (you) in case the application throws an exception. To enable notifications, there needs to be a mail server configured on the production host.

<code>
$ sudo apt-get install postfix
</code>

The default configuration is fine and allows only delivery for emails originated from localhost. Just click through the installer.

== Test the environment ==

After installing the software, run a sanity check for the environment by creating a 'hello world' rails project and corresponding virtual host:

<code>
$ sudo -iu www-data
$ rails new hello
$ cd hello/public && pwd
/home/www-data/hello/public
$ exit
</code>

Write a following virtual host declaration to /etc/apache/sites-available/hello:

<code>
<VirtualHost *:80>
ServerName hello.qa.leonidasoy.fi
DocumentRoot /home/www-data/hello/public

<Directory /home/www-data/hello/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite hello
$ sudo service apache2 restart
</code>

Add the virtual host to <code>/etc/hosts</code> file:
<code>
127.0.0.1 hello.qa.leonidasoy.fi # Use the same domain as above
</code>

Now you should be able to access the 'hello world' project with a browser, e.g. lynx

<code>
$ lynx hello.qa.leonidasoy.fi
</code>

== Create a database for QA Reports ==

<code>
$ mysql -u root -p
mysql> create user 'qa-reports'@'localhost' identified by 'somepasswordofyourchoosing';
mysql> create database qa_reports_production character set 'utf8';
mysql> grant all privileges on qa_reports_production.* to 'qa-reports'@'localhost';
mysql> flush privileges;
mysql> exit
</code>

== Create virtual host for QA Reports ==

Write a following virtual host declaration to /etc/apache/sites-available/qa-reports:

<code>
<VirtualHost *:80>
ServerName qa-reports.qa.leonidasoy.fi
DocumentRoot /home/www-data/qa-reports.meego.com/current/public

<Directory /home/www-data/qa-reports.meego.com/current/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite qa-reports
$ sudo service apache2 restart # Don't mind the warning about missing dir,
# we'll deal with that one in a sec
</code>

= Deploying QA Reports =

QA Reports uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details.

Capistrano is run from your development environment, so you should be now on your workstation with working QA Reports development environment to continue.

== Enable public key authentication for your deployment account ==

Set up public key authentication:
# Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
# Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
# Try logging in: <tt>ssh your.production.user@your.production.host</tt>

== Modify Capistrano scripts and deploy QA Reports ==

QA Reports uses following scripts to configure Capistrano
* <tt>config/deploy.rb</tt>
* <tt>config/deploy/staging.rb</tt>
* <tt>config/deploy/production.rb</tt>

You might want to review all the files, but usually it's enough to update only <tt>config/deploy/production.rb</tt> according to your needs (servers, deployment account, ssh options). You can also create new deployment environment just by copying the production.rb, to e.g. internal.rb and modify it.

Once the Capistrano is updated according to your needs, run
<code>
$ cap production deploy:setup # or cap internal deploy:setup, if you created a new deployment environment
</code>

Setup command creates the folder hierarchy and the symbolic links required by Capistrano. During the setup it requests following information
# Database host
# Database port
# Database name
# Database username
# Database password
# Should QA Reports send performance data to [http://newrelic.com NewRelic]? (Default: no)
# Registration token. This will be part of the registration url, e.g. <tt>foobar</tt> will make registration to be at url <tt>/users/foobar/register</tt>
# Email addresses for Exception Notifier

Once the setup is complete, the deployment is as easy as it gets
<code>
$ cap production deploy:migrations
</code>

You should now have QA Reports up&running. Congrats!

== Update QA Reports to a new version ==

# <code>git pull</code> (In case there's changes in the deployment scripts)
# <code>cap production deploy:migrations</code>
# Ta-da!

== Roll back to previous version ==

# <code>cap production deploy:rollback</code>
# Ta-da!

= Configuring data flow to QA Dashboard =

If you have set up [[Quality/QA-tools/QADashboard|QA Dashboard]] you will most likely want to enable data synchronization to it:

* Get authentication token to QA Dashboard
** This is currently a bit cumbersome: you need to open URI <tt>/user/token</tt> from your QA Dashboard server, save the file it offers to download and get the token from there.
* Configure QA Reports
** Insert correct QA Dashboard host and the authentication token to <tt>config/qa-dashboard_config.yml</tt>. The file is deployed with Capistrano task <tt>deploy:setup</tt>.

If you need to export all your QA Reports data to your QA Dashboard you should use QA Reports' rake task. Once you have QA Reports up and running with correct QA Dashboard export setup, login to the production environment, go to folder <tt>your_installation/current</tt> and execute <tt>RAILS_ENV=production rake db:export_to_qadashboard</tt>.

Note: If you need to clear existing data from your QA Dashboard database, you will need to execute both <tt>db['qa-reports'].drop()</tt> and <tt>db['qa-reports'].dropIndexes()</tt> in the MongoDB database.

= Setting Up the Production Environment with nginx instead of Apache =

# Follow instructions above until "Install Apache and Passenger", then continue here from step 2.
# Install passenger: <tt>$ gem install passenger</tt>
# Install nginx: <tt>$ passenger-install-nginx-module</tt>
## Notice: the default location is under <tt>/opt</tt>. If you wish to install there, use <tt>rvmsudo</tt>. Notice however, that part of your <tt>~/.rvm</tt> contents will then belong to root and may cause gray hair later. I chose to install under <tt>~/nginx</tt>.
Edit nginx configuration <tt>installation_path/conf/nginx.conf</tt>:
## Comment out section <tt>location / { ... }</tt>
## Add lines:
### <tt>passenger_enabled on;</tt>
### <tt>root /home/your_prod_env_user/qa-reports.meego.com/current/public;</tt>
# Start nginx: <tt>$ sudo /installation_path/sbin/nginx</tt>
# Continue with the guide above from "Deploying QA Reports"

Quality/QA-tools/QADashboard/Setting up the production environment

2011-06-21T07:59:02Z

Vesse:

= Overview =

Running and deploying QA Dashboard relies heavily on automated deployment scripts and version control repository. At high level, deployment process is following:

# Log in to your workstation and update QA Dashboard working tree
# Run Capistrano deployment script on your workstation
# Capistrano script connects to the production server and updates the deployment by
## Connecting to version control system from production server and updating the source code on the production server
## Installing node package dependencies
## Restarting the application on production server

= Setting up the local environment for deployments =

QA Dashboard uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details

== Install development environment ==

You should first [http://wiki.meego.com/Quality/QA-tools/QADashboard/Setting_up_the_development_environment set up the development environment] on your workstation before continuing.
Capistrano is run from your development environment

== Installing Capistrano ==

Capistrano requires Ruby. If you do not have Ruby installed please follow the "Install Ruby" instructions [http://wiki.meego.com/Quality/QA-tools/QAReports/Setting_up_the_development_environment here].

<tt>$ gem install capistrano</tt>

= Setting up the production server =

== Install dependencies ==

The same dependencies are needed in the production server as in development environment.
Follow the instructions in [[Quality/QA-tools/QADashboard/Setting_up_the_development_environment]] to:
# Install Node.js
# Install Node Package Manager
# Install mongodb

== Create virtual host for QA Dashboard ==
(example using nginx)

Write a following virtual host declaration to /etc/nginx/sites-available/qa-dashboard

<code>
server {
listen 80;
server_name qa-dashboard.qa.leonidasoy.fi;
location / {
proxy_pass http://localhost:3030;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}
</code>

Restart nginx
<code>
sudo service nginx restart
</code>

= Deploying QA Dashboard =

== Enable public key authentication for your deployment account ==

Set up public key authentication:
# Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
# Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
# Try logging in: <tt>ssh your.production.user@your.production.host</tt>

== Modify settings ==

QA Dashboard authentication settings are defined in <tt>settings.json</tt> that is deployed with Capistrano.

=== LDAP Authentication ===

TODO

=== MySQL Authentication ===

TODO

== Modify Capistrano scripts and setup deployment ==

QA Dashboard uses following scripts to configure Capistrano
* <tt>config/deploy.rb</tt>
* <tt>config/deploy/staging.rb</tt>
* <tt>config/deploy/production.rb</tt>

You might want to review all the files, but usually it's enough to update only <tt>config/deploy/production.rb</tt> according to your needs (servers, deployment account, ssh options). You can also create new deployment environment just by copying the production.rb, to e.g. internal.rb and modify it.

When you deploy for first time you need to run setup command, which creates creates the folder hierarchy and the symbolic links required by Capistrano. 
Once the Capistrano is updated according to your needs you need to run setup command, which creates creates the folder hierarchy and the symbolic links required by Capistrano. After that the server can be started.
<code>
$ cap production deploy:setup # or cap internal deploy:setup, if you created a new deployment environment
$ cap production deploy:start # starts the server
</code>

== Deploying QA Dashboard ==

Once the setup is complete, the deployment is as easy as it gets
<code>
$ cap production deploy
</code>

== Setting up the data flow ==

QA Dashboard naturally needs data to be shown. This data usually comes from [[Quality/QA-tools/QAReports|QA Reports]] and Bugzilla.

=== Getting data from QA Reports ===
Instructions for setting up the data synchronization is described in [[Quality/QA-tools/QAReports/Setting_up_the_production_environment#Configuring_data_flow_to_QA_Dashboard|QA Reports installation guide]].

=== Getting data from Bugzilla ===

TODO: Document Bugzilla exporter setup and usage

Quality/QA-tools/QAReports/Setting up the production environment

2011-06-21T07:55:27Z

Vesse:

= Overview =

Running and deploying QA Reports relies heavily on automated deployment scripts and version control repository. At high level, deployment process is following:

# Log in to your workstation and update QA Reports working tree
# Run Capistrano deployment script on your workstation
# Capistrano script connects to the production server and updates the deployment by
## Connecting to version control system from production server and updating the source code on the production server
## Running the migrations and updating the database schema on production server
## Restarting the application on production server

Capistrano enables you to automate also other administrative tasks like
# Rolling back to previous deployment
# Exporting data from production environment to your development environment

To achieve all the goodness, you should [[Quality/QA-tools/QAReports/Setting up the development environment|set up the development environment]] on your workstation before continuing.

= Setting up the production server =

This guide has been written for vanilla Ubuntu 10.04 installation. You need to be logged in to the production server and have sudo rights to continue.

== Install dependencies ==

<code>$ sudo aptitude install curl build-essential git-core openssh-server zlib1g-dev libssl-dev libreadline5-dev libcurl4-openssl-dev</code>

== Install Ruby ==

# Install [http://rvm.beginrescueend.com/ Ruby Version Manager] as root (to have system-wide install) <code>$ bash < <(curl -B http://rvm.beginrescueend.com/install/rvm)</code>
# Set up .bashrc as instructed by RVM installer: The whole content into an if section, and after that loading of RVM. Here's an example [http://gist.github.com/822216 .bashrc]
# Run: $ source ~/.bashrc
# Add your account and the deployment account to <code>rvm</code> group, e.g. <code>$ sudo adduser jakeskik rvm</code>
# Source your .bashrc to enable rvm <code>$ source ~/.bashrc</code>
# Install Ruby Enterprise Edition <code>$ rvm install ree</code>
# Set the default Ruby interpreter <code>$ rvm use --default ree</code>
# Install bundler <code>$ gem install rails bundler --no-ri --no-rdoc</code> #if you have proxy problem, plz refer to http://docs.rubygems.org/read/chapter/13#page51

Finally, enable rvm and Ruby Enterprise Edition to your deployment account, e.g. www-data

# Edit <code>/etc/passwd</code> and change <code>www-data</code>'s shell from <code>sh</code> to <code>bash</code>. You might want to change the home directory also from <code>/var/www</code> to e.g. <code>/home/www-data</code> as shown below <code>www-data:x:33:33:www-data:/home/www-data:/bin/bash</code>
# Enable RVM as shown below
<code>
$ sudo adduser www-data rvm
$ sudo -iu www-data
$ cp ~jakeskik/.profile .
$ cp ~jakeskik/.bashrc .
$ exit
</code>

== Install Apache and Phusion Passenger ==

<code>
$ sudo apt-get install apache2 apache2-prefork-dev libapr1-dev libaprutil1-dev
$ gem install passenger --no-ri --no-rdoc
$ rvmsudo passenger-install-apache2-module # Follow the on-screen instructions and edit apache.conf
$ sudo service apache2 restart
</code>

== Install MySQL ==

<code>
$ sudo apt-get install mysql-server libmysqlclient-dev
</code>

== Install Postfix ==

QA Reports sends email notifications for system administrators (you) in case the application throws an exception. To enable notifications, there needs to be a mail server configured on the production host.

<code>
$ sudo apt-get install postfix
</code>

The default configuration is fine and allows only delivery for emails originated from localhost. Just click through the installer.

== Test the environment ==

After installing the software, run a sanity check for the environment by creating a 'hello world' rails project and corresponding virtual host:

<code>
$ sudo -iu www-data
$ rails new hello
$ cd hello/public && pwd
/home/www-data/hello/public
$ exit
</code>

Write a following virtual host declaration to /etc/apache/sites-available/hello:

<code>
<VirtualHost *:80>
ServerName hello.qa.leonidasoy.fi
DocumentRoot /home/www-data/hello/public

<Directory /home/www-data/hello/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite hello
$ sudo service apache2 restart
</code>

Add the virtual host to <code>/etc/hosts</code> file:
<code>
127.0.0.1 hello.qa.leonidasoy.fi # Use the same domain as above
</code>

Now you should be able to access the 'hello world' project with a browser, e.g. lynx

<code>
$ lynx hello.qa.leonidasoy.fi
</code>

== Create a database for QA Reports ==

<code>
$ mysql -u root -p
mysql> create user 'qa-reports'@'localhost' identified by 'somepasswordofyourchoosing';
mysql> create database qa_reports_production character set 'utf8';
mysql> grant all privileges on qa_reports_production.* to 'qa-reports'@'localhost';
mysql> flush privileges;
mysql> exit
</code>

== Create virtual host for QA Reports ==

Write a following virtual host declaration to /etc/apache/sites-available/qa-reports:

<code>
<VirtualHost *:80>
ServerName qa-reports.qa.leonidasoy.fi
DocumentRoot /home/www-data/qa-reports.meego.com/current/public

<Directory /home/www-data/qa-reports.meego.com/current/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite qa-reports
$ sudo service apache2 restart # Don't mind the warning about missing dir,
# we'll deal with that one in a sec
</code>

= Deploying QA Reports =

QA Reports uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details.

Capistrano is run from your development environment, so you should be now on your workstation with working QA Reports development environment to continue.

== Enable public key authentication for your deployment account ==

Set up public key authentication:
# Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
# Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
# Try logging in: <tt>ssh your.production.user@your.production.host</tt>

== Modify Capistrano scripts and deploy QA Reports ==

QA Reports uses following scripts to configure Capistrano
* <tt>config/deploy.rb</tt>
* <tt>config/deploy/staging.rb</tt>
* <tt>config/deploy/production.rb</tt>

You might want to review all the files, but usually it's enough to update only <tt>config/deploy/production.rb</tt> according to your needs (servers, deployment account, ssh options). You can also create new deployment environment just by copying the production.rb, to e.g. internal.rb and modify it.

Once the Capistrano is updated according to your needs, run
<code>
$ cap production deploy:setup # or cap internal deploy:setup, if you created a new deployment environment
</code>

Setup command creates the folder hierarchy and the symbolic links required by Capistrano. During the setup it requests following information
# Database host
# Database port
# Database name
# Database username
# Database password
# Should QA Reports send performance data to [http://newrelic.com NewRelic]? (Default: no)
# Registration token. This will be part of the registration url, e.g. <tt>foobar</tt> will make registration to be at url <tt>/users/foobar/register</tt>
# Email addresses for Exception Notifier

Once the setup is complete, the deployment is as easy as it gets
<code>
$ cap production deploy:migrations
</code>

You should now have QA Reports up&running. Congrats!

== Update QA Reports to a new version ==

# <code>git pull</code> (In case there's changes in the deployment scripts)
# <code>cap production deploy:migrations</code>
# Ta-da!

== Roll back to previous version ==

# <code>cap production deploy:rollback</code>
# Ta-da!

= Configuring data flow to QA Dashboard =

TODO

= Setting Up the Production Environment with nginx instead of Apache =

# Follow instructions above until "Install Apache and Passenger", then continue here from step 2.
# Install passenger: <tt>$ gem install passenger</tt>
# Install nginx: <tt>$ passenger-install-nginx-module</tt>
## Notice: the default location is under <tt>/opt</tt>. If you wish to install there, use <tt>rvmsudo</tt>. Notice however, that part of your <tt>~/.rvm</tt> contents will then belong to root and may cause gray hair later. I chose to install under <tt>~/nginx</tt>.
Edit nginx configuration <tt>installation_path/conf/nginx.conf</tt>:
## Comment out section <tt>location / { ... }</tt>
## Add lines:
### <tt>passenger_enabled on;</tt>
### <tt>root /home/your_prod_env_user/qa-reports.meego.com/current/public;</tt>
# Start nginx: <tt>$ sudo /installation_path/sbin/nginx</tt>
# Continue with the guide above from "Deploying QA Reports"

Talk:Quality/QA-tools/QAReports/Admin FAQ

2011-06-21T07:49:39Z

Vesse: /* Multiple servers / load balancing */

== Multiple servers / load balancing ==
Sharing the whole <tt>shared</tt> folder breaks deployment as git checkout is updated from more than one servers at the same time, and this will cause file locking problems. Thus the actually needed folders need to be identified. [[User:Vesse|Vesse]] 07:49, 21 June 2011 (UTC)

Talk:Quality/QA-tools/QAReports/Admin FAQ

2011-06-21T07:49:13Z

Vesse: Created page with "== Multiple servers / load balancing == Sharing the whole <tt>shared</tt> folder breaks deployment as git checkout is updated from more than one servers at the same time, and thi..."

== Multiple servers / load balancing ==
Sharing the whole <tt>shared</tt> folder breaks deployment as git checkout is updated from more than one servers at the same time, and this will cause locking problems. Thus the actually needed folders need to be identified. [[User:Vesse|Vesse]] 07:49, 21 June 2011 (UTC)

Quality/QA-tools/QADashboard/Setting up the production environment

2011-06-21T07:37:09Z

Vesse: /* Install dependencies */ Changed the link from QA Reports to QA Dashboard

= Overview =

Running and deploying QA Dashboard relies heavily on automated deployment scripts and version control repository. At high level, deployment process is following:

# Log in to your workstation and update QA Dashboard working tree
# Run Capistrano deployment script on your workstation
# Capistrano script connects to the production server and updates the deployment by
## Connecting to version control system from production server and updating the source code on the production server
## Installing node package dependencies
## Restarting the application on production server

= Setting up the local environment for deployments =

QA Dashboard uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details

== Install development environment ==

You should first [http://wiki.meego.com/Quality/QA-tools/QADashboard/Setting_up_the_development_environment set up the development environment] on your workstation before continuing.
Capistrano is run from your development environment

== Installing Capistrano ==

Capistrano requires Ruby. If you do not have Ruby installed please follow the "Install Ruby" instructions [http://wiki.meego.com/Quality/QA-tools/QAReports/Setting_up_the_development_environment here].

<tt>$ gem install capistrano</tt>

= Setting up the production server =

== Install dependencies ==

The same dependencies are needed in the production server as in development environment.
Follow the instructions in [[Quality/QA-tools/QADashboard/Setting_up_the_development_environment]] to:
# Install Node.js
# Install Node Package Manager
# Install mongodb

== Create virtual host for QA Dashboard ==
(example using nginx)

Write a following virtual host declaration to /etc/nginx/sites-available/qa-dashboard

<code>
server {
listen 80;
server_name qa-dashboard.qa.leonidasoy.fi;
location / {
proxy_pass http://localhost:3030;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}
</code>

Restart nginx
<code>
sudo service nginx restart
</code>

= Deploying QA Dashboard =

== Enable public key authentication for your deployment account ==

Set up public key authentication:
# Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
# Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
# Try logging in: <tt>ssh your.production.user@your.production.host</tt>

== Modify Capistrano scripts and setup deployment ==

QA Dashboard uses following scripts to configure Capistrano
* <tt>config/deploy.rb</tt>
* <tt>config/deploy/staging.rb</tt>
* <tt>config/deploy/production.rb</tt>

You might want to review all the files, but usually it's enough to update only <tt>config/deploy/production.rb</tt> according to your needs (servers, deployment account, ssh options). You can also create new deployment environment just by copying the production.rb, to e.g. internal.rb and modify it.

When you deploy for first time you need to run setup command, which creates creates the folder hierarchy and the symbolic links required by Capistrano. 
Once the Capistrano is updated according to your needs you need to run setup command, which creates creates the folder hierarchy and the symbolic links required by Capistrano. After that the server can be started.
<code>
$ cap production deploy:setup # or cap internal deploy:setup, if you created a new deployment environment
$ cap production deploy:start # starts the server
</code>

== Deploying QA Dashboard ==

Once the setup is complete, the deployment is as easy as it gets
<code>
$ cap production deploy
</code>

Quality/QA-tools/QADashboard/Setting up the development environment

2011-04-19T11:01:42Z

Vesse: /* Install Node Package Manager */

==Introduction==

QA Dashboard is a [http://nodejs.org/ Node.js] application. It is written in [http://jashkenas.github.com/coffee-script/ coffee-script] and uses [http://www.mongodb.org/ mongodb] database. You need to install some awesome open source tools to get the development environment up and running.

==Install Node.js==
(uses v0.4.5 stable package)
#<tt> $ wget http://nodejs.org/dist/node-v0.4.5.tar.gz</tt>
#<tt> $ gunzip node-v0.4.5.tar.gz </tt>
#<tt> $ tar -xf node-v0.4.5.tar</tt>
#<tt> $ cd node-v0.4.5</tt>
#<tt> $ ./configure</tt>
#<tt> $ make</tt>
#<tt> $ sudo make install</tt>

==Install Node Package Manager==
(uses v1.0.1rc7 stable branch)
#<tt>$ git clone https://github.com/isaacs/npm.git</tt>
#<tt>$ cd npm</tt>
#<tt>$ git checkout v1.0.1rc7</tt>
#<tt>$ sudo make install</tt>

If your environment does not allow git protocol, make install will fail because of fetching the submodules. This can be fixed by changing the submodule URLs:
#<tt>$ git config submodule.node_modules/abbrev.url https://github.com/isaacs/abbrev-js.git</tt>
#<tt>$ git config submodule.node_modules/nopt.url https://github.com/isaacs/nopt.git</tt>
#<tt>$ git config submodule.node_modules/semver.url https://github.com/isaacs/node-semver.git</tt>

==Install mongodb==
#<tt> $ sudo apt-get install mongodb</tt>

==Set up QA Dashboard==
QA Dashboard repository includes a default mongodb dump which can be used to populate the database.
#<tt> $ cd qa-dashboard</tt>
#<tt> $ mongorestore</tt>

==Run the tests and start the server==
#Run unit tests:<tt> $ ./run-nodeunit.sh</tt>
#Start the server:<tt> $ ./run-server.sh</tt>
#Browse to http://localhost:3030

The server will start in development mode using node-supervisor, which watches for code changes and restarts the server accordingly.

Quality/QA-tools/QADashboard/Setting up the development environment

2011-04-19T10:23:28Z

Vesse: /* Install Node Package Manager */

==Introduction==

QA Dashboard is a [http://nodejs.org/ Node.js] application. It is written in [http://jashkenas.github.com/coffee-script/ coffee-script] and uses [http://www.mongodb.org/ mongodb] database. You need to install some awesome open source tools to get the development environment up and running.

==Install Node.js==
(uses v0.4.5 stable package)
#<tt> $ wget http://nodejs.org/dist/node-v0.4.5.tar.gz</tt>
#<tt> $ gunzip node-v0.4.5.tar.gz </tt>
#<tt> $ tar -xf node-v0.4.5.tar</tt>
#<tt> $ cd node-v0.4.5</tt>
#<tt> $ ./configure</tt>
#<tt> $ make</tt>
#<tt> $ sudo make install</tt>

==Install Node Package Manager==
(uses v1.0.1rc7 stable branch)
#<tt>$ git clone https://github.com/isaacs/npm.git</tt>
#<tt>$ cd npm</tt>
#<tt>$ git checkout v1.0.1rc7</tt>
#<tt>$ sudo make install</tt>

==Install mongodb==
#<tt> $ sudo apt-get install mongodb</tt>

==Set up QA Dashboard==
QA Dashboard repository includes a default mongodb dump which can be used to populate the database.
#<tt> $ cd qa-dashboard</tt>
#<tt> $ mongorestore</tt>

==Run the tests and start the server==
#Run unit tests:<tt> $ ./run-nodeunit.sh</tt>
#Start the server:<tt> $ ./run-server.sh</tt>
#Browse to http://localhost:3030

The server will start in development mode using node-supervisor, which watches for code changes and restarts the server accordingly.

Quality/QA-tools/QAReports/API

2011-04-11T07:46:58Z

Vesse: /* /api/import */ New import api parameters

= MeeGo QA Reports API =

MeeGo QA Reports have two [http://en.wikipedia.org/wiki/Representational_State_Transfer RESTful] HTTP API for programmatically importing test reports, and updating the test cases of a existed report.

Personal Authentication Token is required for operating with the API. The token can be fetched via QA Reports web UI, by clicking the user name link at the upper right center of the page while logged in.

[[File:Index.png|500px]]

The API key is shown at the bottom of the User Preferences page:

[[File:User_preferences.png|500px]]

== /api/import ==
Description: Import test results 
Method: POST [encoding multipart/form-data]

Parameters:
{| border="1" cellpadding="5" cellspacing="0"
|-
! Parameter name
! Description
! Values
|-
| auth_token
| Personal authentication token
|
|-
| release_version
| Release version
| 1.0, 1.1, 1.2
|-
| target
| Target profile
| Core, Handset, Netbook, IVI
|-
| testtype
| Test type
| Sanity, Acceptance, Basic Feature Testing etc
|-
| tested_at
| Timestamp of the test in format yyyy-mm-dd
| Optional. If not given, current date is used. Example value: 2010-12-14
|-
| hwproduct
| Hardware
| Ia-Russellville, N900, Pinetrail etc
|-
| report, report.[1..n]
| Report file in XML format
|
|-
| attachment, attachment.[1..n]
| Files to be attached with the report: Screenshots, logs etc
| Optional
|-
| title
| Report title
| Optional. Default: value generated from other information if user defined title is not given.
|-
| objective_txt
| Test objective. Web UI markup can be used.
| Optional. Default: value is set from previous report if it exists.
|-
| build_txt
| Build (image) section content. Web UI markup can be used.
| Optional. Default: value is set from previous report if it exists.
|-
| environment_txt
| Test environment. Web UI markup can be used.
| Optional. Default: hwproduct name
|-
| qa_summary_txt
| Quality summary. Web UI markup can be used.
| Optional. Default: value is set from previous report if it exists.
|-
| issue_summary_txt
| Issue summary. Web UI markup can be used.
| Optional. Default: value is set from previous report if it exists.
|}

The input can contain multiple ''report'' and ''attachment'' files. If multiple files are given, an unique field name have to be given for each file. Unique file names are created by giving a sequence number for each file starting from number 1, for example "attachment.1", "attachment.2" etc. If only on file is given, field can be used without sequence number, for example "attachment".

Because multiple files can be uploaded, HTTP POST with "[http://tools.ietf.org/html/rfc2388 multipart/form-encoding]" is used.

An example using [http://curl.haxx.se/Curl Curl] for testing the API:

<code>curl --form report.1=@sim.xml --form report.2=@bluetooth.xml --form attachment.1=coredump http://<server>/api/import?auth_token=<token>\&release_version=1.2\&target=Core\&testtype=Acceptance\&hwproduct=N900</code>

The operation results status code in [http://en.wikipedia.org/wiki/JSON JSON] format. If the operation proceeds successfully, key value pair "ok" = 1 is returned.

<code>{"ok":"1"}</code>

In case of error, ''ok'' values is 0, and an additional field ''errors'' describing the problem is returned

<code>{"ok":"0","errors":"unknown attribute: foobar"}</code>

== /api/update/<Report_ID> ==
Description: Update the test cases of a existed report 
Method: POST [encoding multipart/form-data]

Parameters:
{| border="1" cellpadding="5" cellspacing="0"
|-
! Parameter name
! Description
|-
| auth_token
| Personal authentication token
|-
| report, report.[1..n]
| Report file in XML or CSV format
|-
| Report_ID
| The ID of the target report
|}

The ID of the target report can be fetched from the URL of the corresponding report page, as shown in the picture below:

[[File:report_id.png|600px]]

The input can contain multiple ''report'' files. If multiple ''report'' files are given, an unique report name have to be given for each file. Unique file names are created by giving a sequence number for each file starting from number 1, for example "report.1", "report.2" etc. If only one file is given, field can be used without sequence number, for example "report".

Because multiple files can be uploaded, HTTP POST with "[http://tools.ietf.org/html/rfc2388 multipart/form-encoding]" is used.

An example using [http://curl.haxx.se/Curl Curl] for testing the API:

<code>curl --form report.1=@sim.xml --form report.2=@bluetooth.xml http://<Server_Domain_Name>/api/update/<Report_ID>?auth_token=<token></code>

The operation results status code in [http://en.wikipedia.org/wiki/JSON JSON] format. If the operation proceeds successfully, key value pair "ok" = 1 is returned.

<code>{"ok":"1"}</code>

In case of error, ''ok'' values is 0, and an additional field ''errors'' describing the problem is returned

<code>{"ok":"0","errors":"Request contained invalid files: ..."}</code>

Quality/QA-tools/QAReports/Setting up the production environment

2011-03-01T13:47:42Z

Vesse: /* Create a database for QA Reports */

= Overview =

Running and deploying QA Reports relies heavily on automated deployment scripts and version control repository. At high level, deployment process is following:

# Log in to your workstation and update QA Reports working tree
# Run Capistrano deployment script on your workstation
# Capistrano script connects to the production server and updates the deployment by
## Connecting to version control system from production server and updating the source code on the production server
## Running the migrations and updating the database schema on production server
## Restarting the application on production server

Capistrano enables you to automate also other administrative tasks like
# Rolling back to previous deployment
# Exporting data from production environment to your development environment

To achieve all the goodness, you should [[Quality/QA-tools/QAReports/Setting up the development environment|set up the development environment]] on your workstation before continuing.

= Setting up the production server =

This guide has been written for vanilla Ubuntu 10.04 installation. You need to be logged in to the production server and have sudo rights to continue.

== Install dependencies ==

<code>$ sudo aptitude install curl build-essential git-core openssh-server zlib1g-dev libssl-dev libreadline5-dev libcurl4-openssl-dev</code>

== Install Ruby ==

# Install [http://rvm.beginrescueend.com/ Ruby Version Manager] (using system-wide installation script) <code>$ sudo bash < <( curl -L http://bit.ly/rvm-install-system-wide )</code>
# Set up .bashrc as instructed by RVM installer: The whole content into an if section, and after that loading of RVM. Here's an example [http://gist.github.com/822216 .bashrc]
# Run: $ source ~/.bashrc
# Add your account and the deployment account to <code>rvm</code> group, e.g. <code>$ sudo adduser jakeskik rvm</code>
# Source your .bashrc to enable rvm <code>$ source ~/.bashrc</code>
# Install Ruby Enterprise Edition <code>$ rvm install ree</code>
# Set the default Ruby interpreter <code>$ rvm use --default ree</code>
# Install bundler <code>$ gem install rails bundler --no-ri --no-rdoc</code> #if you have proxy problem, plz refer to http://docs.rubygems.org/read/chapter/13#page51

Finally, enable rvm and Ruby Enterprise Edition to your deployment account, e.g. www-data

# Edit <code>/etc/passwd</code> and change <code>www-data</code>'s shell from <code>sh</code> to <code>bash</code>. You might want to change the home directory also from <code>/var/www</code> to e.g. <code>/home/www-data</code> as shown below <code>www-data:x:33:33:www-data:/home/www-data:/bin/bash</code>
# Enable RVM as shown below
<code>
$ sudo adduser www-data rvm
$ sudo -iu www-data
$ cp ~jakeskik/.profile .
$ cp ~jakeskik/.bashrc .
$ exit
</code>

== Install Apache and Phusion Passenger ==

<code>
$ sudo apt-get install apache2 apache2-prefork-dev libapr1-dev libaprutil1-dev
$ gem install passenger --no-ri --no-rdoc
$ rvmsudo passenger-install-apache2-module # Follow the on-screen instructions and edit apache.conf
$ sudo service apache2 restart
</code>

== Install MySQL ==

<code>
$ sudo apt-get install mysql-server libmysqlclient-dev
</code>

== Install Postfix ==

QA Reports sends email notifications for system administrators (you) in case the application throws an exception. To enable notifications, there needs to be a mail server configured on the production host.

<code>
$ sudo apt-get install postfix
</code>

The default configuration is fine and allows only delivery for emails originated from localhost. Just click through the installer.

== Test the environment ==

After installing the software, run a sanity check for the environment by creating a 'hello world' rails project and corresponding virtual host:

<code>
$ sudo -iu www-data
$ rails new hello
$ cd hello/public && pwd
/home/www-data/hello/public
$ exit
</code>

Write a following virtual host declaration to /etc/apache/sites-available/hello:

<code>
<VirtualHost *:80>
ServerName hello.qa.leonidasoy.fi
DocumentRoot /home/www-data/hello/public

<Directory /home/www-data/hello/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite hello
$ sudo service apache2 restart
</code>

Add the virtual host to <code>/etc/hosts</code> file:
<code>
127.0.0.1 hello.qa.leonidasoy.fi # Use the same domain as above
</code>

Now you should be able to access the 'hello world' project with a browser, e.g. lynx

<code>
$ lynx hello.qa.leonidasoy.fi
</code>

== Create a database for QA Reports ==

<code>
$ mysql -u root -p
mysql> create user 'qa-reports'@'localhost' identified by 'somepasswordofyourchoosing';
mysql> create database qa_reports_production character set 'utf8';
mysql> grant all privileges on qa_reports_production.* to 'qa-reports'@'localhost';
mysql> flush privileges;
mysql> exit
</code>

== Create virtual host for QA Reports ==

Write a following virtual host declaration to /etc/apache/sites-available/qa-reports:

<code>
<VirtualHost *:80>
ServerName qa-reports.qa.leonidasoy.fi
DocumentRoot /home/www-data/qa-reports.meego.com/current/public

<Directory /home/www-data/qa-reports.meego.com/current/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
</code>

Enable the virtual host
<code>
$ sudo a2ensite qa-reports
$ sudo service apache2 restart # Don't mind the warning about missing dir,
# we'll deal with that one in a sec
</code>

= Deploying QA Reports =

QA Reports uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details.

Capistrano is run from your development environment, so you should be now on your workstation with working QA Reports development environment to continue.

== Enable public key authentication for your deployment account ==

Set up public key authentication:
# Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
# Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
# Try logging in: <tt>ssh your.production.user@your.production.host</tt>

== Modify Capistrano scripts and deploy QA Reports ==

QA Reports uses following scripts to configure Capistrano
* <tt>config/deploy.rb</tt>
* <tt>config/deploy/staging.rb</tt>
* <tt>config/deploy/production.rb</tt>

You might want to review all the files, but usually it's enough to update only <tt>config/deploy/production.rb</tt> according to your needs (servers, deployment account, ssh options). You can also create new deployment environment just by copying the production.rb, to e.g. internal.rb and modify it.

Once the Capistrano is updated according to your needs, run
<code>
$ cap production deploy:setup # or cap internal deploy:setup, if you created a new deployment environment
</code>

Setup command creates the folder hierarchy and the symbolic links required by Capistrano. During the setup it requests following information
# Database host
# Database port
# Database name
# Database username
# Database password
# Should QA Reports send performance data to [http://newrelic.com NewRelic]? (Default: no)
# Registration token. This will be part of the registration url, e.g. <tt>foobar</tt> will make registration to be at url <tt>/users/foobar/register</tt>
# Email addresses for Exception Notifier

Once the setup is complete, the deployment is as easy as it gets
<code>
$ cap production deploy:migrations
</code>

You should now have QA Reports up&running. Congrats!

== Update QA Reports to a new version ==

# <code>git pull</code> (In case there's changes in the deployment scripts)
# <code>cap production deploy:migrations</code>
# Ta-da!

== Roll back to previous version ==

# <code>cap production deploy:rollback</code>
# Ta-da!

= Setting Up the Production Environment with nginx instead of Apache =

# Follow instructions above until "Install Apache and Passenger", then continue here from step 2.
# Install passenger: <tt>$ gem install passenger</tt>
# Install nginx: <tt>$ passenger-install-nginx-module</tt>
## Notice: the default location is under <tt>/opt</tt>. If you wish to install there, use <tt>rvmsudo</tt>. Notice however, that part of your <tt>~/.rvm</tt> contents will then belong to root and may cause gray hair later. I chose to install under <tt>~/nginx</tt>.
Edit nginx configuration <tt>installation_path/conf/nginx.conf</tt>:
## Comment out section <tt>location / { ... }</tt>
## Add lines:
### <tt>passenger_enabled on;</tt>
### <tt>root /home/your_prod_env_user/qa-reports.meego.com/current/public;</tt>
# Start nginx: <tt>$ sudo /installation_path/sbin/nginx</tt>
# Continue with the guide above from "Deploying QA Reports"

Quality/QA-tools/Eat

2011-01-26T05:40:26Z

Vesse: Removed the nowadays non-existing package eat-syslog-host

= Eat - Enable(s) Automated Testing =

Eat is a set of packages that are used to configure your environment for automated testing. The packages are

* eat-device
* eat-host
* eat-syslog-device
* eat-selftest

== eat-device ==
This package is installed to the device under test, it puts the test control pc's ssh-key (the one in eat-host) to the device's authorized ssh-keys list to enable passwordless logins using ssh.

== eat-host ==
This package is installed to the test control pc. It installs the ssh-key to the test control pc as well as testrunner-lite and test-definition as it's dependencies. eat-host also enables receiving syslogs from the device under test.

== eat-syslog-device ==
Triggers sending of device syslogs to test control PC.

== eat-selftest ==
This package installs an init script to the device under test that runs all test packages found in the device at boot time. The package also installs testrunner-lite and test-definition as it's dependencies.

Quality/QA-tools/QAReports/Setting up the production environment

2011-01-21T03:59:57Z

Vesse: Step by step instructions added

= Setting up the environment =

# Install [http://www.rubyenterpriseedition.com/ Ruby Enterprise Edition]
# Install and configure web server ([http://nginx.org/ nginx] or [http://httpd.apache.org/ Apache] recommended)
# Install [http://www.modrails.com/ Phusion Passenger]
# Install MySQL [http://www.mysql.com/ MySQL]

After installing the software, run a sanity check for the environment by creating a 'hello world' rails project and corresponding virtual host:

<code>
jakeskik@staging:~$ rails new hello
jakeskik@staging:~$ cd hello/public && pwd
/home/jakeskik/hello/public
</code>

Example nginx virtual host configuration:

<code>
server {
listen 80;
server_name hello.qa.leonidasoy.fi;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
root /home/jakeskik/hello/public;
passenger_enabled on;
rails_env production #or staging, if you want to run in staging env
}
</code>

Add the new virtual host to /etc/hosts:

<code>
178.79.128.101 hello.qa.leonidasoy.fi
</code>

After restarting the web server, you should be able to access the 'hello world' project with a browser, e.g. lynx

<code>
jakeskik@staging:~$ lynx hello.qa.leonidasoy.fi
</code>

= Deploying MeeGo QA Reports =

QA Reports uses Capistrano to automate the deployments. The main benefit is to eliminate the risks of human errors and to enable easy and repeatable rollbacks. See [http://github.com/capistrano/capistrano/wiki Capistrano documentation] for the details.

== Setting up Capistrano on a new server ==

# Setup development environment on your workstation as described in [[Quality/QA-tools/QAReports/Setting_up_the_development_environment|Setting up a development environment]]
# Reserve a (sub)domain name for QA Reports and create a corresponding DNS entry
# Setup ruby, Passenger, MySQL, nginx/Apache and virtual host on production server as described above
# Create MySQL account and database on the production server. Make sure they match with <code>config/database.yml</code>
# Modify <code>config/deploy/staging.rb</code> and/or <code>config/deploy/production.rb</code> to match your configuration. Capistrano scripts are executed locally on your workstation and can be tested before checking to version control.
# Setup public key authentication so that you can access the deployment account from your workstation
# Run <code>cap [staging|production] deploy:setup</code>. The command defaults to staging. Setup command creates the folder hierarchy and the symbolic links required by Capistrano.
# Follow the steps in "Updating QA Reports to a new version"

Once the tool chain and the environment is up and running, the rest is very straight forward.

== Updating QA Reports to a new version ==

# <code>git pull</code> (In case there's changes in the deployment scripts)
# <code>cap [staging|production] deploy:migrations</code>
# Ta-da!

== Rolling back to previous version ==

# <code>cap [staging|production] deploy:rollback</code>
# Ta-da!

= Step-by-Step Instructions =

These instructions are written based on what I had to do to get QA reports up and running. I had a clean Kubuntu 10.04 installation to start with, and as this was for demonstration purposes the same computer was acting as Production Environment and Development Environment, but under different user accounts.

== Setting Up the Production Environment ==
# Install some packages: <tt>$ sudo aptitude install curl build-essential git-core mysql-server openssh-server zlib1g-dev libssl-dev libreadline5-dev libcurl4-openssl-dev</tt>
# Create a MySQL database user and the database:
## <tt>mysql -u root -p</tt>
## <tt>create user 'meego-qa'@'localhost' identified by 'somepasswordofyourchoosing';</tt>
## <tt>create database qa_reports_production character set 'utf8';</tt>
## <tt>grant all privileges on qa_reports_production.* to 'meego-qa'@'localhost';</tt>
## <tt>flush privileges;</tt>
## <tt>quit;</tt>
# Install RVM: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
## Set up <tt>.bashrc</tt> as instructed by RVM installer: The whole content into an if section, and after that loading of RVM.
## Run: <tt>$ source ~/.bashrc</tt>
# Install Ruby Enterprise Edition: <tt>$ rvm install ree</tt>
# Use it as default: <tt>$ rvm --default use ree</tt>
# Install bundler: <tt>$ gem install bundler</tt>
# Install passenger: <tt>$ gem install passenger</tt>
# Install nginx: <tt>$ passenger-install-nginx-module</tt>
## Notice: the default location is under <tt>/opt</tt>. If you wish to install there, use <tt>rvmsudo</tt>. Notice however, that part of your <tt>~/.rvm</tt> contents will then belong to root and may cause gray hair later. I chose to install under <tt>~/nginx</tt>.
# At this point, jump to [[#Setting Up the Development Environment|Development Environment section]], set it up and deploy QA Reports
# Once deployed correctly, edit nginx configuration <tt>installation_path/conf/nginx.conf</tt>:
## Comment out section <tt>location / { ... }</tt>
## Add lines:
### <tt>passenger_enabled on;</tt>
### <tt>root /home/your_prod_env_user/qa-reports.meego.com/current/public;</tt>
# Create file <tt>/home/your_prod_env_user/qa-reports.meego.com/shared/config/registeration_token</tt> and add some string in it. This will be part of the registration url, e.g. <tt>foobar</tt> will make registration to be at url <tt>/users/foobar/register</tt>
# Start nginx: <tt>$ sudo /installation_path/sbin/nginx</tt>
# Head to the server address with your web browser and hopefully see QA Reports running

== Setting Up the Development Environment ==
# Set up public key authentication:
## Generate yourself as SSH key pair if you don't have one: <tt>$ ssh-keygen</tt>
## Add your public key to <tt>authorized_keys</tt> file of your production environment user: <tt>$ ssh your.production.user@your.production.host 'mkdir .ssh; echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys'</tt>
## Try logging in: <tt>ssh your.production.user@your.production.host</tt>
# Set up development environment as described [[Quality/QA-tools/QAReports/Setting up the development environment|here]]
## Notice: Just run <tt>$ bundle install</tt> without flags and stop there, no need to set up database or anything
# Edit your settings based on your production environment setup:
## <tt>config/deploy/production.rb</tt>: set the correct user and host information (mysql, ssh, host)
## <tt>config/deploy/database.yml.erb</tt>: set up MySQL user and database information
# Deploy:
## <tt>$ cap production deploy:setup</tt>
## <tt>$ cap production deploy:migrations</tt>
## Run again - there's something fishy in the DB setup: <tt>$ cap production deploy:migrations</tt>
# Now head back to [[#continuepoint|Production Environment]] to finalize the setup

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-21T03:33:17Z

Vesse: /* Set up QA Reports */ Rack fixed in git, no need to install manually

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-19T06:11:28Z

Vesse: /* Set up QA Reports */ And more dependencies...

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev libxml2-dev libxslt1-dev libsqlite3-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)
# Install gem <tt>rack</tt> to get what's needed to be able to use the git version: <tt>$ gem install rack</tt>

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-19T06:02:42Z

Vesse: /* Set up QA Reports */ Rack installation manually first makes qa-reports bundling work, it seems

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-19T05:58:14Z

Vesse: /* Set up QA Reports */ More dependencies are needed to get gems installed

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev libxml2-dev libxslt1-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)
# Check <tt>qa-reports/Gemfile</tt>
## If there's a line <tt>gem 'rack', :git => "git://github.com/rack/rack.git"</tt>, change it to <tt>gem 'rack', '1.2.1'</tt>
## Apparently the dependencies are not installed with the git approach which will lead into server starting failure

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
## If you had to edit the Gemfile, you can now change it back the way it was and run the <tt>bundle</tt> command again to make it use the version in git (if that's needed)
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>

Quality/QA-tools

2011-01-06T09:30:11Z

Vesse: /* Tools and Maintainers */ And mnts back, repo at meego.gitorious.org did not have anything in it

= Quality Assurance (QA) Tools =

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for Quality Assurance.

Open source tools – available for all, available for development and contributions. Make people accountable for quality.

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://meego.gitorious.org/meego-quality-assurance/ git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Currently test reports are published manually to wiki
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools weekly meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Gitorious'''||'''Maintainer''' ||'''Substitute'''
|-
| [[Quality/QA-tools/Test-definition|test-definition]]||[http://meego.gitorious.org/meego-quality-assurance/test-definition Gitorious] || Sampo Saaristo || Timo Härkönen
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||[http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Gitorious] || Sampo Saaristo || Kyösti Ranto
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || [http://meego.gitorious.org/meego-quality-assurance/testrunner Gitorious] || Kyösti Ranto || Timo Härkönen
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] ||[http://meego.gitorious.org/meego-quality-assurance/testplanner Gitorious] || Kyösti Ranto || N/A
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] ||[http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing Gitorious] || Timo Härkönen || Timo Mäkimattila
|-
| [[Quality/QA-tools/OTS|ots - open testing system]] ||[http://meego.gitorious.org/meego-quality-assurance/ots Gitorious] || Teemu Vainio || Tom Galvin
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||[http://gitorious.org/qa-tools/meego-ai Gitorious] || Timo Härkönen || N/A
|-
| [[Quality/TestSuite/MCTS|MeeGo Core Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mcts/ Gitorious] ||Matti Salmi || Jeff Zheng
|-
| [[Quality/Netbook Test Suite and Utilities|MeeGo Netbook Test Suite]] || [http://gitorious.org/qa-tools/mnts/ Gitorious] ||Jeff Zheng || N/A
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] || [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Gitorious] || Riku Halonen || N/A
|-
| [[Quality/QA-tools/Min|MIN test framework]] || [http://meego.gitorious.org/meego-quality-assurance/min Gitorious] || Sampo Saaristo || Timo Mäkimattila
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || [http://gitorious.org/TDriver Gitorious] || Petri Kiiskinen || Tatu Lahtela
|-
| Rich Core dumper || [http://meego.gitorious.org/meego-quality-assurance/rich-core Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter settings || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter-settings-public Gitorious] || Carol Rus || Raimo Gratseff
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] || [http://meego.gitorious.org/meego-quality-assurance/hat-control Gitorious] || Marko Junttila || Riku Halonen
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || [http://meego.gitorious.org/meego-quality-assurance/qa-reports Gitorious] || Sami Hangaslammi || Jarno Keskikangas
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] || [http://meego.gitorious.com/meego-quality-assurance/scripts-and-utils Gitorious] || N/A || N/A
|-
| [[Quality/TestSuite/handset-test-suite/handset-ux-test_Releases | handset_ux_tests]] || [http://meego.gitorious.com/meego-quality-assurance/handset-ux-tests Gitorious] || JessicaJi || N/A
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] || [http://meego.gitorious.org/meego-quality-assurance/meego-testing-hudson-plugin Gitorious] || Alexey Kuznetsov || Timo Härkönen
|-
| Service OS based Flasher || [http://meego.gitorious.org/meego-quality-assurance/meego-ai-serviceos Gitorious] || Jing Wang || N/A
|}

You can install Testrunner UI, testrunner-lite, Testplanner, OTS, Meego-ai and eat from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

See the rest of our team members and our collaboration spaces [[Quality/QA-tools#Team_Members_and_Collaboration_Spaces|below]]. If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

=== Overview ===

The figure below tries to summarize the relations and tasks of the tools when used in test automation context.

[[File:testautomationtools.png]]

xfig file:[[File:qatools.fig]]

== Release Practices ==

Here's the workflow for QA-tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file:
[[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to tools:testing and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management. (If the package belongs to both repositories, we let the Release Management set bugs fixed by the package to RELEASED state).
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not. (Follow meego-packaging and meego-commits.)

If you shoot a video to YouTube, promote it on meego-qa mailing list!

''' YouTube videos '''

YouTube is a good way to communicate new features. You can find existing demo videos on [http://www.youtube.com/user/meegoqatools meegoqatools channel on Youtube].

If you shoot a video to YouTube, promote it on meego-qa mailing list!

You can find some hints how to shoot, edit, and upload a video here: [[YouTube_Hints]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Features and Bugs ==
Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Projects&product=Meego%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla workflow: [[Bugzilla/how-report-bugs]]

== Documentation ==

This section will contain links to various guides and user documentation. See [[Quality/QA-tools#Tools_and_Maintainers|the wiki pages of the tools]] for tool-specific documentation.

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]
* [[Quality/QA-tools/How_to_set_up_repositories|How to set up the repositories that are needed to install QA tools]]

== Design/ Planning ==

* [[Quality/QA-tools/MCTS test automation design|MCTS Test Automation]] (QA Tools support for MCTS) '''WORK IN PROGRESS'''

== Meetings ==

All meetings will be held in <code>#meego-meeting</code> on <code>irc.freenode.net</code>.

=== Team meetings ===

QA tools team meetings will be held on need basis for specific topics. This was agreed in [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-07-11.59.html the last weekly meeting held on December 7th 2010]

* [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

=== Architecture meetings ===

Architecture meetings will be held on-demand basis i.e. when topics do not fit in QA-Tools weekly meeting time frame.

* [[Quality/QA-tools/Arch-Meetings|Meeting agendas and minutes]]

=== Workshops ===

Face-2-face meetings within the team.

* [[Quality/QA-tools/Workshops|Meeting agendas and minutes]]

== Team Members and Collaboration Spaces==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Ville Ilvonen || Team lead (act.) || Nokia || vilvo
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Arto Sinnelä || Team member || Digia || asinnela
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Esa-Pekka Miettinen || Team member || Digia || E-P
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Alexey Kuznetsov || Team member || Digia || alkuznet
|-
| Sergey Timofeev || Team member || Digia || setimofe
|-
| Daniil Chuiko || Team member || Digia || dachuiko
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Teemu Vainio || Team member || Ixonos || tvainio
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Tom Galvin || Team member || Ixonos || -
|-
| Jarno Keskikangas || Team member || Leonidas || jakeskik
|-
| Janne Hietamäki || Team member || Leonidas || _janne
|-
| Sami Hangaslammi || Team member || Leonidas || sahangas
|-
|}

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa-tools #meego-qa-tools IRC channel on irc.freenode.net]
** [http://timoph.fi/qa-tools-stats/ #meego-qa-tools statistics]
** [http://timoph.fi/qa-tools-logs/ #meego-qa-tools irc logs]
* Gitorious team, http://meego.gitorious.org/meego-quality-assurance/
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

[[Category:QA]]

Quality/QA-tools

2011-01-06T09:23:36Z

Vesse: /* Tools and Maintainers */ Updated mcts and mnts

= Quality Assurance (QA) Tools =

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for Quality Assurance.

Open source tools – available for all, available for development and contributions. Make people accountable for quality.

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://meego.gitorious.org/meego-quality-assurance/ git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Currently test reports are published manually to wiki
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools weekly meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to wiki page)''' ||'''Gitorious'''||'''Maintainer''' ||'''Substitute'''
|-
| [[Quality/QA-tools/Test-definition|test-definition]]||[http://meego.gitorious.org/meego-quality-assurance/test-definition Gitorious] || Sampo Saaristo || Timo Härkönen
|-
| [[Quality/QA-tools/Testrunner-lite|testrunner-lite]] ||[http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Gitorious] || Sampo Saaristo || Kyösti Ranto
|-
| [[Quality/QA-tools/Testrunner|Testrunner]] || [http://meego.gitorious.org/meego-quality-assurance/testrunner Gitorious] || Kyösti Ranto || Timo Härkönen
|-
| [[Quality/QA-tools/Testplanner|Testplanner]] ||[http://meego.gitorious.org/meego-quality-assurance/testplanner Gitorious] || Kyösti Ranto || N/A
|-
| [[Quality/QA-tools/Eat|eat - enables automated testing]] ||[http://meego.gitorious.org/meego-quality-assurance/enables-automated-testing Gitorious] || Timo Härkönen || Timo Mäkimattila
|-
| [[Quality/QA-tools/OTS|ots - open testing system]] ||[http://meego.gitorious.org/meego-quality-assurance/ots Gitorious] || Teemu Vainio || Tom Galvin
|-
| [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|MeeGo Automated installer]] ||[http://gitorious.org/qa-tools/meego-ai Gitorious] || Timo Härkönen || N/A
|-
| [[Quality/TestSuite/MCTS|MeeGo Core Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mcts/ Gitorious] ||Matti Salmi || Jeff Zheng
|-
| [[Quality/Netbook Test Suite and Utilities|MeeGo Netbook Test Suite]] || [http://meego.gitorious.org/meego-quality-assurance/mnts/ Gitorious] ||Jeff Zheng || N/A
|-
| [[Quality/QA-tools/qtuitest-mbt-adapter|Model-Based Testing adapter for qtuitest]] || [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Gitorious] || Riku Halonen || N/A
|-
| [[Quality/QA-tools/Min|MIN test framework]] || [http://meego.gitorious.org/meego-quality-assurance/min Gitorious] || Sampo Saaristo || Timo Mäkimattila
|-
| [[Quality/QA-tools/TDriver|Testability Driver]] || [http://gitorious.org/TDriver Gitorious] || Petri Kiiskinen || Tatu Lahtela
|-
| Rich Core dumper || [http://meego.gitorious.org/meego-quality-assurance/rich-core Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter Gitorious] || Carol Rus || Raimo Gratseff
|-
| Crash Reporter settings || [http://meego.gitorious.org/meego-quality-assurance/crash-reporter-settings-public Gitorious] || Carol Rus || Raimo Gratseff
|-
| [[Quality/QA-tools/hat-control|Hardware Accessory for Testing (HAT)]] || [http://meego.gitorious.org/meego-quality-assurance/hat-control Gitorious] || Marko Junttila || Riku Halonen
|-
| [[Quality/QA-tools/QAReports|QA Reports]] || [http://meego.gitorious.org/meego-quality-assurance/qa-reports Gitorious] || Sami Hangaslammi || Jarno Keskikangas
|-
| [[Quality/QA-tools/Scripts_and_utils|Scripts and utils]] || [http://meego.gitorious.com/meego-quality-assurance/scripts-and-utils Gitorious] || N/A || N/A
|-
| [[Quality/TestSuite/handset-test-suite/handset-ux-test_Releases | handset_ux_tests]] || [http://meego.gitorious.com/meego-quality-assurance/handset-ux-tests Gitorious] || JessicaJi || N/A
|-
| [[Quality/QA-tools/MeeGo_Fast_Feedback_Testing|MeeGo Fast Feedback Testing (MeeGo-FFT)]] || [http://meego.gitorious.org/meego-quality-assurance/meego-testing-hudson-plugin Gitorious] || Alexey Kuznetsov || Timo Härkönen
|-
| Service OS based Flasher || [http://meego.gitorious.org/meego-quality-assurance/meego-ai-serviceos Gitorious] || Jing Wang || N/A
|}

You can install Testrunner UI, testrunner-lite, Testplanner, OTS, Meego-ai and eat from Tools:Testing repository. The instructions for setting up the repositories can be found [[Quality/QA-tools/How_to_set_up_repositories|here]].

See the rest of our team members and our collaboration spaces [[Quality/QA-tools#Team_Members_and_Collaboration_Spaces|below]]. If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

=== Overview ===

The figure below tries to summarize the relations and tasks of the tools when used in test automation context.

[[File:testautomationtools.png]]

xfig file:[[File:qatools.fig]]

== Release Practices ==

Here's the workflow for QA-tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file:
[[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to tools:testing and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management. (If the package belongs to both repositories, we let the Release Management set bugs fixed by the package to RELEASED state).
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not. (Follow meego-packaging and meego-commits.)

If you shoot a video to YouTube, promote it on meego-qa mailing list!

''' YouTube videos '''

YouTube is a good way to communicate new features. You can find existing demo videos on [http://www.youtube.com/user/meegoqatools meegoqatools channel on Youtube].

If you shoot a video to YouTube, promote it on meego-qa mailing list!

You can find some hints how to shoot, edit, and upload a video here: [[YouTube_Hints]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Features and Bugs ==
Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Projects&product=Meego%20Quality%20Assurance Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Projects&product=MeeGo%20Quality%20Assurance All open features and bugs in priority order]

Bugzilla workflow: [[Bugzilla/how-report-bugs]]

== Documentation ==

This section will contain links to various guides and user documentation. See [[Quality/QA-tools#Tools_and_Maintainers|the wiki pages of the tools]] for tool-specific documentation.

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]
* [[Quality/QA-tools/How_to_set_up_repositories|How to set up the repositories that are needed to install QA tools]]

== Design/ Planning ==

* [[Quality/QA-tools/MCTS test automation design|MCTS Test Automation]] (QA Tools support for MCTS) '''WORK IN PROGRESS'''

== Meetings ==

All meetings will be held in <code>#meego-meeting</code> on <code>irc.freenode.net</code>.

=== Team meetings ===

QA tools team meetings will be held on need basis for specific topics. This was agreed in [http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-12-07-11.59.html the last weekly meeting held on December 7th 2010]

* [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

=== Architecture meetings ===

Architecture meetings will be held on-demand basis i.e. when topics do not fit in QA-Tools weekly meeting time frame.

* [[Quality/QA-tools/Arch-Meetings|Meeting agendas and minutes]]

=== Workshops ===

Face-2-face meetings within the team.

* [[Quality/QA-tools/Workshops|Meeting agendas and minutes]]

== Team Members and Collaboration Spaces==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Ville Ilvonen || Team lead (act.) || Nokia || vilvo
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Arto Sinnelä || Team member || Digia || asinnela
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Esa-Pekka Miettinen || Team member || Digia || E-P
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Alexey Kuznetsov || Team member || Digia || alkuznet
|-
| Sergey Timofeev || Team member || Digia || setimofe
|-
| Daniil Chuiko || Team member || Digia || dachuiko
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Teemu Vainio || Team member || Ixonos || tvainio
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Tom Galvin || Team member || Ixonos || -
|-
| Jarno Keskikangas || Team member || Leonidas || jakeskik
|-
| Janne Hietamäki || Team member || Leonidas || _janne
|-
| Sami Hangaslammi || Team member || Leonidas || sahangas
|-
|}

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa-tools #meego-qa-tools IRC channel on irc.freenode.net]
** [http://timoph.fi/qa-tools-stats/ #meego-qa-tools statistics]
** [http://timoph.fi/qa-tools-logs/ #meego-qa-tools irc logs]
* Gitorious team, http://meego.gitorious.org/meego-quality-assurance/
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* [http://meegoqatools.wordpress.com/ QA-tools team blog]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

[[Category:QA]]

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-04T07:24:17Z

Vesse:

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)
# Check <tt>qa-reports/Gemfile</tt>
## If there's a line <tt>gem 'rack', :git => "git://github.com/rack/rack.git"</tt>, change it to <tt>gem 'rack', '1.2.1'</tt>
## Apparently the dependencies are not installed with the git approach which will lead into server starting failure

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
## If you had to edit the Gemfile, you can now change it back the way it was and run the <tt>bundle</tt> command again to make it use the version in git (if that's needed)
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-04T07:23:56Z

Vesse:

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)
# Check <tt>qa-reports/Gemfile</tt>
## If there's a line <tt>gem 'rack', :git => "git://github.com/rack/rack.git"</tt>, change it to <tt>gem 'rack', '1.2.1'</tt>
## Apparently the dependencies are not installed with the git approach which will lead into server starting failure

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
## If you had to edit the Gemfile, you can now change it back the way it was and run the <tt>bundle</tt> command again to make it use the version in git (if that's needed)
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>
## And see it fail due to problems with <tt>RubyGem rack</tt>

Quality/QA-tools/QAReports/Setting up the development environment

2011-01-04T06:52:14Z

Vesse:

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>
## And see it fail due to problems with <tt>RubyGem rack</tt>

'''TODO:''' Fix the gem "rack" issue. Currently during bundling output like this is produced:
Using rack (1.2.1) from git://github.com/rack/rack.git (at master)
rack at /home/poikajar/.rvm/gems/ruby-1.8.7-p330/bundler/gems/rack-672396f0fdaa did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
["SPEC"] are not files

The above seems to be related to this [https://github.com/rack/rack/pull/73 issue] which should've been solved. If editing rubygems manually from that path bundler does not complain but still the result is the same when trying to start the server.

And when trying to start the server the output is:
/home/poikajar/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:812:in `report_activate_error':
Could not find RubyGem rack (~> 1.2.1) (Gem::LoadError)

Quality/QA-tools/QAReports/Setting up the development environment

2010-12-31T10:39:55Z

Vesse: /* Set up QA Reports */

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>
## And see it fail due to problems with <tt>RubyGem rack</tt>

'''TODO:''' Fix the gem "rack" issue. Currently during bundling output like this is produced:
Using rack (1.2.1) from git://github.com/rack/rack.git (at master)
rack at /home/poikajar/.rvm/gems/ruby-1.8.7-p330/bundler/gems/rack-672396f0fdaa did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
["SPEC"] are not files

And when trying to start the server the output is:
/home/poikajar/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:812:in `report_activate_error':
Could not find RubyGem rack (~> 1.2.1) (Gem::LoadError)

Quality/QA-tools/QAReports/Setting up the development environment

2010-12-31T10:00:05Z

Vesse: /* Set up QA Reports */

==Introduction==

QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in installation on Ubuntu 10.10

==Installing Ruby==

Most likely you won't succeed with the packaged version of Ruby. Thus this guide uses [http://rvm.beginrescueend.com/ Ruby Version Manager (rvm)].

# Install dependencies: <tt>$ sudo apt-get install git-core curl</tt>
# Install rvm: <tt>$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )</tt>
# Follow the instructions printed once installation is ready
## Install needed packages - check section ''"For Ruby (MRI & ree) you should install the following OS dependencies"''
## Enable loading of rvm - check section ''"You must now complete the install by loading RVM in new shells"''
### Edit <tt>.bashrc</tt> as described
### Restart your shell to have rvm enabled
# Install Ruby: <tt>$ rvm install 1.8.7</tt>
# Set into use: <tt>$ rvm use 1.8.7</tt>

==Set up QA Reports==

# Clone qa-reports from git: <tt>$ git clone git://gitorious.org/meego-quality-assurance/qa-reports.git</tt>
# Install preqrequisites: <tt>$ sudo apt-get install libmysqlclient-dev</tt>
# Create database config to <tt>qa-reports/config/database.yml</tt> (example exists by name <tt>database.example.yml</tt>)

Follow the instructions then from <tt>qa-reports/README.creole</tt>:
# <tt>$ gem update --system</tt>
## Note: if you get an error about <tt>zlib</tt>, follow [http://rvm.beginrescueend.com/packages/zlib/ these] instructions
# <tt>$ gem install bundler --no-ri --no-rdoc</tt>
# <tt>$ bundle install --without staging production</tt>
# <tt>$ rake db:create</tt>
# <tt>$ rake db:migrate</tt>
## Failed, but after rerun worked
# Start the server: <tt>$ rails server</tt>
## And see it fail due to problems with <tt>RubyGem rack</tt>

'''TODO:''' Fix the gem "rack" issue. Currently during bundling output like this is produced:
Using rack (1.2.1) from git://github.com/rack/rack.git (at master)
rack at /home/poikajar/.rvm/gems/ruby-1.8.7-p330/bundler/gems/rack-672396f0fdaa did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
["SPEC"] are not files

And when trying to start the server the output is:
/home/poikajar/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/site_ruby/1.8/rubygems.rb:812:in `report_activate_error':
Could not find RubyGem rack (~> 1.2.1) (Gem::LoadError)

Quality/QA-tools/QAReports/Setting up the development environment

2010-12-31T09:52:08Z

Vesse: /* Set up QA Reports */

Quality/QA-tools/QAReports/Setting up the development environment

2010-12-31T09:51:39Z

Vesse: Created page with "==Introduction== QA Reports is a Ruby on Rails application so you need to install a bunch of stuff to get it up and running. This draft documentation is based on experiences in …"

Quality/QA-tools/Scripts and utils

2010-12-17T04:46:01Z

Vesse: Added tests2html documentation

= Scripts and utils =

== mtdv ==

=== Introduction ===

''MIN Test Definition Validator''

Simple tool for validating test definition test case names with regular expression and also for checking that test definition includes all test cases which are defined in the MIN scripter files.

=== Usage ===

Validate tests.xml file(s)

mtdv -s /usr/share/test-definition/testdefinition-syntax.xsd -x tests.xml -x tests2.xml

Validate only tests.xml test case name(s)

mtdv -r "[S]" -x tests.xml -x tests2.xml

Validate MIN script test case name(s)

mtdv -r "[S]" -m /usr/lib/min/

Compare test tests.xml case list to MIN test case list and validate all test cases

mtdv -s /usr/share/test-definition/testdefinition-syntax.xsd -x tests.xml -m /usr/lib/min/ -r "[S]"

== tests2html ==

=== Introduction ===

Tool for generating HTML documentation from test plans validating against [[Quality/QA-tools/Test-definition|test-definition]]. The tool pulls projects from gitorious, locates test XML files and creates the HTML documentation. Currently used at http://testplans.meego.com

=== Usage ===

Tool configuration is in <tt>/etc/tests2html/tests2html.ini</tt> where you define the git projects and a couple of other settings. The projects are cloned under <tt>/var/tmp/tests2html</tt>. The main idea is to run with cron, and the cron script is <tt>/etc/cron.hourly/tests2html</tt>. You need to enable that after you've configured the tool. Logger prints messages to stdout.

When running from command line you have the following command line options available:
-h, --help Display the help
-v, --verbose Set log level to DEBUG
-o, --offline Don't do anything with git. You need to run once
without this flag to get the projects, but after
that using offline mode makes debugging easier

Quality/QA-tools/Autotest-guide

2010-11-19T10:15:49Z

Vesse: /* Creating test images */

= Introduction =
This guide gives a walk through of the steps needed to automate testing in MeeGo. The guide is updated when automated testing solutions are updated or new parts for the system are taken into use so make sure to check the guide for updates every now and then.

The current automated testing solution offers two different ways to execute the tests, from host pc through ssh or on the device under test itself. OTS uses host based testing to execute the tests. On device testing is meant to be used with manual testing and in special cases where host based testing is not an feasible option.

For information about the tools used with test automation see [[Quality/QA-tools#Tools and Maintainers|QA-tools and maintainers]].

== Feedback ==
Feel free to contribute and improve this guide. For questions and/or feedback about it pop by #meego-qa-tools at freenode or use [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list].

= Writing tests =

== Test plan ==
Test plan is a XML file that contains your test suites, cases and steps. The basic principle of test plan XML and tool support is that you can use 'any' executable for testing.

For more information on writing test plan XMLs see [[Quality/QA-tools/Test plan|Test plan]] page in this wiki.

== Test packaging ==

Test packaging is intended to provide flexible and consistent ways to run tests and get results. You may select testing tools of your choice.

Test packaging is set of simple rules to wrap tests with test plan inside rpm package. Tool support for validating test plan and automating test plan execution is provided with testrunner. Following describes rpm-version of test packaging.

A source package with test cases must:

* build binary rpm package with name which ends with "<code>-tests</code>" (this is a test package)

A test package must:

* contain all tests, scripts and configuration files required to run tests
* define dependencies - the ones it tests and the test tools it depends on (if any)
* contain a test plan located at <code>/usr/share/<packagename>-tests/tests.xml</code> [1]

For more information on creating test packages, see [[Quality/QA-tools/Test package|Test package]] page in this wiki.

= Creating test images =
To perform automated testing you need to [[Image Creation|create images]] that contain test automation enablers and the tests. You can create two types of test images depending on how tests are planned to be executed. Instructions for image creation are [[Image Creation|here]] and the beginner instructions are [[Image Creation For Beginners|here]].

For reference kickstart files for test images, see: http://gitorious.org/qa-tools/eat/commits/ks

== Images for host based testing ==
For host based testing the image needs to have the eat-device package installed and optionally eat-syslog-device in it. In addition to these configuration packages you need in to install test packages to the image since OTS fetches the tests from the image.

== Images for on device testing ==
For on device testing install eat-selftest package along with your test packages to the image. This package finds and executes all tests found in the image automatically after boot and writes test results to $HOME/testresults. The tests are executed as the user meego.

If you don't want the tests to be executed automatically and handle test execution yourself install testrunner-lite package to the image along with your tests. In this case the test execution is started like this

testrunner-lite -f /path/to/tests.xml -v -o /path/to/results.xml

== Automating image creation ==
Solution for automated image creation is not yet available.

One option is to use crontab and mic-image-creator.

= Running tests =
Automated test execution in MeeGo can be done by using generic test execution tool called testrunner-lite. Testrunner-lite reads planned tests from test plan xml file which is validated against test-definition schema. The tool can be run on the device under test or from a test control pc.

To enable automatically setting up the test environment we have created `eat` (Enable(s) Automated Testing) package. Eat package splits into different sub-packages listed below:

* eat-device - Configures the device under test for host based testing
* eat-selftest - Configures the device run tests automatically on boot
* eat-host - Configures test control pc for host based testing
* eat-syslog-device - Configures device's syslog to be sent to the host machince
* eat-syslog-host - Configures host's syslog to receive syslogs from the device under test

== Automatically running test packages on image ==
Tests can be run automatically on a MeeGo image by adding package eat-selftest to the image.

eat-selftest package pulls testrunner-lite and test-definition as dependencies to the image. The package itself installs an init script that finds all installed test packages and calls testrunner-lite to execute them. Test packages need to be installed in /usr/share/<packagename>-tests/tests.xml, otherwise the script doesn't find them.

Results from the test and logs from the test runs are written to $HOME/testresults whese $HOME is the path to the user's home who is executing the tests.

== Running test from test control pc ==
If testing is performed by [[Quality/QA-tools/OTS|OTS]] the test packages are fetched from the device and you don't need to manually start the test execution. To manually start test execution from the test control pc (host machine) you need to have the test plan xml files available on the host. To start executing tests in the device under test you need to tell testrunner-lite the device's IP address. For example

testrunner-lite -f tests.xml -v -o results.xml -t root@192.168.2.15

= Setting up test automation environment =
This chapter describes how to set up you own test automation environment. The environment includes host machine configuration, setting up OTS server and configuring the device under test.

== Setting up the host machine ==
RPM packages produced by [[Build Infrastructure|obs]] are only tested to work with MeeGo and Fedora 13. If you're using Ubuntu as your host see the Ubuntu 10.04 subsection.

Install the package eat-host to you host machine. This package will install ssh-keys needed for passwordless authentication and testrunner-lite and test-definition as dependencies. If you need also to receive syslogs from the device under test, also install the eat-syslog-host/device packages.

After installing you need to configure the host machine to use usb networking with the device under test. With Fedora you can do this by right-clicking the network managet icon and selecting edit connections. Edit the "Auto usb0" -connections IPv4 Settings and set Method to Manual and define the following Address to it:

Address: 192.168.2.14
Netmask: 255.255.255.0
Gateway: 0.0.0.0

or if you don't use network manager to manage your networking do the following

# ifconfig usb0 192.168.2.14 up

After this your host machine should be ready to act as a test control pc. Have fun testing with it.

'''Note!''' If the usb connection is unstable or breaks time to time, one reason for this can be the network-manager (Ubuntu).
You can remove the network-manager and configure network settings manually. This is recommended to do for OTS workers and maybe to your desktop, not for laptops (WLAN connections are hard to create after removing the network-manager).

sudo apt-get purge network-manager

Edit /etc/network/interfaces and add next lines (this assumes that your wired connection is eth0 and it uses dhcp):

auto eth0
iface eth0 inet dhcp

auto usb0
iface usb0 inet static
address 192.168.2.14
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
up iptables -A POSTROUTING -t nat -j MASQUERADE
up echo 1 >/proc/sys/net/ipv4/ip_forward
down echo 0 >/proc/sys/net/ipv4/ip_forward
down iptables -t nat -F POSTROUTING

=== Ubuntu 10.04 ===

If you're using Ubuntu 10.04 or 10.10 as your host you can get the host side configuration packages and tools from Tools:Testing debian repository by doing the following:

1. [[Quality/QA-tools/How_to_set_up_repositories#Ubuntu_10.04|Set up Tools:Testing repository]]

2. Install the host configuration package

sudo apt-get install eat-host-ubuntu

The package 'eat-host-ubuntu' will install ssh-keys used to access the device under test for the root user and configure the host to receive syslogs from the device under test. In addition to the configuration the package will install testrunner-lite, testrunner-lite-hwinfo-meego and test-definition as it's dependencies.

=== Fedora 13 ===

Host side tools are also available from a Fedora 13 repository. Set up Fedora 13 as the host by doing the following:

1. [[Quality/QA-tools/How_to_set_up_repositories#Fedora_13|Set up the repository]]

2. Install the following packages from the repository mentioned above

# yum install eat-host eat-syslog-host

== Setting up the device under test ==

=== Nokia N900 ===
To enable host based test execution with N900 MeeGo image you need to install eat-device package to the image. The package will install ssh keys to enable passwordless logins from the host machine. Package eat-syslog-device can also be used to configure the images syslog settings so that syslogs get sent to the host machine.

MeeGo images for the N900 have usb networking enabled by default. The devices IP address is 192.168.2.15

=== Netbooks ===
Current assumption is that we will use ethernet connection to netbook. The netbook should have ip 192.168.2.15 and eat-device package installed.
Configuring DHCP for netbook is explained in [[PXE_boot_server|PXE_boot_server]].

=== Other devices ===
If the device under test uses IP 192.168.2.15 and the test control PC uses IP 192.168.2.14 then you can make the set up by using the eat-device and eat-host packages. The default IP addresses need to be those to support OTS. If you need to use some other IP addresses you have to do some manual work to get host based test execution working.

To enable host based test execution do the following:

Add the test control PC's public ssh-key to the devices authorized_keys by

cat ~/.ssh/id_rsa.pub | ssh root@[devices's IP address] "mkdir -p ~/.ssh ; cat >> ~/.ssh/authorized_keys"

you may also need to increase the device's sshd startups by

echo "MaxStartUps 1024" >> /etc/ssh/sshd_config

after this you should be able to run testrunner-lite from the host machine. If you need to get the device's syslog sent to the test control PC you have to edit the device's /etc/rsyslog.conf or /etc/syslog.conf depending if the image is using rsyslog or sysklogd. Newer MeeGo images are using sysklogd. For sysklogd do the following

cp /etc/syslog.conf /etc/syslog.conf.back
echo "*.*;auth,authpriv.none @[control PC's IP]"\
>> /etc/syslog.conf
cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
sed -e 's/SYSLOGD_OPTIONS.*/SYSLOGD_OPTIONS=\"-m 0 -r\"/' \
/etc/sysconfig/sysklogd.back \
> /etc/sysconfig/sysklogd

After that setup the test control PC to receive the syslogs

cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
cp /etc/syslog.conf /etc/syslog.conf.back
echo "SYSLOGD_OPTIONS=\"-m 0 -r\"" >> /etc/sysconfig/sysklogd
echo ":fromhost-ip, isequal, "[device's IP]" /var/log/eat.log"\
>> /etc/syslog.conf

= Automatic image installations =

== N900 ==
MeeGo images can be installed to the N900 automatically by using autoinstaller-n900.sh script. The script is included in [[File:autoinstaller-n900.tar.gz]]. The package also contains a custom initrd image and kernel that are used in the installation process. The package however does not include the Nokia flasher utility required by the process. The utility is available for N900 owners from [http://tablets-dev.nokia.com/ Nokia]

Autoinstaller for N900 images is available here: [[File:autoinstaller-n900.tar.gz]]

'''Pre-requirements'''

* Flasher utility is in the same folder as the script
* Device has an external microSD card
* Device is connected with USB cable to the host machine
* The device is powered off

'''Usage'''
After all the pre-requirements are met do the following

cd /path/to/directory/containing/script/
sudo ./autoinstaller-n900.sh /path/to/raw-image /path/to/kernel

Note that the kernel given to the script is the kernel that comes with the raw image.

== Netbook ==

The automated install of netbooks is still work in progress. Current idea is that the test control PC acts as a PXE boot server for the SUT (=netbook).
We boot into initrd image over ethernet and from there on do pretty much the same as with the N900. The following has been tested with Samsung NC 10 laptop.

Autoinstaller for netbooks: [[File:autoinstaller-netbook.tar.gz]]

'''Pre-requirements'''

* Laptop with PXE support
*[[PXE boot server]]
* Laptop connected to PXE server over ethernet and powered off

'''Usage'''

* Power on the laptop and press F12 (Samsung NC 10 has "PXE always on" BIOS option but it does not seem to have the desired effect).
* If all goes well you should see the following line on the laptop screen:
Starting netcat for initial connection check
* Do the following
cd /path/to/directory/containing/script/
sudo ./autoinstaller-netbook.sh /path/to/raw-image

== Other targets ==
No solution for other targets currently available

= Troubleshooting =

== N900 auto installation never finishes ==

* Check if the copying is being done by
sudo kill -USR1 `pidof dd`

* Check if usb0 interface is configured
ifconfig

bring the interface up by
ifconfig usb0 192.168.2.14 up

The installation tries to bring the interface up automatically if it can't get a response from the device by doing the above command

Note that USB hubs, etc. can slow down the installation significantly.

== Freezing ssh sessions with host based execution ==

Some users have a use case where they want to start a server process in a test step to be used by later test steps. If you fork a new process it is possible that the ssh session running freezes during logout until given timeout or when the process terminates. This blocks further test steps. Reason for this is that each test step is currently in its own ssh session and the forked process holds on to its standard pipes and working directory. This is discussed in more technical detail in [http://bugs.meego.com/show_bug.cgi?id=5718 bug 5718].

One solution to this issue is daemonizing the new process. Then it redirects it's input, output and error pipes to "/dev/null" and changes the working directory to root. Here's a short code snippet how to daemonize a C program.

#include <stdlib.h>

int main( int argc, char *argv[] ) {
daemon(0, 0);
/* actual code */
return 0;
}

The server process '''must''' be terminated by a later test step so that it won't stay running in the device after test case.

Quality/QA-tools/Autotest-guide

2010-11-19T10:11:50Z

Vesse: Link to image creation and OBS

= Introduction =
This guide gives a walk through of the steps needed to automate testing in MeeGo. The guide is updated when automated testing solutions are updated or new parts for the system are taken into use so make sure to check the guide for updates every now and then.

The current automated testing solution offers two different ways to execute the tests, from host pc through ssh or on the device under test itself. OTS uses host based testing to execute the tests. On device testing is meant to be used with manual testing and in special cases where host based testing is not an feasible option.

For information about the tools used with test automation see [[Quality/QA-tools#Tools and Maintainers|QA-tools and maintainers]].

== Feedback ==
Feel free to contribute and improve this guide. For questions and/or feedback about it pop by #meego-qa-tools at freenode or use [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list].

= Writing tests =

== Test plan ==
Test plan is a XML file that contains your test suites, cases and steps. The basic principle of test plan XML and tool support is that you can use 'any' executable for testing.

For more information on writing test plan XMLs see [[Quality/QA-tools/Test plan|Test plan]] page in this wiki.

== Test packaging ==

Test packaging is intended to provide flexible and consistent ways to run tests and get results. You may select testing tools of your choice.

Test packaging is set of simple rules to wrap tests with test plan inside rpm package. Tool support for validating test plan and automating test plan execution is provided with testrunner. Following describes rpm-version of test packaging.

A source package with test cases must:

* build binary rpm package with name which ends with "<code>-tests</code>" (this is a test package)

A test package must:

* contain all tests, scripts and configuration files required to run tests
* define dependencies - the ones it tests and the test tools it depends on (if any)
* contain a test plan located at <code>/usr/share/<packagename>-tests/tests.xml</code> [1]

For more information on creating test packages, see [[Quality/QA-tools/Test package|Test package]] page in this wiki.

= Creating test images =
To perform automated testing you need to [[Image Creation|create images]] that contain test automation enablers and the tests. You can create two types of test images depending on how tests are planned to be executed.

For reference kickstart files for test images, see: http://gitorious.org/qa-tools/eat/commits/ks

== Images for host based testing ==
For host based testing the image needs to have the eat-device package installed and optionally eat-syslog-device in it. In addition to these configuration packages you need in to install test packages to the image since OTS fetches the tests from the image.

== Images for on device testing ==
For on device testing install eat-selftest package along with your test packages to the image. This package finds and executes all tests found in the image automatically after boot and writes test results to $HOME/testresults. The tests are executed as the user meego.

If you don't want the tests to be executed automatically and handle test execution yourself install testrunner-lite package to the image along with your tests. In this case the test execution is started like this

testrunner-lite -f /path/to/tests.xml -v -o /path/to/results.xml

== Automating image creation ==
Solution for automated image creation is not yet available.

One option is to use crontab and mic-image-creator.

= Running tests =
Automated test execution in MeeGo can be done by using generic test execution tool called testrunner-lite. Testrunner-lite reads planned tests from test plan xml file which is validated against test-definition schema. The tool can be run on the device under test or from a test control pc.

To enable automatically setting up the test environment we have created `eat` (Enable(s) Automated Testing) package. Eat package splits into different sub-packages listed below:

* eat-device - Configures the device under test for host based testing
* eat-selftest - Configures the device run tests automatically on boot
* eat-host - Configures test control pc for host based testing
* eat-syslog-device - Configures device's syslog to be sent to the host machince
* eat-syslog-host - Configures host's syslog to receive syslogs from the device under test

== Automatically running test packages on image ==
Tests can be run automatically on a MeeGo image by adding package eat-selftest to the image.

eat-selftest package pulls testrunner-lite and test-definition as dependencies to the image. The package itself installs an init script that finds all installed test packages and calls testrunner-lite to execute them. Test packages need to be installed in /usr/share/<packagename>-tests/tests.xml, otherwise the script doesn't find them.

Results from the test and logs from the test runs are written to $HOME/testresults whese $HOME is the path to the user's home who is executing the tests.

== Running test from test control pc ==
If testing is performed by [[Quality/QA-tools/OTS|OTS]] the test packages are fetched from the device and you don't need to manually start the test execution. To manually start test execution from the test control pc (host machine) you need to have the test plan xml files available on the host. To start executing tests in the device under test you need to tell testrunner-lite the device's IP address. For example

testrunner-lite -f tests.xml -v -o results.xml -t root@192.168.2.15

= Setting up test automation environment =
This chapter describes how to set up you own test automation environment. The environment includes host machine configuration, setting up OTS server and configuring the device under test.

== Setting up the host machine ==
RPM packages produced by [[Build Infrastructure|obs]] are only tested to work with MeeGo and Fedora 13. If you're using Ubuntu as your host see the Ubuntu 10.04 subsection.

Install the package eat-host to you host machine. This package will install ssh-keys needed for passwordless authentication and testrunner-lite and test-definition as dependencies. If you need also to receive syslogs from the device under test, also install the eat-syslog-host/device packages.

After installing you need to configure the host machine to use usb networking with the device under test. With Fedora you can do this by right-clicking the network managet icon and selecting edit connections. Edit the "Auto usb0" -connections IPv4 Settings and set Method to Manual and define the following Address to it:

Address: 192.168.2.14
Netmask: 255.255.255.0
Gateway: 0.0.0.0

or if you don't use network manager to manage your networking do the following

# ifconfig usb0 192.168.2.14 up

After this your host machine should be ready to act as a test control pc. Have fun testing with it.

'''Note!''' If the usb connection is unstable or breaks time to time, one reason for this can be the network-manager (Ubuntu).
You can remove the network-manager and configure network settings manually. This is recommended to do for OTS workers and maybe to your desktop, not for laptops (WLAN connections are hard to create after removing the network-manager).

sudo apt-get purge network-manager

Edit /etc/network/interfaces and add next lines (this assumes that your wired connection is eth0 and it uses dhcp):

auto eth0
iface eth0 inet dhcp

auto usb0
iface usb0 inet static
address 192.168.2.14
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
up iptables -A POSTROUTING -t nat -j MASQUERADE
up echo 1 >/proc/sys/net/ipv4/ip_forward
down echo 0 >/proc/sys/net/ipv4/ip_forward
down iptables -t nat -F POSTROUTING

=== Ubuntu 10.04 ===

If you're using Ubuntu 10.04 or 10.10 as your host you can get the host side configuration packages and tools from Tools:Testing debian repository by doing the following:

1. [[Quality/QA-tools/How_to_set_up_repositories#Ubuntu_10.04|Set up Tools:Testing repository]]

2. Install the host configuration package

sudo apt-get install eat-host-ubuntu

The package 'eat-host-ubuntu' will install ssh-keys used to access the device under test for the root user and configure the host to receive syslogs from the device under test. In addition to the configuration the package will install testrunner-lite, testrunner-lite-hwinfo-meego and test-definition as it's dependencies.

=== Fedora 13 ===

Host side tools are also available from a Fedora 13 repository. Set up Fedora 13 as the host by doing the following:

1. [[Quality/QA-tools/How_to_set_up_repositories#Fedora_13|Set up the repository]]

2. Install the following packages from the repository mentioned above

# yum install eat-host eat-syslog-host

== Setting up the device under test ==

=== Nokia N900 ===
To enable host based test execution with N900 MeeGo image you need to install eat-device package to the image. The package will install ssh keys to enable passwordless logins from the host machine. Package eat-syslog-device can also be used to configure the images syslog settings so that syslogs get sent to the host machine.

MeeGo images for the N900 have usb networking enabled by default. The devices IP address is 192.168.2.15

=== Netbooks ===
Current assumption is that we will use ethernet connection to netbook. The netbook should have ip 192.168.2.15 and eat-device package installed.
Configuring DHCP for netbook is explained in [[PXE_boot_server|PXE_boot_server]].

=== Other devices ===
If the device under test uses IP 192.168.2.15 and the test control PC uses IP 192.168.2.14 then you can make the set up by using the eat-device and eat-host packages. The default IP addresses need to be those to support OTS. If you need to use some other IP addresses you have to do some manual work to get host based test execution working.

To enable host based test execution do the following:

Add the test control PC's public ssh-key to the devices authorized_keys by

cat ~/.ssh/id_rsa.pub | ssh root@[devices's IP address] "mkdir -p ~/.ssh ; cat >> ~/.ssh/authorized_keys"

you may also need to increase the device's sshd startups by

echo "MaxStartUps 1024" >> /etc/ssh/sshd_config

after this you should be able to run testrunner-lite from the host machine. If you need to get the device's syslog sent to the test control PC you have to edit the device's /etc/rsyslog.conf or /etc/syslog.conf depending if the image is using rsyslog or sysklogd. Newer MeeGo images are using sysklogd. For sysklogd do the following

cp /etc/syslog.conf /etc/syslog.conf.back
echo "*.*;auth,authpriv.none @[control PC's IP]"\
>> /etc/syslog.conf
cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
sed -e 's/SYSLOGD_OPTIONS.*/SYSLOGD_OPTIONS=\"-m 0 -r\"/' \
/etc/sysconfig/sysklogd.back \
> /etc/sysconfig/sysklogd

After that setup the test control PC to receive the syslogs

cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
cp /etc/syslog.conf /etc/syslog.conf.back
echo "SYSLOGD_OPTIONS=\"-m 0 -r\"" >> /etc/sysconfig/sysklogd
echo ":fromhost-ip, isequal, "[device's IP]" /var/log/eat.log"\
>> /etc/syslog.conf

= Automatic image installations =

== N900 ==
MeeGo images can be installed to the N900 automatically by using autoinstaller-n900.sh script. The script is included in [[File:autoinstaller-n900.tar.gz]]. The package also contains a custom initrd image and kernel that are used in the installation process. The package however does not include the Nokia flasher utility required by the process. The utility is available for N900 owners from [http://tablets-dev.nokia.com/ Nokia]

Autoinstaller for N900 images is available here: [[File:autoinstaller-n900.tar.gz]]

'''Pre-requirements'''

* Flasher utility is in the same folder as the script
* Device has an external microSD card
* Device is connected with USB cable to the host machine
* The device is powered off

'''Usage'''
After all the pre-requirements are met do the following

cd /path/to/directory/containing/script/
sudo ./autoinstaller-n900.sh /path/to/raw-image /path/to/kernel

Note that the kernel given to the script is the kernel that comes with the raw image.

== Netbook ==

The automated install of netbooks is still work in progress. Current idea is that the test control PC acts as a PXE boot server for the SUT (=netbook).
We boot into initrd image over ethernet and from there on do pretty much the same as with the N900. The following has been tested with Samsung NC 10 laptop.

Autoinstaller for netbooks: [[File:autoinstaller-netbook.tar.gz]]

'''Pre-requirements'''

* Laptop with PXE support
*[[PXE boot server]]
* Laptop connected to PXE server over ethernet and powered off

'''Usage'''

* Power on the laptop and press F12 (Samsung NC 10 has "PXE always on" BIOS option but it does not seem to have the desired effect).
* If all goes well you should see the following line on the laptop screen:
Starting netcat for initial connection check
* Do the following
cd /path/to/directory/containing/script/
sudo ./autoinstaller-netbook.sh /path/to/raw-image

== Other targets ==
No solution for other targets currently available

= Troubleshooting =

== N900 auto installation never finishes ==

* Check if the copying is being done by
sudo kill -USR1 `pidof dd`

* Check if usb0 interface is configured
ifconfig

bring the interface up by
ifconfig usb0 192.168.2.14 up

The installation tries to bring the interface up automatically if it can't get a response from the device by doing the above command

Note that USB hubs, etc. can slow down the installation significantly.

== Freezing ssh sessions with host based execution ==

Some users have a use case where they want to start a server process in a test step to be used by later test steps. If you fork a new process it is possible that the ssh session running freezes during logout until given timeout or when the process terminates. This blocks further test steps. Reason for this is that each test step is currently in its own ssh session and the forked process holds on to its standard pipes and working directory. This is discussed in more technical detail in [http://bugs.meego.com/show_bug.cgi?id=5718 bug 5718].

One solution to this issue is daemonizing the new process. Then it redirects it's input, output and error pipes to "/dev/null" and changes the working directory to root. Here's a short code snippet how to daemonize a C program.

#include <stdlib.h>

int main( int argc, char *argv[] ) {
daemon(0, 0);
/* actual code */
return 0;
}

The server process '''must''' be terminated by a later test step so that it won't stay running in the device after test case.

Quality/QA-tools/Autotest-guide

2010-11-17T10:21:22Z

Vesse: /* Introduction */ typo

= Introduction =
This guide gives a walk through of the steps needed to automate testing in MeeGo. The guide is updated when automated testing solutions are updated or new parts for the system are taken into use so make sure to check the guide for updates every now and then.

The current automated testing solution offers two different ways to execute the tests, from host pc through ssh or on the device under test itself. OTS uses host based testing to execute the tests. On device testing is meant to be used with manual testing and in special cases where host based testing is not an feasible option.

For information about the tools used with test automation see [[Quality/QA-tools#Tools and Maintainers|QA-tools and maintainers]].

== Feedback ==
Feel free to contribute and improve this guide. For questions and/or feedback about it pop by #meego-qa-tools at freenode or use [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list].

= Writing tests =

== Test plan ==
Test plan is a XML file that contains your test suites, cases and steps. The basic principle of test plan XML and tool support is that you can use 'any' executable for testing.

For more information on writing test plan XMLs see [[Quality/QA-tools/Test plan|Test plan]] page in this wiki.

== Test packaging ==

Test packaging is intended to provide flexible and consistent ways to run tests and get results. You may select testing tools of your choice.

Test packaging is set of simple rules to wrap tests with test plan inside rpm package. Tool support for validating test plan and automating test plan execution is provided with testrunner. Following describes rpm-version of test packaging.

A source package with test cases must:

* build binary rpm package with name which ends with "<code>-tests</code>" (this is a test package)

A test package must:

* contain all tests, scripts and configuration files required to run tests
* define dependencies - the ones it tests and the test tools it depends on (if any)
* contain test plan located at <code>/usr/share/<packagename>-tests/tests.xml</code> [1]

For more information on creating test packages, see [[Quality/QA-tools/Test package|Test package]] page in this wiki.

= Creating test images =
To perform automated testing you need to create images that contain test automation enablers and the tests. You can create two types of test images depending on how tests are planned to be executed.

For reference kickstart files for test images, see: http://gitorious.org/qa-tools/eat/commits/ks

== Images for host based testing ==
For host based testing the image needs to have the eat-device package installed and optionally eat-syslog-device in it. In addition to these configuration packages you need in to install test packages to the image since OTS fetches the tests from the image.

== Images for on device testing ==
For on device testing install eat-selftest package along with your test packages to the image. This package finds and executes all tests found in the image automatically after boot and writes test results to $HOME/testresults. The tests are executed as the user meego.

If you don't want the tests to be executed automatically and handle test execution yourself install testrunner-lite package to the image along with your tests. In this case the test execution is started like this

testrunner-lite -f /path/to/tests.xml -v -o /path/to/results.xml

== Automating image creation ==
Solution for automated image creation is not yet available.

= Running tests =
Automated test execution in MeeGo can be done by using generic test execution tool called testrunner-lite. Testrunner-lite reads planned tests from test plan xml file which is validated against test-definition schema. The tool can be run on the device under test or from a test control pc.

To enable automatically setting up the test environment we have the created `eat` (Enable(s) Automated Testing) package. Eat package splits into different sub-packages listed below:

* eat-device - Configures the device under test for host based testing
* eat-selftest - Configures the device run tests automatically on boot
* eat-host - Configures test control pc for host based testing
* eat-syslog-device - Configures device's syslog to be sent to the host machince
* eat-syslog-host - Configures host's syslog to receive syslogs from the device under test

== Automatically running test packages on image ==
Tests can be run automatically on a MeeGo image by adding package eat-selftest to the image.

eat-selftest package pulls testrunner-lite and test-definition as dependencies to the image. The package itself installs an init script that finds all installed test packages and calls testrunner-lite to execute them. Test packages need to be installed in /usr/share/<packagename>-tests/tests.xml, otherwise the script doesn't find them.

Results from the test and logs from the test runs are written to $HOME/testresults whese $HOME is the path to the user's home who is executing the tests.

== Running test from test control pc ==
If testing is performed by [[Quality/QA-tools/OTS|OTS]] the test packages are fetched from the device and you don't need to manually start the test execution. To manually start test execution from the test control pc (host machine) you need to have the test plan xml files available on the host. To start executing tests in the device under test you need to tell testrunner-lite the device's IP address. For example

testrunner-lite -f tests.xml -v -o results.xml -t root@192.168.2.15

= Setting up test automation environment =
This chapter describes how to set up you own test automation environment. The environment includes host machine configuration, setting up OTS server and configuring the device under test.

== Setting up the host machine ==
RPM packages produced by obs are only tested to work with MeeGo and Fedora 13. If you're using ubuntu as your host see the Ubuntu 10.04 subsection.

Install the package eat-host to you host machine. This package will install ssh-keys needed for passwordless authentication and testrunner-lite and test-definition as dependencies. If you need also to receive syslogs from the device under test, also install the eat-syslog-host/device packages.

After installing you need to configure the host machine to use usb networking with the device under test. With Fedora you can do this by right-clicking the network managet icon and selecting edit connections. Edit the "Auto usb0" -connections IPv4 Settings and set Method to Manual and define the following Address to it:

Address: 192.168.2.14
Netmask: 255.255.255.0
Gateway: 0.0.0.0

or if you don't use network manager to manage your networking do the following

# ifconfig usb0 192.168.2.14 up

After this your host machine should be ready to act as a test control pc. Have fun testing with it.

=== Ubuntu 10.04 ===
If you're using Ubuntu 10.04 as your host you can get the host side configuration packages and tools from Tools:Testing debian repository by doing the following.

1. Add the following to your sources.list

deb http://download.meego.com/live/Tools:/Testing/xUbuntu_10.04/ /

2. Add the repository key

wget http://download.meego.com/live/Tools:/Testing/xUbuntu_10.04/Release.key
sudo apt-key add Release.key
rm Release.key

3. Update your PC's package information

sudo apt-get update

4. Install the host configuration package

sudo apt-get install eat-host-ubuntu

The package 'eat-host-ubuntu' will install ssh-keys used to access the device under test for the root user and configure the host to receive syslogs from the device under test. In addition to the configuration the package will install testrunner-lite, testrunner-lite-hwinfo-meego and test-definition as it's dependencies.

=== Fedora 13 ===
Host side tools are also available from a Fedora 13 repository.

http://download.meego.com/live/Tools:/Testing/Fedora13/Tools:Testing.repo

To set up Fedora 13 as the host, install the following packages from the repository mentioned above

# yum install eat-host eat-syslog-host

== Setting up the device under test ==

=== Nokia N900 ===
To enable host based test execution with N900 MeeGo image you need to install eat-device package to the image. The package will install ssh keys to enable passwordless logins from the host machine. Package eat-syslog-device can also be used to configure the images syslog settings so that syslogs get sent to the host machine.

MeeGo images for the N900 have usb networking enabled by default. The devices IP address is 192.168.2.15

=== Netbooks ===
Current assumption is that we will use ethernet connection to netbook. The netbook should have ip 192.168.2.15 and eat-device package installed.
Configuring DHCP for netbook is explained in [[PXE_boot_server|PXE_boot_server]].

=== Other devices ===
If the device under test uses IP 192.168.2.15 and the test control PC uses IP 192.168.2.14 then you can make the set up by using the eat-device and eat-host packages. The default IP addresses need to be those to support OTS. If you need to use some other IP addresses you have to do some manual work to get host based test execution working.

To enable host based test execution do the following:

Add the test control PC's public ssh-key to the devices authorized_keys by

cat ~/.ssh/id_rsa.pub | ssh root@[devices's IP address] "mkdir -p ~/.ssh ; cat >> ~/.ssh/authorized_keys"

you may also need to increase the device's sshd startups by

echo "MaxStartUps 1024" >> /etc/ssh/sshd_config

after this you should be able to run testrunner-lite from the host machine. If you need to get the device's syslog sent to the test control PC you have to edit the device's /etc/rsyslog.conf or /etc/syslog.conf depending if the image is using rsyslog or sysklogd. Newer MeeGo images are using sysklogd. For sysklogd do the following

cp /etc/syslog.conf /etc/syslog.conf.back
echo "*.*;auth,authpriv.none @[control PC's IP]"\
>> /etc/syslog.conf
cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
sed -e 's/SYSLOGD_OPTIONS.*/SYSLOGD_OPTIONS=\"-m 0 -r\"/' \
/etc/sysconfig/sysklogd.back \
> /etc/sysconfig/sysklogd

After that setup the test control PC to receive the syslogs

cp /etc/sysconfig/sysklogd /etc/sysconfig/sysklogd.back
cp /etc/syslog.conf /etc/syslog.conf.back
echo "SYSLOGD_OPTIONS=\"-m 0 -r\"" >> /etc/sysconfig/sysklogd
echo ":fromhost-ip, isequal, "[device's IP]" /var/log/eat.log"\
>> /etc/syslog.conf

= Automatic image installations =

== N900 ==
MeeGo images can be installed to the N900 automatically by using autoinstaller-n900.sh script. The script is included in [[File:autoinstaller-n900.tar.gz]]. The package also contains a custom initrd image and kernel that are used in the installation process. The package however does not include the Nokia flasher utility required by the process. The utility is available for N900 owners from [http://tablets-dev.nokia.com/ Nokia]

Autoinstaller for N900 images is available here: [[File:autoinstaller-n900.tar.gz]]

'''Pre-requirements'''

* Flasher utility is in the same folder as the script
* Device has an external microSD card
* Device is connected with USB cable to the host machine
* The device is powered off

'''Usage'''
After all the pre-requirements are met do the following

cd /path/to/directory/containing/script/
sudo ./autoinstaller-n900.sh /path/to/raw-image /path/to/kernel

Note that the kernel given to the script is the kernel that comes with the raw image.

== Netbook ==

The automated install of netbooks is still work in progress. Current idea is that the test control PC acts as a PXE boot server for the SUT (=netbook).
We boot into initrd image over ethernet and from there on do pretty much the same as with the N900. The following has been tested with Samsung NC 10 laptop.

Autoinstaller for netbooks: [[File:autoinstaller-netbook.tar.gz]]

'''Pre-requirements'''

* Laptop with PXE support
*[[PXE boot server]]
* Laptop connected to PXE server over ethernet and powered off

'''Usage'''

* Power on the laptop and press F12 (Samsung NC 10 has "PXE always on" BIOS option but it does not seem to have the desired effect).
* If all goes well you should see the following line on the laptop screen:
Starting netcat for initial connection check
* Do the following
cd /path/to/directory/containing/script/
sudo ./autoinstaller-netbook.sh /path/to/raw-image

== Other targets ==
No solution for other targets currently available

= Troubleshooting =

== N900 auto installation never finishes ==

* Check if the copying is being done by
sudo kill -USR1 `pidof dd`

* Check if usb0 interface is configured
ifconfig

bring the interface up by
ifconfig usb0 192.168.2.14 up

The installation tries to bring the interface up automatically if it can't get a response from the device by doing the above command

Note that USB hubs, etc. can slow down the installation significantly.

== Freezing ssh sessions with host based execution ==

Some users have a use case where they want to start a server process in a test step to be used by later test steps. If you fork a new process it is possible that the ssh session running freezes during logout until given timeout or when the process terminates. This blocks further test steps. Reason for this is that each test step is currently in its own ssh session and the forked process holds on to its standard pipes and working directory. This is discussed in more technical detail in [http://bugs.meego.com/show_bug.cgi?id=5718 bug 5718].

One solution to this issue is daemonizing the new process. Then it redirects it's input, output and error pipes to "/dev/null" and changes the working directory to root. Here's a short code snippet how to daemonize a C program.

#include <stdlib.h>

int main( int argc, char *argv[] ) {
daemon(0, 0);
/* actual code */
return 0;
}

The server process '''must''' be terminated by a later test step so that it won't stay running in the device after test case.

Quality/QA-tools

2010-11-01T08:43:28Z

Vesse: /* Team Members and Collaboration Spaces */ Added myself

= Quality Assurance (QA) Tools =

Quality Assurance tools are developed to ensure MeeGo SW quality. QA tools team develops and maintains tools for Quality Assurance.

Open source tools – available for all, available for development and contributions. Make people accountable for quality.

Anyone is welcome to contribute and non-member contributions will be treated with same process and review as member contributions. We follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines]. In addition, you may take personal clone from our [http://gitorious.org/qa-tools git repositories] and create merge request. Tool maintainers in our projects will review your contributions and decide on merge.

'''Targets:'''

* Improve MeeGo test reporting tools - target from MeeGo Quality Assurance
* Currently test reports are published manually to wiki
* Improve MeeGo test automation (execution and software installation) - target from MeeGo release engineering

"As Core OS release release manager I want to verify trunk:testing packages frequently so that I know the quality of nightly/weekly releases."

== Tools and Maintainers ==

Tool maintainers are selected based on developer experience with particular tool/package or seniority. Tool maintainers have been agreed [[Quality/QA-tools/Meetings|in the QA-tools weekly meeting]] Tuesday September 7th 2010. Changes, if needed, are discussed also there.

In practice only tool maintainers will have commit and review right to particular repository - later several people may have rights to repository based on merit (as proposed by tool maintainer). Others must follow [http://meego.com/about/contribution-guidelines MeeGo contribution guidelines] to submit patches or personal clone + merge request approach.

The maintainer of the tree shall update the changelog.

{| border="1" cellspacing="0"
|+
|'''Tool (link to gitorious)''' ||'''Wiki Page''' ||'''Maintainer''' ||'''Substitute'''
|-
| [http://gitorious.org/qa-tools/test-definition test-definition] || [[Quality/QA-tools/Test-definition|Link]] || Sampo Saaristo || Timo Härkönen
|-
| [http://gitorious.org/qa-tools/testrunner-lite testrunner-lite] || [[Quality/QA-tools/Testrunner-lite|Link]] || Sampo Saaristo || Kyösti Ranto
|-
| [http://gitorious.org/qa-tools/testrunner-ui Testrunner-UI] || [[Quality/QA-tools/Testrunner-ui|Link]] || Kyösti Ranto || Timo Härkönen
|-
| [http://gitorious.org/qa-tools/testplanner Testplanner] || [[Quality/QA-tools/Testplanner|Link]] || Kyösti Ranto || N/A
|-
| [http://gitorious.org/qa-tools/eat eat - enables automated testing] || [[Quality/QA-tools/Eat|Link]] || Timo Härkönen || Timo Mäkimattila
|-
| [http://gitorious.org/qa-tools/ots ots - open testing system] || [[Quality/QA-tools/OTS|Link]] || Teemu Vainio || Tom Galvin
|-
| [http://gitorious.org/qa-tools/meego-ai MeeGo Automated installer] || [[Quality/QA-tools/Autotest-guide#Automatic_image_installations|Link]] || Timo Härkönen || N/A
|-
| [http://gitorious.org/qa-tools/mcts MeeGo Core Test Suite] || ||Matti Salmi || Jeff Zheng
|-
| [http://gitorious.org/qa-tools/mnts MeeGo Netbook Test Suite] || ||Jeff Zheng || N/A
|-
| [http://gitorious.org/qa-tools/qtuitest-mbt-adapter Model-Based Testing adapter for qtuitest] || [[Quality/QA-tools/qtuitest-mbt-adapter|Link]] ||Riku Halonen || N/A
|-
| [http://gitorious.org/min MIN test framework] || [[Quality/QA-tools/Min|Link]] || Sampo Saaristo || Timo Mäkimattila
|-
| [http://gitorious.org/TDriver Testability Driver] || [[Quality/QA-tools/TDriver|Link]] || Petri Kiiskinen || Tatu Lahtela
|-
| [http://gitorious.org/qa-tools/rich-core Rich Core dumper] || || Riku Halonen || Sami Lahtinen
|-
| [http://gitorious.org/qa-tools/crash-reporter Crash Reporter] || || Riku Halonen || Raimo Gratseff
|-
| [http://gitorious.org/qa-tools/crash-reporter-settings-public Crash Reporter settings] || || Riku Halonen || N/A
|}

See the rest of our team members and our collaboration spaces [[Quality/QA-tools#Team_Members_and_Collaboration_Spaces|below]]. If you are interested in the user experience work regarding these tools, you can find more information [[Quality/QA-tools/User experience|here]].

== Release Practices ==

Here's the workflow for QA-tools release practices.

{| border="1" cellspacing="0"
|+
|'''Role'''
|'''Description'''
|-
| Developer || Anyone who wants to participate in qa-tools development
|-
| VCS Maintainer || Component owner who has commit rights in version control system (VCS)
|-
| Package Maintainer || Integrator whose responsibility is the OBS packaging
|-
| Release Management || Third party who is responsible of trunk:testing releases(?)
|}

[[File:Release.png]]

Kivio file:
[[File:Release.flw]]

# Developer creates merge request(s) in gitorious.
# VCS Maintainer tests and accepts merge requests.
# VCS Maintainer checks/updates change logs.
# VCS Maintainer tags a version.
# VCS maintainer sends email to [http://lists.meego.com/pipermail/meego-qa/ meego-qa mailing list] based on the following template
Topic: Integration request: package-name version
PACKAGE: package-name
TAG: tag name
URL: link to sources
CHANGES: short description of changes containing bugs.meego.com bug numbers of fixed bugs
# Package maintainer updates the OBS package.
# Package maintainer tests the OBS package.
# If the package belongs to QA Tools repo and passes testing, Package Maintainer may accept it. If the package belongs to trunk:testing, Package Maintainer creates a promotional request to Release Management.
# Host side tools are updated to tools:testing after verifying functionality
# Package maintainer replies to meego-qa list about the actions done with the updated package. e.g. 'Updated in devel:quality and sent promotion request to testing'
# Release Management accepts the package. Or not.

Bugzilla workflow: [[Bugzilla/how-report-bugs]]

=== Release checklist ===
To make sure fixes are released without delay, check that the following conditions are met

# Change logs are updated and contain relevant references to MeeGo bugzilla
# Created obs request include fixes bug numbers from MeeGo bugzilla
# Bugzilla items listed in changes are set as resolved
# Spec file matches [[Packaging/Guidelines|MeeGo packaging guidelines]]
# Rpmlint warnings are either fixed or explained by comments in the spec file. e.g. eat packages install files into root's home and the reasoning for it needs to be explained
# Host side tool packages use the same source tar ball to produce debian and rpm packages

== Features and Bugs ==

Want to report an feature idea or bug to us? - [http://bugs.meego.com/enter_bug.cgi?product=Development%20Tools Please do it here]

* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=ASSIGNED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Platform&product=Development%20Tools Assigned bugs and features - Working on it]
* [http://bugs.meego.com/buglist.cgi?query_format=advanced&order=Importance&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&component=eat&component=min&component=ots&component=TDriver&component=testdefinition&component=Testplanner&component=testrunner%20UI&component=testrunner-lite&classification=MeeGo%20Platform&product=Development%20Tools All open features and bugs in priority order]

== Documentation ==

This section will contain links to various guides and user documentation. See [[Quality/QA-tools#Tools_and_Maintainers|the wiki pages of the tools]] for tool-specific documentation.

* [[Quality/QA-tools/Autotest-guide|Autotest-Guide]]

== Meetings ==

Meetings will be held weekly on Tuesdays 12:00 UTC in <code>#meego-meeting on irc.freenode.net</code>.

* [[Quality/QA-tools/Meetings|Meeting agendas and minutes]]

== Team Members and Collaboration Spaces==

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| '''Name'''
| '''Role'''
| '''Affiliation'''
| '''IRC nickname'''
|-
| Ville Ilvonen || Team lead (act.) || Nokia || vilvo
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || sievi
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || carrus
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || rrraimo
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Arto Sinnelä || Team member || Digia || asinnela
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Timo Mäkimattila || Team member || Digia || timakima
|-
| Elias Luttinen || Team member || Digia || eluttine
|-
| Ville Niutanen || Team member || Digia || Villen
|-
| Esa-Pekka Miettinen || Team member || Digia || E-P
|-
| Vesa Poikajärvi || Team member || Digia || vesse
|-
| Sampo Saaristo || Team member || Sofica || sampos
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
| Teemu Vainio || Team member || Ixonos || tvainio
|-
| Tuomo Mäkinen || Team member || Ixonos || -
|-
| Jouni Leppäkases || Team member || Ixonos || jouni
|-
| Tom Galvin || Team member || Ixonos || -
|-
|}

Team communication is in English. Our collaboration spaces are:
* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://webchat.freenode.net/?channels=meego-qa-tools #meego-qa-tools IRC channel on irc.freenode.net]
* Gitorious team, http://gitorious.org/qa-tools (to be moved meego.gitorious.org)
* [http://www.youtube.com/user/meegoqatools Youtube channel for demo videos]
* MeeGo OBS - devel:quality
* This wiki area
* [[Quality/QA-tools/ServiceOS|ServiceOS]]
* [[Quality/QA-tools/PXEInstall|PXEInstallation]]

[[Category:QA]]

Main Page

2010-09-21T13:23:55Z

Vesse: /* Yearly MeeGo Conference */ Yearly -> Annual

= Structure and Governance =

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]

Anyone can attend the bi-weekly [[Technical Steering Group meetings]] to learn more about the decisions being made in the MeeGo project.

== MeeGo Project Functions ==

* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Quality]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]

= User =

* [[MeeGo 1.0 Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo 1.0 on your netbook]
* [[Devices|Supported devices]]

= Developer =
== Developer Guide ==

* [[Developer Guide]]
* [[Build_Infrastructure | Build Infrastructure]]

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, N8x0, Beagleboard, MSM/QSD + QEMU)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].

See also [[Who's who]].

== Regular Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Working Group meeting]]
* [[Localization team]]

== Annual MeeGo Conference ==

The [http://conference2010.meego.com/ MeeGo Conference 2010] will be held at Aviva Stadium in Dublin, Ireland, November 15-17th, 2010. Visit the [[MeeGo Conference 2010]] wiki page for planning details.

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

Image Creation

2010-08-18T14:46:54Z

Vesse: /* libgcc related issues */ Typo

= Overview =

This is the main Image Creator developer's guide. For a more simplistic, step-by-step document, go to: [[Image Creation For Beginners]].

The tool used to create MeeGo images is something called "MIC2" (for distinguishing from obsolete MIC - Moblin Image Creator). MIC stands for MeeGo Image Creator. It is composed of a series of tools to create images, convert images and do some development work on MeeGo. MIC2 is based primarily on Fedora livecd-tools and appliance-tools.

With MIC2 tools, users can create different types of images for different purposes, including live CD images, live USB images, raw images for KVM, VMDK images for Vmware, vdi images for VirtualBox, loop images for IVI platforms, NAND images for Moorestown platforms, ubi images for N900, fs image for MeeGo developers. Also, users can use MIC2 tools to manipulate images like transforming an image from a virtual machine to a live image, and providing a chroot environment based on an existing live image. With these features, developers can do development work on a host virtual machine running MeeGo or a Meego chroot environment, and transfer the resulting new live image to a target device for final debug/verification.

This document discusses only features, usage guide, and known issues.

= Features =

MIC2 offers these major tools:
* mic-image-creator: create images.
* mic-image-convertor: convert a raw/vmdk/vdi/live image into a live image.
* mic-chroot: provide a MeeGo environment from a live/loop image for development, it also can translate that chroot file system into a live image.
* mic-image-writer: write a MeeGo image to a USB disk. This is a safe alternative to dd.

The following support is provided:

* Supports mainstream Linux distros. MIC2 has been thoroughly tested on these distributions:
** Meego
** Fedora (Fedora 10 and above)
** Opensuse (> OpenSUSE 11.1)
** and Ubuntu > 9.04
* Supports various types of images: livecd, liveusb, loop, raw, vmdk, nandmrst, vdi, fs, ubi
* Supports image coversion from virtual machine/live images to live images.
* Uses kickstart (.ks) files for image creation. Through this, users can specify which software repositories to use, which packages to install and basic system configuration directives. Please refer to http://fedoraproject.org/wiki/Anaconda/Kickstart for more information about kickstart configuration files.

= Usage =

== Requirements ==

To be able to use MIC2, the following packages must be available on your system. (Most of the packages are installed by default, depending on the distribution.):

* yum
* rpm
* kpartx
* parted
* syslinux
* isomd5sum
* kvm
* zlib-devel(for compiling)
* python-devel(for installation)

You should load these modules as well, if not loaded automatically by the kernel:

* squashfs
* squashfs-tools
* dm_snapshot
* loop

Specific packages for Fedora:

* pykickstart
* device-mapper

Specific packages for Ubuntu 8.10:

* python-celementtree
* python-elementtree
* dmsetup

=== Installing requirements for Ubuntu 10.04 ===

sudo apt-get install yum rpm kpartx parted syslinux isomd5sum kvm zlib1g-dev squashfs-tools python2.6-dev

== Installation ==

We currently build MIC2 binary rpms/debs for many popular Linux distributions, including Fedora 11, Fedora 12, Ubuntu 9.04, Ubuntu 9.10, Ubuntu 10.04, OpenSUSE 11.1, OpenSUSE 11.2 and Debian 5.0. Please go to http://repo.meego.com/tools/repos/ to get repository URL corresponding to your Linux distribution then add it into your repo or package source for installation and update later. If your distribution isn't in support list, please install MIC2 from git source.

=== From Binary Packages ===

* '''Installation Steps For Fedora 11 and Fedora 12'''

1. Add MIC2 repo

For Fedora 11, save [[Media:Meego-devel-tools-f11.repo|Meego-devel-tools-f11.repo]] as /etc/yum.repos.d/meego-devel-tools-f11.repo

For Fedora 12, save [[Media:Meego-devel-tools-f12.repo|Meego-devel-tools-f12.repo]] as /etc/yum.repos.d/meego-devel-tools-f12.repo

2. sudo yum install mic2 --nogpgcheck

* '''Update Steps For Fedora 11 and Fedora 12'''

You can use the below command to get the latest mic2 package.

<pre>
sudo yum update mic2 --nogpgcheck
</pre>

* '''Installation Steps For Ubuntu 9.04, Ubuntu 9.10, Ubuntu 10.04 and Debian 5.0'''

1. Add package source

For Ubuntu 9.04, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/tools/repos/ubuntu/9.04/ /
</pre>

Note: also ensure your libsqlite3-0 package is 3.6.10-1ubuntu0.2 or later. You may need to enable recommended updates on the update tab of System / Administration / Software Sources.

For Ubuntu 9.10, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/tools/repos/ubuntu/9.10/ /
</pre>

For Ubuntu 10.04, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/tools/repos/ubuntu/10.04/ /
</pre>

For Debian 5.0, add the below line to /etc/apt/sources.list

<pre>
deb http://repo.meego.com/tools/repos/debian/5.0/ /
</pre>

2. sudo apt-get update

You should see the following error:
W: GPG error: http://repo.meego.com Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0BC7BEC479FC1F8A

To add the repository public key use the following command:
:gpg --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
:gpg --export --armor 0BC7BEC479FC1F8A | sudo apt-key add -

3. sudo apt-get install syslinux=3.85

4. sudo apt-get install mic2

* '''Update Steps For Ubuntu 9.04, Ubuntu 9.10, Ubuntu 10.04 and Debian 5.0'''

1. sudo apt-get update

2. sudo apt-get install mic2

* '''Installation Steps For OpenSUSE 11.1 and OpenSUSE 11.2'''

1. Add repos

For OpenSUSE 11.1:

<pre>sudo zypper addrepo http://repo.meego.com/tools/repos/opensuse/11.1/ meego-tools</pre>

For OpenSUSE 11.2:

<pre>sudo zypper addrepo http://repo.meego.com/tools/repos/opensuse/11.2/ meego-tools</pre>

2. sudo zypper install mic2

* '''Update Steps For OpenSUSE 11.1 and OpenSUSE 11.2'''

<pre>
sudo zypper update mic2
</pre>

=== From Stable Git Source Releases ===

You can get the latest stable release of MIC2 from the tag section in http://meego.gitorious.org/meego-developer-tools/image-creator. Click on the "Source tree" link on the top of the screen. There will be a list of tags on the right hand side.

You should follow the below steps to install it:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
cd image-creator
git checkout 0.17 #check Gitorious for the most recent tag
make
sudo make install
</pre>

=== From Development Git Tree ===

Note: MIC2 GIT tree has latest-and-greatest source, so stability is not guaranteed. If you run into errors, please use a 'Stable Release' instead before filing a bug.

You need to follow the below steps to git clone MIC2:

<pre>
git clone git://gitorious.org/meego-developer-tools/image-creator.git
</pre>

Build and install:

<pre>
cd image-creator
make clean
make
sudo make install
</pre>

You should add the repo for mic2 then run

<pre>
sudo ./tools/mic-check-alldeps
</pre>

to check/install all the depended packages, otherwise mic2 can't work normally.

== Running mic-image-creator ==

Configuration of images is based on kickstart, the format used for unattended installation in Fedora and Redhat.

Super user privileges are needed. The tool is more or less self-documented, use the --help option to see options.
<pre>
sudo mic-image-creator --help
</pre>

=== Creating Supported Image Types ===

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

To obtain the official Meego .ks files, go here: TO-DO-LINK

'''Create Livecd Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=livecd --cache=mycache
</pre>

This tells image-creator to use the kickstart file default.ks to obtain info about which packages to download and include in the image, and --cache is the directory on your local machine which will host a cache of these packages. The cache is very useful if you are remote to the server and reduces the amount of downloaded packages next time you create an image. Next time the command is run, this cache will simply be 'updated' if there are changes, rather than re-downloading from the repositories again.

The output of this command will be a file named meego-1.0-default-XX.iso created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

To burn it onto a USB stick, just run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.0-default-XX.iso
</pre>

'''Create Moorestown NAND Image'''

!! This still needs to be done !!
Please refer to the section dedicated to this topic below.

'''Create Liveusb Image'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --cache=mycache
</pre>

A file named meego-1.0-default-XX.usbimg will be created. To burn it onto a USB stick, run the following command, assuming the USB stick is /dev/sdb in your system:

<pre>
sudo mic-image-writer meego-1.0-default-XX.usbimg
</pre>

This image has a FAT file system and can be mounted easily on Windows and other OSes.

'''Create Liveusb Image Interactively'''

<pre>
sudo mic-image-creator --config=default.ks --format=liveusb --interactive --cache=mycache
</pre>

It directly creates a MeeGo live usb stick.

Liveusb image can be created in two different ways, interactive and non-interactive (default). When running MIC2 in a non-interactive mode, MIC2 creates a USB images file that can be copied directly into a USB stick. The non-interactive mode can be used for daily build or automated testing. The interactive mode will write the images onto a USB disk, it will detect if a USB stick is available and detects and verifies a partition is available. If two or more USB devices are present, you will be asked to select the target device. This way won't destroy existing content of USB stick unless it founds no appropriate partition, end user should use it to create live USB.

'''Create Loop Image'''

This is the simplest image format available. Such images can be loop mounted and chrooted into, for example, to build applications or for debugging purposes.

<pre>
sudo mic-image-creator --config=default.ks --format=loop --cache=mycache
</pre>

A file named meego-1.0-default-XX.img is created. You can use below to mount it and chroot into it.

<pre>
sudo mount -o loop meego-1.0-default-XX.img /mnt
sudo chroot /mnt su -
</pre>

'''Create KVM Image'''

Can be used with QEMU or other VMM applications to launch MeeGo as a virtualized instance.

<pre>
sudo mic-image-creator --config=default.ks --format=raw --cache=mycache
</pre>

A file named meego-1.0-default-XX folder with a meego-1.0-default-XX-sda.raw image is created. For optimal results, use this feature in a machine with VT support and enable it in the BIOS.

If you use Fedora or openSUSE, run the following command to launch the image into MeeGo KVM virtual machine:

<pre>
sudo qemu-kvm -m 512 -boot c -hda meego-1.0-default-XX-sda.raw -std-vga
</pre>

If you use Ubuntu, run the following command launch image:

<pre>
sudo kvm -m 512 -boot c -hda meego-1.0-default-XX-sda.raw
</pre>

'''Create VMDK Image'''

VMDK images can be loaded into Vmware or Vmware player. MIC2 also generates a VMX file that has image configuration and can be used to launch the image in Vmware by just clicking the file. If you have vmplayer, it should open automatically.

<pre>
sudo mic-image-creator --config=default.ks --format=vmdk --cache=mycache
</pre>

A file named meego-1.0-default-XX folder with both meego-1.0-default-XX-sda.vmdk image and meego-1.0-default-XX-sda.vmx is created. Just run vmware or vmware player, and select the generated vmx file.

=== KickStart Files (configuration files used for image creation) ===

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below.

====Official Meego .ks files====

The official Meego .ks files are here:

*For ARM based Nokia N900: http://repo.meego.com/MeeGo/devel/n900/images/
*For Intel Atom based netbook and handset (Moorestown): http://repo.meego.com/MeeGo/devel/trunk/images/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

====Modifying your .ks====

Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

'''''Partition, Setup and Bootloader options'''''

''Example''

<pre>
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego --defaultdesktop=xfce
user --name meego --groups audio,video --password meego
</pre>

These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.

'''''Repos'''''

This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

''Example''

<pre>
# This is a comment

# My first repo
repo --name=trunk --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo --name=<repo-name-2> --baseurl=< url | local-repo-dir >
</pre>

'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command:

<pre>
createrepo -d <local-dir>
</pre>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

'''''Adding Packages and Package Groups'''''

''Example''

<pre>
%packages

# Example adding pkg groups

@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>

# Example adding individual pkgs

kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end

</pre>

This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the examples above. Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file. Defined therein are package group names, and what packages are included in each package group. The Meego package groups are standard, and cannot be changed. You can, however, define your own package groups in your own non-Meego repos if you are using those.

Please see here for more info on defining package groups in repositories: TO-DO-LINK

You can also add individual package names to be included in the image as you can see from the second part in the above example.

'''''Important Note about how MIC2 picks a package when different versions are available'''''

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

''Example''

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0

MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file.

<pre>
Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

</pre>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

''Example''

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

''Example''

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

'''''Removing Packages'''''

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

''Example''
<pre>
%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end
</pre>

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. E.g. if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

'''''Post scripts'''''

You can also specify post-scripts to be run after the image is installed.

''Example''
<pre>
%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*

# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf

%end
</pre>

====Proxy settings for the repos in .ks====

An option you might find useful if you're behind a firewall is the --proxy flag for the "repo" definition. You can specify it in the .ks as follows:

repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport/ --proxyuser=proxyusername
--proxypaswd=proxyuserpassword

If you are behind a firewall, you don't need to set proxyuser and proxypasswd, like:

repo --name=meego --baseurl=http://repo.meego.com/trunk/repo/ia32/os/ --proxy=http://proxyhost:proxyport

'''Note:''' You can also insert this in your sudoers config:

<pre>
$ sudo visudo

Add: Defaults env_keep += " no_proxy http_proxy ........."
</pre>
so sudo will adhere to the no_proxy and proxy settings.

=== MIC2 Configuration file ===

MIC2 options can be specified in a global configuration file ('''/etc/mic2/mic2.conf''') and local configuration file ('''$HOME/.mic2.conf''') where you can specify
* Repository configuration
* proxy settings
* cache directories and
* other variables
that you normally would have to re-type in your command-line.

The two configuration files have the same format, /etc/mic2/mic2.conf is global, no matter whoever is running MIC2, this configuration file will be read first, $HOME/.mic2.conf is just valid for current user, every user can have their own settings.
The final configuration is a combination of two configuration files, options in '''$HOME/.mic2.conf''' will override those from '''/etc/mic2/mic2.conf'''. Options from command line have the highest priority.
If an option is specified on the command line, the same option in both configuration files, global and local will be ignored.

Below is an example you can cut-and-paste, and reuse for your needs:

<pre>
[main]
cachedir=/home/user1/mycache
tmpdir=/home/user1/mystorage/tmp
outdir=/home/user1/mystorage
proxy=http://my.proxy.com:911/
no_proxy=localhost,127.0.0.0/8,.mysite.com,172.16.0.0/16
</pre>

''cachedir'' = directory where the cached repo(s) will reside. With this variable set, you do not need to pass the --cache flag in the command-line.

''tmpdir'' = temporary directory used by MIC2 when creating images. With this variable set, you do not need to pass the --tmpdir flag in the command-line.

''outdir'' = where your images will reside once they are created. With this variable set, you do not need to pass the --outdir flag in the command-line.

''proxy'' = specify your proxy if you're behind a behind a firewall.

''no_proxy'' = specify what domains should not sure the proxy setting.

''image_format'' = specify image format.

''default_ks'' = specify a default kickstart file, there are several kickstart files provided in repository http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/

'''Note:''' When specifying proxy and no_proxy, you do not need to use the --proxy flag in your .ks files when referring to repos.

In configuration files, you also can specify one or multiple repositories, for example:

<pre>
[trunk]
name=trunk
baseurl=http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/
enabled=1
</pre>

Once there is this reposiroty info in your configuration files, and both image_format and default_ks are set, you can just run "sudo mic-image-creator" to create a image, there isn't any extra argument needed.

=== Use Bootstrap ===

MIC2 highly depends on yum and librpm, but different Linux distributions used diffrent yum and librpm versions, so MIC2 has some compatibility issues on OpenSUSE, Ubuntu and Debian, bootstrap is just for fixing these compatibility issues.

bootstrap is a minimal MeeGo file system, MIC2 can run very smoothly on it using chroot mode. You can use the below command to create a bootstrap:

<pre>
sudo mic-create-bootstrap -n trunk -k /your/repo/cache/path -r http://repo.meego.com/MeeGo/devel/trunk/repo/ia32/os/ -o /your/final/bootstrap
</pre>

-n is used to specify repository name, if you have its cache before, it can reduce runtime dramatically to use it with -k option, -k is used to specify your repository cache dir, -r is used to specify MeeGo main repository.

Once you created your bootstrap, you can use this bootstrap to run MIC2 as follows

<pre>
sudo mic-image-creator --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

Alternatively, you can create and use bootstrap in one mic-image-creator run as follows

<pre>
sudo mic-image-creator --build-bootstrap --bootstrap=/your/final/bootstrap --format=livecd --config=default.ks --cache=/your/repo/cache/path
</pre>

== Running mic-image-writer ==

mic-image-writer writes a Meego image to a USB disk. It is a safe alternative to dd. dd is really a very dangerous tool.

mic-image-writer can run in both console mode and GUI mode. It can decide which mode to run, according to current system environment. You can also use a given option to force it to run in some other mode. Run 'mic-image-writer --help' to get usage information:

<pre>
Usage: mic-image-writer [options] [image file]

Options:
-h, --help Show this help message and exit
-c, --console Run in console mode
-g, --gui Run in GUI mod
</pre>
Here is a run example in console mode:

<pre>
$ sudo mic-image-writer meego-xxx.img
Available usb disk:
[1] /dev/sdc: SanDisk USB Flash Drive
[2] /dev/sdb: SanDisk U3 Cruzer Micro
Please choice [1..2] ? 2
Source: /myhome/meego-xxx.img
Target: /dev/sdb
Image size: 559 MB
Estimated time: 55 seconds
Elapsed time: 64, progress: 100% 8944+0 records in
8944+0 records out
586153984 bytes (586 MB) copied, 63.0486 s, 9.3 MB/s
</pre>

mic-image-writer can estimate how long it will take to write the given image to your USB disk and reports current writing progress. It automatically unmounts your USB disk, if it is mounted. If your USB can't be unmounted, it will terminate.

If you love UI mode, you can run it in X enviroment. The command with the added -g flag:

<pre>
sudo mic-image-writer -g meego-xxx.img
</pre>

Image name is optional.

== Running mic-image-convertor ==

It's very easy to use:

<pre>
sudo mic-image-convertor --source-image=InputImage --target-format=Targegformat

sudo mic-image-convertor -I InputImage -T Targegformat
</pre>

For example, to translate a KVM raw image to livecd image, just type:

<pre>
sudo mic-image-convertor --source-image=meego-core-200902200545/meego-core-200902200545-sda.raw --target-format=livecd
</pre>

A new livecd image of meego-converted-from-raw-200902201804.iso is generated. The tool can detect the type of input image, either raw or vmdk.

This tool is very useful. For example, the developer can launch a virtual machine running MeeGo v2 and make whatever changes on the virtual system like yum install/remove a package, scp a source tarball to VM and build and try, and etc. Then with a simple "sync" or shutdown of VM, the VM image now contains his changes. With this tool, the VM image can be transformed to a live image and burned to a USB flash disk. Now developers can have final verifications in a target device, with changes in the live system.

== Running mic-chroot ==

There are two major usage models for mic-chroot for developers.

'''chroot directly into the image to use it as a development environment, then optionally create a new image based off of your changes'''
<pre>
sudo mic-chroot -c livecd meego-core-200903131337.iso
</pre>

The above command would present a chroot, using the livecd image, to developers with some bind mounts like /proc /sys /dev/pts and /parentroot. With those bind mounts, developers now can easily exchange files in chroot env with host /parentroot, and conduct yum install, yum remove and any other network related operations. After done and typing "exit", a new live ISO image is created from the chroot env with the changes developers made.

'''Unpack and modify the image's filesystem (which you can save), and create a new image based off of your changes'''

Sometimes developers want to keep the chroot env so that they can do multiple changes in that root file system at different times. So they want to execute following:

<pre>
sudo mic-chroot -s my-chroot-fs --unpack-only meego-core-200903131337.iso --bind-mounts=/proc:/proc;/:/parentroot;/sys:/sys;/dev/pts:/dev/pts
</pre>

The above creates a folder 'my-chroot-fs' in the current directory, using the chroot env from the livecd image. Of course if developers forget add the --bind-mounts options, they must manually do some bind mounts themselves like for /proc /sys /dev/pts to use network and run many commands. Don't forget copying /etc/reslov.conf into my-chroot-fs to use DNS. Now at any time developers think is time to create an image from the chroot env, just execute following to create a livecd image

<pre>
sudo mic-chroot -c livecd --convert-only my-chroot-fs/
</pre>

== Enabling Autoinstallation ==

You need to copy a kickstart file into /root/mic2-ks.cfg which is used for
automated installation of the image. To activate autoinstall mode, boot with autoinst on the command line
or add --menus=autoinst to the bootloader directive in the kickstart file you use to
create the image.

= Known issues =

* MIC2 is not compatible with Ubuntu 8.04 (Yum package compatibility)
* MIC2 is not compatible with the initial Ubuntu 9.04. Make sure you have package libsqlite3-0 of 3.6.10-1ubuntu0.2 or later.
* MIC2 has some issues on Debian, please refer to [[MIC on Debian]] to get installation instructions

= Troubleshooting =

You can file a bug on http://bugzilla.meego.com/enter_bug.cgi?product=Development%20Tools (Note: you should select MIC for component) if you run into any MIC2-related issue, bugzilla can track your issue faster and more efficiently.

===libgcc related issues===
<pre>
libgcc_s.so.1 must be installed for pthread_cancel to work"

"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error occurs when MIC2 is unable to find the proper version of libgcc. This usually happens on x86_64 systems - MIC2 is looking for the 32 bit version of libgcc, but only the 64 bit version is installed. Installing the 32 bit version of libgcc should resolve this.

===General squashfs issues===
<pre>
"Error: failed to create image : '/sbin/mksquashfs /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin /var/tmp/imgcreate-FKCSsk/iso-u8xCPh/LiveOS/osmin.img' exited with error (-6)
</pre>

This error can also be an issue with the syslinux package. Try updating to the latest version for your distro.

===device-mapper issues===
<pre>
unable to remove open device
</pre>

This is a race condition with device-mapper in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=506644. Usually rerunning the MIC2 command will resolve this.

= Advanced Hacking Tips =

===replace kernel in live image===

<pre>
$sudo mic-image-convertor --source-image=<your-netbook.img> --target-format=livecd --shell
</pre>

This command will give you a chroot environment of MeeGo, you can follow the below steps to replace the default kernel with a new one.

1). remove the old kernel

<pre>
# rpm -e kernel-netbook
</pre>

NOTE: execute the above command in chroot environment.

2). copy new kernel to chroot environment of MeeGo

<pre>
$sudo cp /path/to/kernel-*.rpm /var/tmp/imgcreate-*/install_root/
</pre>

NOTE: execute the above command in your host system.

/path/to/kernel-*.rpm is your new kernel to install, /var/tmp/imgcreate-*/install_root/ is the directory where chroot MeeGo mounted on.

3). install the new kernel

<pre>
# rpm -ivh /kernel-*.rpm
# rm /kernel-*.rpm
</pre>

NOTE: execute the above command in chroot environment.

After that, you can find out the new kernel in directory /boot/.

4). update contents of isolinux

<pre>
$sudo cp /var/tmp/imgcreate-*/install_root/boot/initrd-*.img /var/tmp/imgcreate-*/iso-*/isolinux/initrd0.img
$sudo cp /var/tmp/imgcreate-*/install_root/boot/vmlinuz-* /var/tmp/imgcreate-*/iso-*/isolinux/vmlinuz0
</pre>

NOTE: execute the above command in your host system.

5. create an new image
<pre>
#exit
</pre>
NOTE: execute the above command in chroot environment.

After all the above steps, you got an new image.