Not logged in - Log In / Register

General Build Histories

Present a list of different builds (binary builds, source recipe builds) in a single batched history

As a developer building branches to PPAs
I want to view and search all builds targeting a given PPA
so that I can see the history of my branch builds and find build failures of all types.

As an admin of the Launchpad build system
I want to browse the history of a builder to see binary, source and translation builds
so that I can identify and investigate a builders throughput of jobs.

The Build generalisation blueprint will be used to track the breakdown of this feature into small tasks.

The planning and links to email discussions for this feature are available on bug 536700


Why are we doing this now?

What value does this give our users? Which users?


Same as build from branch – XXX: need to have a general LEP tying that together


What MUST the new behaviour provide?

What MUST it not do?


What are the workflows for this feature?

Provide mockups for each workflow.

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.


How will we know when we are done?

When PPA pages such as fta's main PPA display a contiguous list of batched source package recipe builds and binary package builds.

When Builder history pages such as Samarium's history display a contiguous list of batched source package recipe builds, translation template builds, and binary package builds.

How will we measure how well we have done?

By the simplicity of the change to the browser/template code. If the architecture of the model/db changes is good, it should be simple to update the batched views themselves.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. It is mandatory.

When viewing a build-farm builder history (or all the builds for your PPA), you will not only see binary builds, but also other types of builds such as source package recipe builds, or translation template builds.


Put everything else here. Better out than in.

Implementation plan

As this will be a significant amount of work, we want to plan it to enable the work to be done in parallel. Here are the current thoughts. Each line in the following spreadsheet could be a separate branch/task/bug.

Implementation dependencies

  • Note: By only removing the old soyuz build data in a schema patch after all the separate areas have been updated, we can migrate each area separately, ensuring that tests continue to pass.
  • Note2: Although it would be nice to remove BuildQueue/BuildPackageJob tables and related job records, it won't be necessary to present the generalised build histories.

LEP/GeneralBuildHistories (last edited 2010-04-09 11:36:58 by jml)