QA/Automation/Projects/Mozmill Automation/On Demand Test Framework/CI Documentation

NOTE

This is a work in progress and should be more detailed soon

Overview

Master Responsibilities

• Come up with a build environment artifact
  • Centralized on master to limit dependencies
  • Master itself is configured as a build node specifically to do these envs

• Create core jobs on itself via Jenkins API
  • Grabs from davehunt's github repo
  • Uses python-jenkins to update the jobs on itself
  • Will leave old jobs behind if a platform is removed from requirements

• Run the job cascade from the configuration file via the on-demand job

• Push jobs to slaves

Slave Responsibilities

• Pull build env artifact from master
  • Copy Artifact plugin

• Run the test jobs (mozmill scripts)

• Mozmill scripts push to brasstacks (slaves need network visibility to results repo)

• Currently one build executor per node because no simultaneous mozmill. New focus monitor changes gives us a shot at parallelism

Installation

Install Prerequisites

• Java
• Python
• pip (for jenkins-python)
• python-jenkins (http://pypi.python.org/pypi/python-jenkins/0.2)
• Git
• curl
• python-dev
• Jenkins

Instructions

1. Install and run Jenkins (java -jar jenkins.war)
2. Open http://localhost:8080
3. Install the following plugins (Manage Jenkins > Manage Plugins)
   • Mercurial Plugin
   • Green Balls
   • Xvnc (for Linux slaves)
   • Parameterized Trigger
   • GitHub
   • Git
   • Show Build Parameters
   • Rebuild

Configuration

Master

SSH login

1. Generate public/private keys using RSA
2. Keep the public key

Jenkins

1. # of executors to 1

Windows Slave

Jenkins

1. # of executors to 1

Linux, OS X Slave

SSH login

1. Create activated_keys with master's public key

Jenkins

1. # of executors to 1

Questions/Proposals

1. A plugin like the following could help us to prepare the workspace for testruns across slaves of the same platform. Downloads will not have to happen in parallel by the slaves but will all be done by the "master" and handed over to the slaves
2. Do we want to place the master's Jenkins folder under the home directory of the user? Therefore we should work with the .war file instead of installing a native jenkins build onto the system?
3. Do we have a fallback strategy if something is broken? Could we still trigger/execute tests manually for a given platform?

Jobs