launchpad-dev team mailing list archive

[Tim Penhey <tim.penhey@xxxxxxxxxxxxx>]

On Wed, 07 Oct 2009 08:48:41 Julian Edwards wrote:
> Hey Tim
> 
> We said we'd have a chat about the BFB requirements and design before
>  deciding on a sprint.
> 
> As I understand it, the things we want are:
> 
>   * A PPA picker on the source package branch page with a "Build" button
>     (and we might want to extend this to a distro upload at some point)

I agree with Jono that we should have some archive picker, but I'm not against 
having a reduced functionality initial widget, as long as we are careful not 
to exclude the future when making the initial widget.  I have found in the 
past that it is often easier just to do the whole thing at the start rather 
than adding limiting code early on.

I think we should have a separate discussion around what an archive picker 
might look like, and how various restrictions would play out.  For example, if 
I have a package branch of lucid bzr, then how would we limit the archives 
that it could be built into?

>   * The button will create a job request to run `bzr builddeb` or
>  equivalent.

That is probably the easiest bit.  The job creation.  The more interesting bit 
also relates to something else Jono mentioned, and that is how to report the 
status of a long running job.  Ideally on the branch page we'd show the 
progress (or lack of progress) of any build job for the branch.  Having a nice 
(standard) way to show pending or running jobs would also be good for things 
like the branch upgrade job.
 
>   * The job will need to run in a secure environment; the existing Soyuz
>  build farm is most appropriate for this.  It will need a new set of
>  chroots to run this command (or any arbitrary jobs I guess).

I hand this entirely off to you :)

>   * We will need to make our buildd-manager to handle this generic job type
>     in tandem with the other package builds.  This is where most of the
>  work lies.

And this.

>   * The finished source package will be uploaded to Soyuz as a regular
>  source upload, however since it won't be signed we need a new
>  identification and trust mechanism to identify the person who clicked the
>  button as the uploader.

And this.

>   * It's also possible that the branch build will fail so an email should
>  be sent in that case.

Aaron has done some work on the job infrastructure recently to make it easy to 
send emails for failures.  Hooking into that should be quite easy.

>   * At this point the regular Soyuz package build mechanisms continue as
>     normal.
> 
> I've made no mention of any UI beyond the first point, as I'm not sure we
>  need anything else.  We can enhance the existing /builders page to give
>  more info on waiting BFBs.  Can you think of any other UI changes we'd
>  need?

Just the updates to the branch page itself.  At least in the early stage where 
we are just operating off a job.

We will want to plan for some linking ability between a branch and an archive 
to allow the build jobs to be created whenever the branch is pushed to.

> As far as I can see, most of the work needs to be done in the Soyuz domain.
> We'll also need some assistance from the IS guys to get the appropriate
> chroots made to their security standards.
> 
> Did I miss anything?

James mentioned that there could well be confusion with some developers where 
their package builds locally but not in the LP build farm.  I'd suggest that 
we'd want to provide some flags to the build deb plug-in so it could simulate 
the LP build environment with its non-downloading and hookless bits.  This 
would then allow the devs to simulate the LP build environment locally at 
least.

One thing I am not clear on yet is whether the package branch contains enough 
information itself to just be built.  If yes, then great, a simple job should 
be all we need form the code point of view.  If more information is needed, 
we'd need to work out how to capture that information and also how it would 
work from the push to build point of view.

You are right, most of this work does land on the soyuz side of the fence.

Tim