• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Why

Ubuntu is beginning to manage its source packages as Bazaar branches, as part of the DistributedDevelopment project.

One incredibly important activity for source packages is building them into binary packages that can be downloaded and installed. This spec explains how Launchpad can make this a wonderful experience. In particular, this is important for the DailyBuilds project.

Requirements

• A single button that takes a branch and builds it into a binary package in a PPA or a distribution of the user's choice.
• A record of which branch and revision a package was built from.

User Interface

See the build-branch-to-archive UI design page.

Current db-devel schema

• Why is sourcepackagename on SourcePackageRecipeBuild (when it's already present on the related SPR). Similarly for distroseies. It would be worth a comment here explaining why this is the case.

Dia version

High-Level Implementation and Work-Flow

• The builddeb phase where a branch is converted into a source package needs to happen in a secure environment. This means we need to create a generalised job system on the existing Soyuz build farm which is specified here: BuilddGeneralisation

• The finished source package is then uploaded to the existing upload processor as a normal source package upload. It will need a new way of identifying the uploader based on who requested the job since it's impossible for that person to sign the package.
• At this point the regular Soyuz processing takes over as normal.

We will also need assistance from IS to create an appropriate chroot for the builders that will run the builddeb instead of sbuild. [ACTION] Ask IS about the requirements for this from their security PoV. [ACTION] Confirm with James Westby exactly what needs to happen to convert the branch. Currently it's bzr builddeb but it needs to be something that does not connect to the internet to get more dependencies.

Considerations

• What happens if a branch is deleted and there's a source package referring to it?
• What about private branches/archives?

Implementation

XXX Julian 2009-10-14 I think this section is premature.

1. Given an IBranch and an IArchive by the user, we create a branch job.

2. The branch job has the following information:

   • branch

   • requester

   • archive

   • rev_id -- this is either provided by the user or is the rev_id of the branch's tip at the time of request.

For any given build-to-archive branch job, we:

1. Extract the suite and source package name from the Changelog in the branch. XXX - What if this fails? -- JonathanLange <<Date(2009-08-07T16:19:43Z)>>

2. Based on this information, we fire off a builder, providing it with
   • A branch URL
   • A chroot URL
   • The requester
   • The rev_id
3. The builder then
   1. Pulls the given rev_id of the branch
   2. Grabs the chroot, unpacks it, etc.
   3. Does magic to build the source package (based on bzr builddeb)
   4. Produces:
      • The changes file
      • The dsc file
      • The tar.gz
      • The diff

      • Some information including the requster, branch_url & rev_id waves hands.

4. The dispatcher then pulls this data down & dismantles the builder

5. The dispatcher uploads that information to the relevant archive
6. Done! Soyuz takes care of the rest.

Steps

• Investigate buildd code
• Change buildd code to be much more generic, and thus allow building of source package branches
• Confirm the schema changes for the job table, if any required
• Spec out the user interface for the build button
• Write the dispatcher
• Write modified builddeb worker

Other Plan Items

• Some infrastructure polish. This means more Soyuz implementation.
• Scalability: Julian sees this as a tough issue.
• UI: Michael and Jono are pursuing this.
  • UI mockups are done (see notes above).
  • How much attention will the design review process give to this?
  • How can we define a measure to know we've done a good enough job here?
• Julian feels we need to better define UI workflow.
• Use on/off feature switches.
• Limited rollout.
  • How should this be done?
• Need to get the right hardware in-house.
  • Chase OPs to get the RT done.
• Watch out for feature creep.
• Use Kanban board to summarize feature work?
• Use UDD list to discuss Ubuntu-issues
• How do we know when we are done?
  • Stage 1: We have moved chromium-browser, mozilla, bzr to this model
  • Stage 2: Scalability (new HW + test SW)

Notes

• Our draft diagram refers to {name: url} and a name field in the builder. We don't know what this means.

• Only applicable to public branches at the moment, due to the sandbox lacking any way to gain authenticated access to bazaar.launchpad.net.

• At no point is anything in the process signed with anyone's GPG key. This might be a problem.

• There's a potential conflict between the distroseries and sourcepackagename on the branch and the information in the debian/ metadata.

• It might be nice to sign the .dsc with a well-known key representing this Launchpad system.

• Not sure how to make sure that rev_id, branch_url & requester are passed all of the way through.

• My notes include "API for buildding" in steps -- don't know what this means.
• My notes include "Start linking table discussion" in steps -- don't know what this means
• Daily builds will need pristine packaging branches, can't use the Ubuntu imports.
• Building a release is very nice, building tip is #1 priority.
• Need to link to a package from a project. Therefore, need a source package selector. jml -- ask curtis
• Get a graph of a package that lacks builds

Questions

• How will daily builds interact with RSS feeds?
• What will the controls look like for building?