launchpad help|
Size: 3540
Comment:
|
← Revision 16 as of 2016-03-15 11:51:31 ⇥
Size: 3094
Comment: git recipes are out of beta now
|
| 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]] > Source package recipes -~ |
| Line 8: | Line 7: |
| = Overview = | = Source package recipes = |
| Line 10: | Line 9: |
| 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. | Source package recipes are a great way of trying out the latest code from a project, with relatively little effort. |
| Line 12: | Line 11: |
| 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. | Whether you want to help others test your code, or you want to run a modified or bleeding edge version of your favourite software, with Launchpad's source package recipes you can: |
| Line 14: | Line 13: |
| == Why Daily Builds? == | * take the code in one or more Bazaar or Git branches * borrow the packaging information from the software's existing Ubuntu package * sit back and get an automatic build on 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 16: | Line 19: |
| * 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. |
Source package builds is the name we give to this Launchpad feature. Most source package builds are automatically built each day and you'll see those referred to as daily builds. |
| Line 21: | Line 21: |
| There could be some downsides to having daily builds, so they may not be suitable for your project. | == Why source package recipes? == |
| Line 23: | Line 23: |
| ||<tablestyle="border: 0; width: 100%;"> ~-[[Packaging|< Packaging]] -~ ||<style="text-align: right;"> ~-[[Packaging/SourceBuilds/GettingStarted|Getting started >]] -~|| | If you're running a software project, the main advantage of source package recipes is that they help with testing. In particular, they can help: |
| Line 25: | Line 25: |
| * 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. |
* '''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 source package recipes are not suitable for your project, such as: |
| Line 31: | Line 31: |
| * 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 source package 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 source package builds (for example you do a one-time database upgrade or something from one version to another) then this can be problematic. |
|
| Line 32: | Line 36: |
| == Setting up a daily build == | = Getting started with source package recipes = |
| Line 34: | Line 38: |
| 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 source package recipes]] 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 40: |
| == 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 source package recipes >]]-~ || |
Launchpad Help > Packaging > Source package recipes
|
|||
Source package recipes in Launchpad
Source package recipes
Source package recipes 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, with Launchpad's source package recipes you can:
- take the code in one or more Bazaar or Git branches
- borrow the packaging information from the software's existing Ubuntu package
- sit back and get an automatic build on 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.
Source package builds is the name we give to this Launchpad feature. Most source package builds are automatically built each day and you'll see those referred to as daily builds.
Why source package recipes?
If you're running a software project, the main advantage of source package recipes is that they help with testing. In particular, they 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 source package recipes 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 source package 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 source package builds (for example you do a one-time database upgrade or something from one version to another) then this can be problematic.
Getting started with source package recipes
To get started with your own source package recipes 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.
