Diff for "Packaging/SourceBuilds"

Not logged in - Log In / Register

Differences between revisions 4 and 5
Revision 4 as of 2010-07-20 17:42:59
Size: 2900
Editor: CPE001e6b233d5b-CM001e6b233d5a
Comment:
Revision 5 as of 2010-07-20 19:09:17
Size: 2912
Editor: CPE001e6b233d5b-CM001e6b233d5a
Comment:
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
See [[Packaging/SourceBuilds/AvailableDailyBuilds|AvailableDailyBuilds]] for a list of some of the daily builds available. Builds on this page should adhere to the principles in [[Packaging/SourceBuilds/GoodDailyBuilds|GoodDailyBuilds]]. See [[http://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds|AvailableDailyBuilds]] for a list of some of the daily builds available. Builds on this page should adhere to the principles in [[Packaging/SourceBuilds/GoodDailyBuilds|GoodDailyBuilds]].

lp-diamond-16.png Source package recipes in Launchpad

Home

Getting Started

Knowledge Base

List of Daily Builds

Launchpad can now build directly from source code, creating a source package and then creating binary packages from the source package. You can configure Launchpad to perform these builds daily (if the source has changed), run them manually, or script them yourself using the Launchpad API. The terms "Source Build" and "Daily Build" are more or less interchangeable.

The build results can be discarded if a build-test is all that is wanted, but usually they are kept and made available so that they can be tested in use as well. Obviously, as there is automation involved in the process the resulting packages can be risky as they haven't had human verification. This means that there has to be some care taken with them, and the project and packager should do their best to ensure that the risks are minimized. They are also not something that an average user should be using. With due diligence the benefits can certainly outweigh the risks though.

Why Daily Builds?

  • Testing
    • Making new code quickly available as a package tightens the feedback loop between developers and testers and so can improve the quality of the software.
    • Lowers the barrier to entry to becoming a tester (Just adding a PPA instead of building from source)
    • Easier verification testing - Makes it easier for users to see if their bug is fixed in a future revision.

There could be some downsides to having daily builds, so they may not be suitable for your project.

  • Downsides
    • If your project doesn't use feature branches or keep trunk in a buildable state, then dailies might be not be valuable to you.
    • If your project is in the early stages or in the middle of a major refactoring and you're not ready for testing then dailies won't be useful.
    • Sometimes users think dailies are supported releases and this can add up to bug noise.
    • If users cannot easily go back to their previous version of your software after using daily builds (for example you do a one-time database upgrade or something from one version to another) then this can be problematic.

Setting up a daily build

If you would like to set up a daily build then see BzrBuilder for one way to do this. Be sure to also check out GoodDailyBuilds for some tips on how to ensure that the daily build will be most useful. Running daily builds are not maintenance-free, you need to follow upstream development so that if the upstream project adds or removes dependencies your builds don't break.

Available daily builds

See AvailableDailyBuilds for a list of some of the daily builds available. Builds on this page should adhere to the principles in GoodDailyBuilds.

Packaging/SourceBuilds (last edited 2016-03-15 11:51:31 by cjwatson)