Diff for "Packaging/SourceBuilds"

Not logged in - Log In / Register

Differences between revisions 6 and 10 (spanning 4 versions)
Revision 6 as of 2010-07-20 19:11:15
Size: 2922
Editor: CPE001e6b233d5b-CM001e6b233d5a
Comment:
Revision 10 as of 2011-03-24 11:23:49
Size: 3083
Editor: host217-44-165-42
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
~-[[FrontPage|Launchpad Help]] > [[Packaging]] > Daily builds -~

||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 3: Line 7:
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. = Daily builds =
Line 5: Line 9:
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. Daily builds are a great way of trying out the latest code from a project, with relatively little effort.
Line 7: Line 11:
== Why Daily Builds? == Whether you want to help others test your code, or you want to run a modified or bleeding edge version of your favourite software, Launchpad's daily builds lets you:
Line 9: Line 13:
 * 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.
 * take the code in one or more Bazaar branches
 * borrow the packaging information from the software's existing Ubuntu package
 * sit back and get an automatic build one every day the source changes, which is then published in the PPA of your choice.
 
So you can run the latest code, with or without your chosen modifications, without having to install from source. Plus, you get automatic Ubuntu update reminders whenever the package changes.
Line 14: Line 19:
There could be some downsides to having daily builds, so they may not be suitable for your project. == Why daily builds? ==
Line 16: Line 21:
 * 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.
If you're running a software project, the main advantage of daily builds is that it helps with testing. In particular, it can help:
Line 22: Line 23:
 * '''Tighten the feedback loop:''' making new code available almost straight away, in a way that's easy to install, brings developers and testers closer together
 * '''Lowers the barrier to becoming a tester:''' adding a PPA is an easy and common task for Ubuntu users, meaning that anyone can help test your software
 * '''Easier verification testing:''' people who've reported a bug can quickly and simply check that the bug is fixed in a future revision.
 
There are also some considerations that may mean daily builds are not suitable for your project, such as:
Line 23: Line 29:
== Setting up a daily build ==  * Your project doesn't use feature branches or keep the trunk in a buildable state.
 * Your project is in the early stages of development or in the middle of a major refactoring and not yet ready for testing.
 * Sometimes users think daily builds are supported releases, which can both add to bug noise and generate support requests.
 * 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.
Line 25: Line 34:
If you would like to set up a daily build then see [[Packaging/SourceBuilds/BzrBuilder|BzrBuilder]] for one way to do this. Be sure to also check out [[Packaging/SourceBuilds/GoodDailyBuilds|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. == Finding existing daily build archives ==
Line 27: Line 36:
== Available daily builds == Launchpad provides a [[https://code.launchpad.net/+daily-builds|list of all daily builds]] and the Ubuntu community has a [[https://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds|slightly more detailed but manually maintained list of daily builds]].
Line 29: Line 38:
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]]. = Getting started with daily builds =

To [[/GettingStarted|get started with your own daily builds]] you'll need source code in Launchpad, packaging information and a recipe that brings them all together. Let's take a look in more detail.

||<tablestyle="width: 100%;" style="width: 50%;"> ~- [[Packaging/PPA/BuildScores|How Launchpad prioritises builds]] -~ ||<style="text-align: right; width: 50%;">~-[[/GettingStarted|Getting started with daily builds >]]-~ ||

Launchpad Help > Packaging > Daily builds

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

Home

Getting Started

Knowledge Base

List of Daily Builds

Daily builds

Daily builds are a great way of trying out the latest code from a project, with relatively little effort.

Whether you want to help others test your code, or you want to run a modified or bleeding edge version of your favourite software, Launchpad's daily builds lets you:

  • take the code in one or more Bazaar branches
  • borrow the packaging information from the software's existing Ubuntu package
  • sit back and get an automatic build one every day the source changes, which is then published in the PPA of your choice.

So you can run the latest code, with or without your chosen modifications, without having to install from source. Plus, you get automatic Ubuntu update reminders whenever the package changes.

Why daily builds?

If you're running a software project, the main advantage of daily builds is that it helps with testing. In particular, it can help:

  • Tighten the feedback loop: making new code available almost straight away, in a way that's easy to install, brings developers and testers closer together

  • Lowers the barrier to becoming a tester: adding a PPA is an easy and common task for Ubuntu users, meaning that anyone can help test your software

  • Easier verification testing: people who've reported a bug can quickly and simply check that the bug is fixed in a future revision.

There are also some considerations that may mean daily builds are not suitable for your project, such as:

  • Your project doesn't use feature branches or keep the trunk in a buildable state.
  • Your project is in the early stages of development or in the middle of a major refactoring and not yet ready for testing.
  • Sometimes users think daily builds are supported releases, which can both add to bug noise and generate support requests.
  • 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.

Finding existing daily build archives

Launchpad provides a list of all daily builds and the Ubuntu community has a slightly more detailed but manually maintained list of daily builds.

Getting started with daily builds

To get started with your own daily builds you'll need source code in Launchpad, packaging information and a recipe that brings them all together. Let's take a look in more detail.

How Launchpad prioritises builds

Getting started with daily builds >

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