Automated Build Framework

Related Topics: VirtualBuildBox, Vm1DeploymentPlan

Background

The NTP software has proven to be remarkably portable, running on a huge number of different versions of different OSes over the years.

The size of the NTP build and test farm at UDel has been shrinking over the past few years' time, and there are already a number of platforms we do not have access to for build or test access.

It would be helpful if there was an easy way for people to automatically build new releases of NTP and automatically report back the status of these builds.

Possible Implementation Design

Client Code

Monitor our existing release feed, http://support.ntp.org/rss/releases.xml, via RSS, and when a new release was available the client would fetch the tarball, build the code, and submit the make.log file back to the server.

Server Code

Collect the returned make.log files.

Prepare a webpage with updated reports on the build status of each architecture.

Questions and Discussion

• Should we only work with "registered" clients?
  • It will cut down on abuse/spam.
  • Decision: YES, we only interact with "registered" clients.

• We might want to dynamically limit the number of equivalent build systems.

• It would be useful if clients could indicate if they are capable of doing any debugging.

• How might we support a developer who wants to do some testing of patches that are not yet part of the released code?

Comments

I think it will be better if the client works with registered client and if a user want to register,registering process will take no time eg. taking any mail id as we do in facebook reg.

To limit the number of equivalent system we will have to compare make.log on server side and fix parameters on which two system can be considered equivalent.It can be done based on kernel used or tools used to build ntp.

Debugging will certainly the added feature of client.

We need a language in which server side and client scripting can be done. python and ruby on rails seems a good choice, perl is equally better.

-- RahulKumar - 23 Mar 2009

I just finished a prototype in Ruby. It downloads the newest development version to /tmp, compiles and send make.log to NTP_POST_URL, which is a simple PHP script just to check if the key sent is right and saves the file.

The Ruby script is in http://pastebin.com/f49bbd2cf, and the PHP in http://pastebin.com/f718e165d

There's much more that needs to be done, but it shows basic functionality.

-- VitorBaptista - 29 Mar 2009

Looks good to me Vitor, thanks! Do you have any suggestions on what else we might do to make this even more useful and helpful?

-- HarlanStenn - 29 Mar 2009

Due to the extreme diversity of the platforms supported by NTP I don't think that it will be possible to provide an automated client for every case. The most conservative approach is to make it possible for a participant to manually download the tarball (possibly via an intermediate system), manually run the build process, and manually upload the resulting make.log (again possibly via an intermediate system) using a browser.

-- SteveKostecke - 01 Apr 2009

@Harlan: I was thinking about making this project as general as possible. So, with the same client, you could subscribe to download/compile n projects. This way, with more projects participating, there'll be more users volunteering. Everyone wins. But I think this is beyond the scope of one summer.

-- VitorBaptista - 02 Apr 2009

@Steve: I agree, there should be means to the user do it manually. It shouldn't add much work to the project (mostly none), anyway.

-- VitorBaptista - 02 Apr 2009

I just finished the first draft of the proposal, it's at http://vitorbaptista.com/GSoC2009-NTP.pdf. I also submitted it at http://socghop.appspot.com/student_proposal/show/google/gsoc2009/vitorbaptista/t123865348080. Any comment will be really appreciated.

-- VitorBaptista - 02 Apr 2009

I think we should be able to get some sort of portable script going that will support most any *ix platform. We already require perl for ntp; we might be able to use that for this project.

-- HarlanStenn - 21 Apr 2009

It might also be Really Interesting if this project could have some sort of add-on or plugin that would interface with the http://modules.sf.net project - that way we could specify different versions of different tools, and perhaps get a "menu" or list of what versions of what tools were on any given client.

-- HarlanStenn - 21 Apr 2009

Amar is implementing a buildbot instance for us that should handle these things.

-- HarlanStenn - 2010-03-03

Has anything happened with this project?

-- BrianUtterback - 2012-05-13

I should have an update on this by the middle of next week.

-- HarlanStenn - 2012-05-13

Brian, Amar says he is expecting to start deploying VM system images "today" (Friday) and we should be able to start doing NTP builds on these by early next week.

-- HarlanStenn - 2012-05-18