Michael Hudson <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
