launchpad help|
Size: 3540
Comment:
|
Size: 3083
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ~- [[FrontPage|Launchpad Help]] > [[Packaging]] > Source package builds -~ | ~-[[FrontPage|Launchpad Help]] > [[Packaging]] > Daily builds -~ |
| Line 3: | Line 3: |
| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| | |
| Line 6: | Line 7: |
| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| | = Daily builds = |
| Line 8: | Line 9: |
| = Overview = | Daily builds are a great way of trying out the latest code from a project, with relatively little effort. |
| Line 10: | Line 11: |
| 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. | 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 12: | Line 13: |
| 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. | * 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: |
| == Why Daily Builds? == | == Why daily builds? == |
| Line 16: | Line 21: |
| * 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. |
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 21: | Line 23: |
| There could be some downsides to having daily builds, so they may not be suitable for your project. | * '''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: |
| ||<tablestyle="border: 0; width: 100%;"> ~-[[Packaging|< Packaging]] -~ ||<style="text-align: right;"> ~-[[Packaging/SourceBuilds/GettingStarted|Getting started >]] -~|| | * 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: |
| * 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. |
== Finding existing daily build archives == |
| Line 31: | Line 36: |
| 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 32: | Line 38: |
| == Setting up a daily build == | = Getting started with daily builds = |
| Line 34: | Line 40: |
| 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. | 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. |
| Line 36: | Line 42: |
| == Available daily builds == 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]]. ||<tablestyle="border: 0; width: 100%;"> ~-[[Packaging|< Packaging]] -~ ||<style="text-align: right;"> ~-[[Packaging/SourceBuilds/GettingStarted|Getting started with source package branches >]] -~|| |
||<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
|
|||
Source package recipes in Launchpad
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.
