launchpad help|
Size: 3235
Comment:
|
Size: 3114
Comment: Document git recipes, now in beta
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ~-[[FrontPage|Launchpad Help]] > [[Packaging]] > Source package recipes -~ |
|
| Line 3: | Line 5: |
| 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. | ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
| Line 5: | Line 7: |
| 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. | = Source package recipes = |
| Line 7: | Line 9: |
| == Why Daily Builds? == | Source package recipes are a great way of trying out the latest code from a project, with relatively little effort. |
| Line 9: | Line 11: |
| * 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. |
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: |
| There could be some downsides to having daily builds, so they may not be suitable for your project. | * take the code in one or more Bazaar branches (or Git branches, in beta) * 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: |
| * 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 your software doesn't gracefully "fall back" to the user using an older version (for example you do a one-time database upgrade or something from one version to another) then this can be problematic. |
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 22: | Line 21: |
| == Types of daily build == | == Why source package recipes? == |
| Line 24: | Line 23: |
| A daily build doesn't have to be daily at all, it could be weekly for instance, or done on every commit. The ideal frequency depends mainly on the activity of the project, it is a busy project then one generally wants the packages to be built more frequently. However, too frequent updates lead to wasted bandwidth, so there is a balance to strike. | 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 26: | Line 25: |
| == Setting up a daily build == | * '''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 28: | Line 31: |
| If you would like to set up a daily build then see [[SourceBuilds/BzrBuilder|BzrBuilder]] for one way to do this. Be sure to also check out [[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. | * 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 30: | Line 36: |
| == Available daily builds == | = Getting started with source package recipes = |
| Line 32: | Line 38: |
| See [[SourceBuilds/AvailableDailyBuilds|AvailableDailyBuilds]] for a list of some of the daily builds available. Builds on this page should adhere to the principles in [[SourceBuilds/GoodDailyBuilds|GoodDailyBuilds]]. | 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. ||<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 branches (or Git branches, in beta)
- 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.
