← Back to team overview

launchpad-dev team mailing list archive

Re: documentation of our build process

 

Karl Fogel wrote:
> 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.

Thanks, I learnt a lot writing it :)

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

Yes, indeed, that's the PQM we're using.  I'm not sure what revno we're
currently using.

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

Yeah, I don't think there's a deep reason.  The config contains slave
passwords, but given that the only addresses that can connect to the
master are elastic ips we own, they're really not very exciting.

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

It's a wiki, you could have fixed these yourself :)

> 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, ".)

I fiddled with this bit a little.

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

Thanks for the read-through!

Cheers,
mwh



Follow ups

References