launchpad-dev team mailing list archive

[Karl Fogel <karl.fogel@xxxxxxxxxxxxx>]

Michael Hudson <michael.hudson@xxxxxxxxxxxxx> writes:
> I'm happy to report that the first visible result of my Build Engineer
> stint is a wiki page explaining in some detail the mysteries of buildbot
> and PQM and testfix mode: https://dev.launchpad.net/Trunk/Glue
>
> I was very happy to be able to write this page; I hope it saves the next
> Build Engineer some serious head scratching :)
>
> Thanks to the various people who commented on earlier versions of the page.

This is a huge help, wow -- I learned a lot from reading the page.

Few questions:

There are no links to code for PQM.  There is even a reference to
https://bugs.edge.launchpad.net/launchpad-foundations/+bug/424060, which
is about PQM, but that bug also does not link to anything that looks
like code for PQM.  The PQM we're using is just https://launchpad.net/pqm,
right?  If so, I'll update the page to point to it.

At another point the page says this:

  "There is a (currently private) branch on launchpad that contains the
   buildbot config and the buildbot-poll.py script.  The buildbot UI is
   currently also private, but this will change, hopefully soon."

(https://code.edge.launchpad.net/~launchpad-pqm/lpbuildbot/trunk is what
the word "branch" links to.)

I can understand why certain internal config data needs to stay private,
but does the whole buildbot config need to be private?  If it were
public, other buildbot-savvy people on this list might be able to point
out possible improvements or optimizations.  (Perhaps this is an awkward
question to ask on a public list, I don't know -- but I'm guessing if
there's some reason that branch should all stay private, the reason why
is not itself particularly private.)

Some other parts of the page need wiki syntax escaping (in some places)
and linkified text (in others):

  The change source we use is the "?BzrPoller" in bzrbuildbot/poller.py
  in the lpbuildbot branch. It is configured with a list of URLs to
  watch and when it sees a new revision in one of these branches, it
  feeds it to buildbot.

  The scheduler we use for the two trunk builders is
  "?AggregatingTestfix". An ?AggregatingTestfix scheduler is configured
  with a branch and watches for changes that affect this branch. When it
  sees a change that affect its branch, it checks to see if the last
  build succeeded or failed. If it failed, then it only starts a new
  build if the commit message contains '[testfix]'.

(I think it's obvious where, so not specifying.)

In this next paragraph, the first sentence implies that the second
sentence is the fullfillment of the "couple of reasons", but I think
it's actually not, right?

  Builbot's built-in "Force Build" button doesn't work for us for a
  couple of reasons. Builds forced using our page have a distinctive
  "reason" attribute that the buildbot-poll.py script looks for using
  our custom XML-RPC method.

(If not, solution might be to start second sentence with "Instead, ".)

Above minor nits aside, that page is a powerful blast of enlightenment,
and I thank you for it.

-K