launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 29 November 2011 00:17, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> 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