Difference between revisions of "Mozilla BuildBot Trending"

From CDOT Wiki
Jump to: navigation, search
(Project Wiki Pages)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Build Bot Trending=
+
== Project Name ==
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, I 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.
+
 
 +
Mozilla BuildBot Trending
 +
 
 +
== Project Description ==
 +
 
 +
This project aims to provide more information from the build system.
 +
 
 +
== Project Leader(s) ==
 +
 
 +
[[User:John64|John Ford]] is leading this project
 +
 
 +
== Project Contributor(s) ==
 +
 
 +
Name(s) of people casually working on the project, or who have contributed significant help.  Include links to personal pages within wiki
 +
 
 +
NOTE: only Project Leader(s) should add names here.  You '''can’t''' add your own name to the Contributor list.
 +
 
 +
== Project Details ==
 +
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.
 +
 
 +
== Project Wiki Pages ==
 +
[[Mozilla_BuildBot_Trending/BuildBot | BuildBot]] - Information regarding the BuildBot setup <br />
 +
[[Mozilla_BuildBot_Trending/ToDo | To Do]] - List of things that need to be done.<br />
 +
[[Mozilla_BuildBot_Trending/Patches | Patches]] - Some patches I have written<br />
 +
[[Mozilla_BuildBot_Trending/Snippets | Snippets]] - Useful code I have written for this project<br />
  
 
==Project Plan==
 
==Project Plan==
This project will be broken into many distinct parts.  The first seven parts of Step 2 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 have more solid details of the first few releases.  As I work through the first few parts of the system, I will be able to add detail to this page.
+
This project will be broken into many distinct parts.  Step 2 will be completed for DPS911.  As I don't know what this project holds, I have more solid details of the first few releases.  As I work through the first few parts of the system, I will be able to add detail to this page.
 
===Step 1===
 
===Step 1===
 
====Name In====
 
====Name In====
Line 10: Line 34:
 
I guess this is what I am doing here
 
I guess this is what I am doing here
 
===Step 2===
 
===Step 2===
====DPS911 Release - Setup Local Buildbot====
+
====0.142 - Setup Local Buildbot====
 
This step will be to set up buildbot 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.  If having a local stable buildbot is found to be useful, an additional 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 buildbot 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.  If having a local stable buildbot is found to be useful, an additional 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.
  
====DPS911 Release - Make a (successful) change to BuildBot====
+
====0.285 - Make a (successful) change to BuildBot/Twisted====
 
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
  
====DPS911 Release - Patch BuildBot to add timestamps====
+
====0.428 - Patch BuildBot to add timestamps====
 
