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