wiki:NineNotes

Nine's architecture

Side Note

There is only a general description available + source code.

The current source code seems to be a result of over engineering.

Hopefully, practical notes

"DB + MQ" is a black box that provides four ways to interact:

update

create/update data in the database; this is an internal (Python-only, in-process only) interface

using this interface usually results in emitting a set of events

read
read an object or a collection of objects
control
operations triggered via the API from outside the process: rebuild, cancel, force, graceful shutdown, clean shutdown, etc.
events
entities can subscribe to events to perform their work

Components

All Buildbot components are built around the same pattern:

  • wait for a "thing" to happen using an interface that depends on the component
  • (optionally) get some data from "DB + MQ" using "READ" interface
  • create a new object/update an existing object in "DB + MQ"

Each component is configured using data from master.cfg: this could be just plain data or some classes/functions to extend the functionality of a stock component.

Some components (change source, schedulers) may only have one instance to avoid duplication of work. Some components (web UI, builders) have many instances for load-balancing purposes

XXX: anything else?

Below is a high level desription of different entities described in terms of:

trigger
what triggers an activity
get
what extra data is required from db
update
what data is written to db
config
what kind of configuration data is essential
other
other relevant bits

Change Sources

trigger

Either timer tick (for polling change sources) or an external event (usually delivered via http)

The latter can be delivered via a special plugin of Web UI (not implemented).

get
this component kind does not seem to need to read anything from the DB
update
create a new change
configuration
mostly plain data. however some change source might need code configuration (e.g. svn)
other
nothing (?)

Schedulers

trigger
"New change" event, timer, or inbound event (triggerable) Or a mix! (NightlyTriggerable with onlyIfChanged, for example)
get
depending on what payload the event brought, change description
update
create new build requests and build set
configuration
lots. both plain data and code
other
nothing (?)

Status Targets

trigger
"Build completed" and/or "Build set completed" events (It's much deeper than this actually - all the way down to log appends --dustin)
get
build information (what exactly depends on the event payloads)
update
nothing
other

performs an operation on external system:

  • sends a mail
  • performs an external system API call
  • etc

Anything Else?

Last modified 4 years ago Last modified on Feb 18, 2015, 8:12:25 PM