As I understand it, buildbot uses [http://twistedmatrix.com/trac/ Twisted]'s twisted.python.log.msg() method to log everything.  I will modify this function to interface with some sort of information gathering system and create a configuration option in buildbot to use this option.  The patches which will accomplish this will be submitted upstream.
 
As I understand it, buildbot uses [http://twistedmatrix.com/trac/ Twisted]'s twisted.python.log.msg() method to log everything.  I will modify this function to interface with some sort of information gathering system and create a configuration option in buildbot to use this option.  The patches which will accomplish this will be submitted upstream.
  
====DPS911 Release - Design Database Schema====
+
====0.571 - 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.
 
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.
  
====DPS911 Release - Create DB====
+
====0.714 - Log to Database Connector====
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.
+
This release will involve creating a way of getting data from the buildbot into the database.  Currently, a parsing program is planned which will run on the logs of buildbot which have had timestamps addedOther options include having buildbot directly interface with the database and wrapping the individual build tools.
 
 
====DPS911 Release - Start writing log parser====
 
This release involves writing the initial part of a log parser which will take information from the log files and populate the database.  Another potential option is to modify the buildbot patch to directly insert into the database.  If buildbot is going to directly insert into the database it might be a good idea to write a high performance caching program in C so the build is not affected by database overhead.  This C program would then write to the database as needed.
 
 
 
====DPS911 Release - Finish writing log parser====
 
This release will complete the log parsing solution from the previous releaseThis will be the final release of the DPS911 and the rest of the system will be implemented in during the Summer.
 
  
====Design UI for trending information====
+
====0.857 - Design UI for trending information====
 
This step involves designing the UI for the trending information.  It will include relevant information which is known to be representable from the data collected earlier.
 
This step involves designing the UI for the trending information.  It will include relevant information which is known to be representable from the data collected earlier.
  
====Implement UI for trending informaion====
+
====1.00 - Implement UI for trending informaion====
 
I will implement this UI.  I plan to make a web front end to the system.
 
I will implement this UI.  I plan to make a web front end to the system.
  
 
===Step 3===
 
===Step 3===
 
This step will not be broken down into distinct chunks yet as I would like to get familiar with buildbot and the overall build-test cycle before I start planning this part of the system.  This step involves keeping track of historical information found during builds and their error logs.  This portion of the system will help isolate recurring issues by making note of which machines are falling which test runs and why.  A potential idea is to integrate some sort of 'learning' mechanism to help find patterns in build output which are known to be caused by a specific problem.
 
This step will not be broken down into distinct chunks yet as I would like to get familiar with buildbot and the overall build-test cycle before I start planning this part of the system.  This step involves keeping track of historical information found during builds and their error logs.  This portion of the system will help isolate recurring issues by making note of which machines are falling which test runs and why.  A potential idea is to integrate some sort of 'learning' mechanism to help find patterns in build output which are known to be caused by a specific problem.

Latest revision as of 01:04, 13 February 2009

Project Name

Mozilla BuildBot Trending

Project Description

This project aims to provide more information from the build system.

Project Leader(s)

John Ford is leading this project

Project Contributor(s)

Name(s) of people casually working on the project, or who have contributed significant help. Include links to personal pages within wiki

NOTE: only Project Leader(s) should add names here. You can’t add your own name to the Contributor list.

Project Details

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.

Project Wiki Pages

BuildBot - Information regarding the BuildBot setup
To Do - List of things that need to be done.
Patches - Some patches I have written
Snippets - Useful code I have written for this project

Project Plan

This project will be broken into many distinct parts. Step 2 will be completed for DPS911. As I don't know what this project holds, I have more solid details of the first few releases. As I work through the first few parts of the system, I will be able to add detail to this page.

Step 1

Name In

I need to come up with a name :)

Break It Down

I guess this is what I am doing here

Step 2

0.142 - Setup Local Buildbot

This step will be to set up buildbot 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. If having a local stable buildbot is found to be useful, an additional 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.

0.285 - Make a (successful) change to BuildBot/Twisted

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

0.428 - Patch BuildBot to add timestamps

As I understand it, buildbot uses Twisted's twisted.python.log.msg() method to log everything. I will modify this function to interface with some sort of information gathering system and create a configuration option in buildbot to use this option. The patches which will accomplish this will be submitted upstream.

0.571 - 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.

0.714 - Log to Database Connector

This release will involve creating a way of getting data from the buildbot into the database. Currently, a parsing program is planned which will run on the logs of buildbot which have had timestamps added. Other options include having buildbot directly interface with the database and wrapping the individual build tools.

0.857 - Design UI for trending information

This step involves designing the UI for the trending information. It will include relevant information which is known to be representable from the data collected earlier.

1.00 - Implement UI for trending informaion

I will implement this UI. I plan to make a web front end to the system.

Step 3

This step will not be broken down into distinct chunks yet as I would like to get familiar with buildbot and the overall build-test cycle before I start planning this part of the system. This step involves keeping track of historical information found during builds and their error logs. This portion of the system will help isolate recurring issues by making note of which machines are falling which test runs and why. A potential idea is to integrate some sort of 'learning' mechanism to help find patterns in build output which are known to be caused by a specific problem.