= 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<<BR>>
'''I want ''' to view and search all builds targeting a given PPA <<BR>>
'''so that ''' I can see the history of my branch builds and find build failures of all types.<<BR>>

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

 * This feature will not change the UI for the builder history or PPA builds views, rather it will enable those views to include and batch all builds rather than just the current binary builds.

''The [[https://blueprints.edge.launchpad.net/soyuz/+spec/build-generalisation|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 Bug:536700

== Rationale ==

''Why are we doing this now?''
 * It is not a blocker, but it is part of the [[BuildBranchToArchive]] implementation.

''What value does this give our users? Which users?''
 * Developers using build-branch-to-archive mainly, giving them one point to view all builds related to their PPA.

== Stakeholders ==

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

== Constraints ==

''What MUST the new behaviour provide?''

''What MUST it not do?''


== Workflows ==

''What are the workflows for this feature?''

''Provide mockups for each workflow.''
 * This feature will not change the UI for the builder history or PPA builds views, rather it will enable those views to include and batch all builds rather than just the current binary builds.

'''''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.'''''

== Success ==

''How will we know when we are done?''

When PPA pages such as [[https://edge.launchpad.net/~fta/+archive/ppa/+builds?build_text=&build_state=all|fta's main PPA]] display a contiguous list of batched source package recipe builds and binary package builds.

When Builder history pages such as [[https://edge.launchpad.net/builders/samarium/+history|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.

== Thoughts? ==

''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.

[[https://spreadsheets.google.com/ccc?key=0Aj8NBAOm_qcIdEoxZEZuekdCc3ByOUJyQ3ljLUE5enc&hl=en_GB|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.