• 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

Refer to BuildBranchToArchive for the non-UI aspects.

The UI issue: simple building of (daily) packages

Although it is possible for Launchpad users to build a source package from a branch and publish it in their PPA using the bzr-builder plugin, we can radically reduce the complexity of this process (and remove the need to transfer data in and out of Launchpad unnecessarily) enabling a much wider audience to benefit from easy branch building and, in particular, daily builds.

We can create a simple UI, that in the best case, presents a selection of target PPA and recipe for building the source package with a button to start, while still ensuring that the full flexibility of custom builds is available when required.

Please update this page with any ideas of your own, especially the questions section.

Goals of the UI

[draft] Users with upload rights to any PPA can, when viewing a branch page:

• build the branch-tip within 3 clicks of the branch page (or a specific revision).
• setup a daily build for the branch by customising the recipe (ie. just a checkbox)
• see the recent builds of that branch (and perhaps a build history for the branch?)
• See all the recipes for the branch (name, owner and distroseries?)

When viewing a source package recipe build within their PPA, users can:

• easily identify the current status of the build (and log etc.)
• View the manifest (and from there the related branches and recipe)
• view (and edit) the recipe (ie. disabling daily builds)
• ...

After starting a new build from a branch, users will be:

• Informed of any relevant successes or failures.

Users can view a list of all their recipes and update them as needed (and when looking at a recipe, see the history of builds for that recipe?)

Users can see source package recipe builds when viewing a specific builder's history.

Target user audiences

[draft] The following roles have been identified as potential target audience groups:

• Project maintainers
• Current users of bzr-builder for daily builds...
• Opportunistic programmers who...
• Power users of existing projects who want to run trunk jml (michael: wouldn't/shouldn't the project set up a daily build, or be encouraged to do so by such power users?)

Use-cases

Please feel free to expand, correct or add further use-cases. If you are wanting to update or modify any of the mockups, you can grab the Balsamiq mockup files with:

bzr branch lp:~michael.nelson/+junk/buildfrombranch-mockups

(and propose any merges).

• A typical manual build of branch - This use-case includes the creation of a recipe, and its re-use for a subsequent build.

Daily builds

Yong-sik works on the ereader project and has a number of PPAs including 'ereader_daily' and 'ereader_beta'. He now wants to automate his daily builds.

This could be achieved by adding scheduling options to the previous mockups:

Note: we don't currently have db schema support for this - see bug 515923.

Yong-sik opens the Launchpad page for his devel branch and then

1. clicks on the "Build now" button,
2. ...

Design and interaction questions

New Questions

Still requiring thought

• Should a recipe handle all distro series?! bug 516448 and different but related bug 513201

  • The distro series should be encoded in the package version e.g. ~{distro} which gets substituted with the distro series version number eg. ~9.10 so that upgrades work from one release to next within the ppa. Also this way you only need one recipe to build for all distro series by selection "All supported" in the series dropdown menu. Majority of daily ppa's have tweaked packaging to work across all series so having 5x recipes per each daily-build setup is less than optimal. And this way new daily-builds will start automaticly once new development release is set up.

  • Is {distro} an option supported by bzr-builder? I can't see it anywhere in the docs -- michael.nelson 2010-02-03 13:31:10

  • See comment 3 on bug 516496 - afaics, this will need to be addressed before we can even think about this option.

• Slow moving projects, duplicate rejects
  • Some projects are slow moving, and sometimes don't have commits every day. Will those daily builds be silently dropped or the reject emails will be send from Soyuz/PPA? Emails will be annoying =)

  • abentley suggests we could create build jobs when the tip of any branch in the recipe changes, using the branch scanner.

• Why can't the packaging branch be something that you can search for and change? (ie. an optional field, rather than part of the text-area) (see mockup below).
• Why do users even need to know about recipes when creating an initial build - can't we potentially determine a related packaging branch?

  • There is no standard way to construct packaging branches as yet. Some may be pure packaging info, which will require nesting into a 'debian' directory, others will contain the debian directory and require just a simple merge. Similarly, there may be other custom merges required as well. So it seems that even initially we'll need to expose the recipe in all its glory.

  • That said, there's no reason why we can't provide an *optional* packaging branch selector and capture most of the information without needing to display the recipe verbatim, but rather using structured fields (and hence a packaging branch picker). Here's a mockup:

• Our current schema doesn't support daily builds (as the archive is only mentioned on the SPRBuild, not on SPRecipe). How will we update the schema to support specifying daily builds (bug 515923)?

  • wgrant suggested some type of 'schedule' that would generalise to also allow automatic builds in other conditions.

  • abentley recommends doing the minimum that will work until we have a better idea what we want to generalize.

