Difference between revisions of "Mozilla BuildBot Trending"

From CDOT Wiki
Jump to: navigation, search
Line 3: Line 3:
  
 
==Project Plan==
 
==Project Plan==
This project will be broken into many distinct parts.  The first seven parts of the system will be completed as releases for DPS911 and the remainder will be completed during the summer of 2009.
+
This project will be broken into many distinct parts.  The first seven parts of the system will be completed as releases for DPS911 and the remainder will be completed during the summer of 2009.  As I don't know what this project holds, I am a lot more solid about details of the first few releases.  As I can get more detail about the releases, I will update this page.
  
===1 - Setup Local Buildbot===
+
===Setup Local Buildbot===
 
This step will be to set up a build bot at CDOT.  This system will serve a dual purpose of having a local Buildbot system for use in CDOT as well as allowing me to test changes to buildbot.  The primary purpose for this Buildbot setup is to test changes.  If having a local stable buildbot is found to be useful, one can be set up.  Initially, this local Buildbot will have a single CentOS Slave, though, as time goes on more slaves will be added.   
 
This step will be to set up a build bot at CDOT.  This system will serve a dual purpose of having a local Buildbot system for use in CDOT as well as allowing me to test changes to buildbot.  The primary purpose for this Buildbot setup is to test changes.  If having a local stable buildbot is found to be useful, one can be set up.  Initially, this local Buildbot will have a single CentOS Slave, though, as time goes on more slaves will be added.   
  
 
I plan to put the buildbot master on Australia and use either KVM based Virtual Machines or bare metal machines.
 
I plan to put the buildbot master on Australia and use either KVM based Virtual Machines or bare metal machines.
  
===2 - Make a (successful) change to BuildBot===
+
===Make a (successful) change to BuildBot===
 
This step involves making a change to buildbot which doesn't horribly break the system.  By this release I would like to have at least one Windows and one OS X machine as slaves to ensure that nothing is broken for the individual build systems.  This step will serve as a learning tool for my next step and make me familiar with the BuildBot codebase
 
This step involves making a change to buildbot which doesn't horribly break the system.  By this release I would like to have at least one Windows and one OS X machine as slaves to ensure that nothing is broken for the individual build systems.  This step will serve as a learning tool for my next step and make me familiar with the BuildBot codebase
  
===3 - Patch BuildBot to add timestamps===
+
===Patch BuildBot to add timestamps===
I will write a patch for BuildBot that inserts timestamps into build logs to allow for more
+
I will write a patch for BuildBot that inserts timestamps into build logs to allow for more detailed timing information and to allow the logs to be parsed by a tool to be written which will do trending.  The goal of this patch is to get make this patch acceptable to upstream.
 +
 
 +
===Design Database Schema===
 +
The log parser will need somewhere to put the information it finds in the logs.  Currently, the best place to put this is a database.  I will design the schema required for storing data.  My goal is to have this be able to store information for different branches, each with their own history.  This release will be in the form of a diagram illustrating the design.
 +
 
 +
===Create DB===
 +
This release will be a database generation script based on the above schema.  I will target either MySQL or Postgres depending on what is preferred.

Revision as of 00:07, 18 January 2009

Build Bot Trending

Currently, it is very difficult to figure out how much time is being spent in each part of the build system. Very high level tasks are timed, like checkout, build, test, but individual steps aren't being timed. For DPS911, this project will aim to create a local buildbot environment, patch buildbot to insert granular timestamps into logs, design a database for timing information and write a log parser to insert data into the database. During Summer 2009 a system to display trending information will be completed as well as historical view for buildbot.

Project Plan

This project will be broken into many distinct parts. The first seven parts of the system will be completed as releases for DPS911 and the remainder will be completed during the summer of 2009. As I don't know what this project holds, I am a lot more solid about details of the first few releases. As I can get more detail about the releases, I will update this page.

Setup Local Buildbot

This step will be to set up a build bot at CDOT. This system will serve a dual purpose of having a local Buildbot system for use in CDOT as well as allowing me to test changes to buildbot. The primary purpose for this Buildbot setup is to test changes. If having a local stable buildbot is found to be useful, one can be set up. Initially, this local Buildbot will have a single CentOS Slave, though, as time goes on more slaves will be added.

I plan to put the buildbot master on Australia and use either KVM based Virtual Machines or bare metal machines.

Make a (successful) change to BuildBot

This step involves making a change to buildbot which doesn't horribly break the system. By this release I would like to have at least one Windows and one OS X machine as slaves to ensure that nothing is broken for the individual build systems. This step will serve as a learning tool for my next step and make me familiar with the BuildBot codebase

Patch BuildBot to add timestamps

I will write a patch for BuildBot that inserts timestamps into build logs to allow for more detailed timing information and to allow the logs to be parsed by a tool to be written which will do trending. The goal of this patch is to get make this patch acceptable to upstream.

Design Database Schema

The log parser will need somewhere to put the information it finds in the logs. Currently, the best place to put this is a database. I will design the schema required for storing data. My goal is to have this be able to store information for different branches, each with their own history. This release will be in the form of a diagram illustrating the design.

Create DB

This release will be a database generation script based on the above schema. I will target either MySQL or Postgres depending on what is preferred.