launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #00798
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