Buildbot-1.0 - The Shimmering Vision

In brainstorming what features and functionality will be included in Buildbot-1.0, we developed the following (preliminary) resolutions. RESOLVED

  • That Buildbot is a framework for building distributed testing systems, rather than a configurable application.
  • That Buildbot contains a solid distributed job control system capable of sophisticated job scheduling and control.
    • Including support for sophisticated load-balancing (c.f. #42)
    • Including support for non-Python slaves (for embedded test systems)
    • that is resilient to flaky network connections (c.f. #25)
    • that has a set of alternative strategies for choosing a slave for a build: random (the default), priority based, override point for user provided function.
  • That Buildbot has a scalable persistence backend for storing build results, with an expandable schema. (++)
  • That Buildbot ships with a bunch of useful components, and makes it easy to plug in more:
    • version-control interfaces,
      • more VC-specific properties
      • watch for changes/patches from a patch-submission mailing list
    • build processes,
      • steps that can extract arbitrary information (e.g., filenames) from logfiles
      • more steps for C and Python language (Pylint cf. #259, lint...) and rpmlint for rpm packaging.
      • built-in packaging steps
      • server-side steps, e.g., to copy logfiles or artifacts
    • notification systems,
    • displays,
      • integration with e.g., trac
      • rss/atom feeds
    • controls.
    • leverage Python packaging tools to support distribution of new "apps"
  • That Buildbot uses normal software abstraction techniques (functions, inheritance, etc.) to make the basic use-cases easy while not prohibiting arbitrarily complex configurations.
  • That Buildbot supports an unlimited number of projects, repositories, etc. managed by a single buildmaster instance.
  • That Buildbot has a versatile and highly configurable web interface, including filters to limit the information displayed on a page.
    • The controls on the web interface should provide detailed controls over any triggered builds or other actions
    • Basic configurations can be administered online (++)
    • Implements or supports external access control (who can view the status, the logs, force builds, etc.) (++)
    • That Buildbot can maintain and display arbitrary metadata about process objects (e.g., contact information for buildslaves) (++)
    • That Buildbot should have a way of seeing the queue of builds for a builder, and be able to control them (kill them etc.), it should be able to stop a build rather than relying on stopping the currently running step.
  • That Buildbot provides a sophisticated notion of a "build," which may span multiple slave systems (e.g., a build host and a test host).
    • results and logfiles are appropriately aggregated
  • That Buildbot provides a mechanism for distributing build artifacts (eg the compiled application) for subsequent use inside or outside of buildbot
  • That Buildbot can support configuration parameters specified on the slave side.
  • That Buildbot will carry information from the VC system as deeply into the build process as possible, including displaying any new changes made between periodic builds.
  • That Buildbot should have minimal dependencies on POSIX executables like "cp" or "rm", preferring to accomplish the same tasks natively.
  • That Buildbot can perform in-process reloads, transitioning smoothly from a running configuration to a new on-disk configuration.

Suggestions are from, in alphabetical order:

  • Sebastien Douche
  • John Earl
  • Matisse Enzer
  • Philippe Eveque
  • Ben Hearsum
  • Neil Hemingway
  • Dan Kegel
  • Steve Kinneberg
  • John Koleszar
  • Marcus Lindblom
  • Dustin J. Mitchell
  • Steven Mohr
  • John O'Duinn
  • Terry Rankine
  • Mark Roddy
  • Stefan Seefeld
  • Christian Unger

(This page originally springs from this thread on buildbot-devel])