Present other build types in a PPA context

Bug #536700 reported by Michael Nelson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Michael Nelson

Bug Description

Note: the soyuz aspect of this bug is complete, but other apps will need to update to the new db-schema before their builds will appear.

Now that we'll have other types of builds being published within a PPA context (SourcePackageRecipeBuild in particular), we would like to have a general way to present a list of different types of builds in the context of a PPA (or a Builder).

Currently both ISourcePackageRecipeBuild and I(Binary)Build inherit from the abstract IBuildBase - an interface defining the common fields, but are separate tables in the DB (ie. ORM "One data entity per concrete class")

So the traversal for builds in a PPA context is:

/~person/+archive/ppaname/+builds

but this presents binary builds only (as historically they were the only type of build).

To enable other types of builds (such as SPRecipeBuilds) to be included in such plurals, we've chatted about this within our Soyuz team as well as with other LP devs:
https://lists.launchpad.net/launchpad-dev/msg03032.html

and would like to go with a "One data entity per class", with a separate BuildFarmJob table, so that a soyuz PackageBuild would encapsulate the BuildBase record + the (Binary)Build record. Similarly, the SourcePackageRecipeBuild class would encapsulate the BuildBase record + the SPRecipeBuild record.

This would enable simply finding all the builds for an archive (or in other contexts also), and presenting them as one continuous history, and also using the one url traversal for all builds (as the id would be on the BuildBase class.) But it would be a bit more work than the simple schema change, due to the way we currently optimise queries for builds, and also that we currently have IHasBuilds which is used in a few contexts and assumes certain things (such as an architecture field).

The current build-related tables with their relation ships can be seen here:
See http://launchpadlibrarian.net/40805850/build-related.png

After discussion, William proposed the following as the new organisation of builds:
http://people.ubuntu.com/~wgrant/launchpad/buildfarm/new-build-model-again.png

Related branches

Changed in soyuz:
assignee: nobody → Michael Nelson (michael.nelson)
Changed in soyuz:
status: Triaged → In Progress
description: updated
description: updated
Changed in soyuz:
status: In Progress → Triaged
assignee: Michael Nelson (michael.nelson) → nobody
description: updated
Changed in soyuz:
milestone: 10.03 → 10.04
description: updated
description: updated
Revision history for this message
Michael Nelson (michael.nelson) wrote :
description: updated
description: updated
Revision history for this message
Ursula Junque (ursinha) wrote : Bug fixed by a commit
Changed in soyuz:
assignee: nobody → Michael Nelson (michael.nelson)
status: Triaged → Fix Committed
tags: added: qa-needstesting
Changed in soyuz:
status: Fix Committed → Triaged
tags: removed: qa-needstesting
Revision history for this message
Michael Nelson (michael.nelson) wrote :

I shouldn't have linked the renaming branch to this bug... it was bug 506292 (linking it there now and updating it). I can't work in this bug itself (the presentation of non-soyuz builds) until all the backend refactoring work is done.

Changed in soyuz:
milestone: 10.04 → 10.05
Changed in soyuz:
milestone: 10.05 → 10.06
Revision history for this message
Michael Nelson (michael.nelson) wrote :

This landed with devel r11041. Tested on edge vs. production. There is a significant degradation in the query count - it may be that the pre-fetching is not working as expected (or it may be an unrelated change on edge, but unlikely). If it is related to this change it is approx. 4 queries per build when using the binary_only=False option :/. The page times are still comparable. Note: this does not effect the API, which has binary_only=True fixed (and hence uses the current implementation). Marking as qa-ok, but if we've time this or next cycle, it would be great to get this back down.

Edge (r11042): https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+builds?build_text=&build_state=all&batch=50
At least 289 queries issued in 3.76 seconds

Production (10.05): https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+builds?build_text=&build_state=all&batch=50
At least 44 queries issued in 3.55 seconds

Changed in soyuz:
status: Triaged → Fix Committed
tags: added: qa-ok
description: updated
Changed in soyuz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.