• What is the complete set of URLs that will be updated as part of this work?
  • (code) path_to_branch (eg. ~owner/myproject/feature_x). Required: new "Build now" link (or "Build this", or "Create a build" - needs to be inclusive of both once-off and daily builds), and latest builds portlet.
  • code: path_to_branch/+buildbranch (non-js version). New page to create a recipe build
  • A traversal for creating new recipes - I personally think this will be best close to the base-branch of the recipe (ie. path_to_branch/+new-build-recipe - we create a recipe for the base-branch, not a recipe for the distroseries/sourcepackagename and perhaps specify an incorrect base-branch), but there might have been more thought on this in the past?
  • (code) path_to_branch/+recipes (displays both recipes identifying the branch as the base, as well as potentially recipes which merge the branch etc. )
  • (code?) ~owner/distro/distroseries/sourcepackagename/recipename The canonical traversal for displaying/editing a recipe.
  • (code?) ~owner/+recipes: all recipes owned/created by a person
  • /builders/buildername/+history: needs to display different types of builds, rather than just binary builds (bug 491330)
  • ~username/+archive/mytargetppa/+builds : needs to display different types of builds, rather than just binary builds (one idea that we chatted about was to include build type and id in the url as we don't have a table for the base class, but rather

duplicate fields on two tables. Something like /+builds/2_234. The other option is to update the backend so that BaseBuild has it's own table.

• ~username/+archive/mytargetppa/+packages needs to (somehow) indicate that there are SPRBuilds currently underway with
  • a link to the build.
• Also, creating the JS overlay in the above mockup will require first exposing SPRecipes through the API.

Answered (to some degree)

• What if the user who wants to build a branch doesn't have a PPA (or upload privileges to one)?

  • Eventually we'd like to see PPA creation seamlessly interwoven with the build process, but initially this option will only be available to users who have upload rights to a PPA

• How will malformed recipes be handled?

  • When submitting the recipe text, normal LPForm validation will indicate errors. Eventually it'd be great to check the recipe text client-side.

• What if I have need a recipe that combines many branches for a build, not just one main one?

  • Free-form editing of the bulk of the recipe text will be possible, but so far we don't think it would be a good idea to be able to edit the base_branch.

• How will users who have no experience with bzr-builder be able to create a recipe?

  • We hope we'll be able to do most of the work to display a sane template. But we will need help available for the recipe commands and the revision spec options.

• How will I be notified of the progress of my build?

  • Similar to the current soyuz build infrastructure, you will be able to view the build as soon as it's created and it will display the estimated time until dispatch or the current state etc. We haven't discussed emailing on success/failure, but I guess we'll need to do that too?"

• What if theris already a recipe for the given branch, how will the user know to use that instead?

  • The ui will encourage users to choose from one of the available recipes for the branch before creating their own.

• Do we currently detect when *none* of the branches associated with a recipe add a debian directory?

  • No, and we can't do this as it's not in the DB (and we can't poke bzr from LP code).

• When displaying the resulting source package in the PPA, would we also want something like "There is a newer revision available for this source package branch [build now]."?

  • Yes.

• Eventually, in a years time, we may have *lots* of recipes on certain branches (say a project's trunk) for different distroseries. How will we display a sensible selection of recipes?

  • Perhaps restrict the recipes by the current release, devel and LTS distroseries?

• I'm assuming that part of our validation when creating a build should be that the evaluated deb-version will be greater than all current versions in the target PPA?

  • Yes.

• Should users be free to specify the complete deb-version? (deb-version 1.0+{revno}-{revno:packaging}), Or how can we simplify this? We could do auto {revno} and {revno:packaging}, but this could lead to issues when the same users creates a build using a *different* packaging branch that has a lesser version?

  • Currently we can't see any other possibility without some very intelligent algorithm that checks the destination ppa publishings etc., even then we'd still need the option of manual specification.

• The destination target needs a progress indicator. For PPAs, the detail packages page should show the source package in the construction (builddeb) phase, which conceptually is before anything it shows right now. How will we do this?

  • We could include it in the latest updates portlet, but this may not be sufficient.

• None of the current mockups consider the distroseries of recipes, but the user should only be able to select recipes for the distroseries to which they want to publish - this information is available in the changelog of the packaging branch, but it won't be in the DB until the source package is uploaded. How can we do this consistently? In a way it seems as though we want the recipe to define the distroseries, but it won't, the changelog will.

  • The mockups have been updated to include distroseries and package name.

• Similarly, the sourcepackagename is defined in the changelog of the packaging branch - information which we won't have until the source package is uploaded, but we need to create the recipe first - how can we do this consistently?

  • The mockups have been updated to include distroseries and package name. There is still a related issues, one related to the current schema (spnames required before upload - bug 515581 which is perhaps ok), and spname/suite not being passed to dailydeb - bug 515918

Notes