On 29 November 2011 00:17, Julian Edwards <julian.edwa...@canonical.com> wrote: > On Thursday 10 November 2011 09:46:31 Martin Pool wrote: >> I've just copied what was lib/canonical/buildd into >> lp:launchpad-buildd <https://launchpad.net/launchpad-buildd> and soon >> I'm going to propose a merge to launchpad that makes this a dependency >> and deletes the code from the Launchpad tree. I've already (I think) >> removed all the code-level coupling. > > \o/ > > Thanks for doing this Martin!
Thanks! > >> Still to be done: >> * launchpad needs to treat this as a dependency; i'm thinking >> probably to make it a dpkg dependency because it's not really a lot >> like a python egg I did end up making it a dpkg rather than an egg, largely because it was already packaged that way, that's how it is deployed to the buildds, and there didn't seem much benefit in having two separate packagings. There are two binaries built from one source: python-lpbuildd is the library and launchpad-buildd is all the stuff that configures it to run as a daemon. There is a separate small python-txfixtures as an egg. > I'm not entirely sure it needs to be a run-time dependency; if it is it should > be an optional one since the vast majority of LP runs without it. It should > definitely be a testing dependency though. I don't know how to do that with > dpkg dependencies. At run time, launchpad-buildd does not depend on launchpad nor vice versa. For tests, launchpad-buildd can run its own unit-type tests standalone, and Launchpad's tests rely on python-lpbuildd which they use to start up and test talking to a buildd. >> * launchpad needs to call in to it to run its tests > > We need to be *super* careful that we don't break buildd now it's separate. > The coupling between the buildd-manager and the slave code is far too high and > it's easily broken :( Right, so I haven't deleted any tests, and Launchpad's integration tests still exist and talk to a real buildd. Eventually it would be perhaps good to have a fake implementation that talks the right protocol (to test lp without buildd), a driver that talks that protocol to the buildd to test it alone, and then a harness that tests an entire running system. I think the last is the most urgent: just answering "did that deployment to staging work or not" is super complicated and manual and is the place we had a lot of stalls in deployment. Without that, any introduction of fakes is going to be risky. -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
