launchpad help|
Size: 4978
Comment:
|
← Revision 3 as of 2010-08-18 11:27:19 ⇥
Size: 4442
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| ||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
|
| Line 10: | Line 8: |
| Launchpad can build Debian-style packages for Ubuntu directly from Bazaar branches hosted in Launchpad. | Launchpad can build Debian-style packages for Ubuntu directly from source code in Bazaar branches hosted on Launchpad or imported from elsewhere. |
| Line 12: | Line 10: |
| You can configure Launchpad to perform these builds once a day (if the source has changed) or when you request them through the web interface or Launchpad's API. | You can configure Launchpad to perform these builds automatically once a day (if the source has changed) or when you request them through the web interface or Launchpad's API. |
| Line 14: | Line 12: |
| ||<tablestyle="font-size: 0.8em; width:30%; background:#F1F1ED; margin: 1em 1em 1em 0;" style="padding:0.5em;">{{attachment:audacity-daily-builds.png}}|| ||<style="text-align: center;">'''A PPA containing daily builds'''|| |
Packages built this way are most useful when you enable automatic daily builds and so these guides will concentrate on using them in that way. |
| Line 26: | Line 23: |
| 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. | If all you want is a build test, you can discard the build results. Usually, though, you'll want to keep the resulting packages and make them available for testing. |
| Line 28: | Line 25: |
| 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. | As the build process is automatic, the resulting packages can be risky and you should take care when using them. You should do what you can to minimise any risks to people who install your automatically built packages. |
| Line 30: | Line 27: |
| == Why Daily Builds? == | However, don't be put off. While packages built this way are not for the average user, when you deploy them in the right circumstances, and with due diligence, the benefits can certainly outweigh any risks. |
| Line 32: | Line 29: |
| * 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. |
= Why use daily builds? = |
| Line 37: | Line 31: |
| There could be some downsides to having daily builds, so they may not be suitable for your project. | Testing is the main use for packages built this way, particularly if you opt for automatic daily builds. |
| Line 39: | Line 33: |
| ||<tablestyle="border: 0; width: 100%;"> ~-[[Packaging|< Packaging]] -~ ||<style="text-align: right;"> ~-[[Packaging/SourceBuilds/GettingStarted|Getting started >]] -~|| | Here's why: |
| Line 41: | Line 35: |
| * 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. |
* Testers can install the latest code almost straight away, tightening the feedback loop between developers and testers. * It lowers the barrier to entry for new testers: they can add the PPA and install your package, then receive automatic updates, rather than building from source. * Visibility of bug fixes: people can easily verify that their bug has been fixed in a version of the code not yet officially released. |
| Line 47: | Line 39: |
| There could be some downsides to using daily builds, so they may not be suitable for your project. | |
| Line 48: | Line 41: |
| == Setting up a daily build == | Possible downsides include: * If your project doesn't use feature branches or keep trunk in a buildable state, then daily builds 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 daily builds won't be useful. * Sometimes users think daily builds are supported releases and this can add to bug noise. * If users cannot easily go back to their previous version of your software after using daily builds (for example, there is a one-time database upgrade between versions) this may lead to increased support requests. = Setting up a daily build = |
Launchpad Help > Packaging > Source package branches
|
|||
Source package recipes in Launchpad
Overview
Launchpad can build Debian-style packages for Ubuntu directly from source code in Bazaar branches hosted on Launchpad or imported from elsewhere.
You can configure Launchpad to perform these builds automatically once a day (if the source has changed) or when you request them through the web interface or Launchpad's API.
Packages built this way are most useful when you enable automatic daily builds and so these guides will concentrate on using them in that way.
How source package branches work |
1. You tell Launchpad where to find the source code you want to build. |
2. You write a recipe that tells Launchpad where to find packaging instructions and how to apply them. |
3. You tell Launchpad when you want the builds to happen |
• each day (if there has been a change in the source) |
• or only when you ask for one (either through the web or API). |
4. Launchpad builds a source package. |
5. Launchpad builds the source package into a binary and puts it in the PPA you specify. |
If all you want is a build test, you can discard the build results. Usually, though, you'll want to keep the resulting packages and make them available for testing.
As the build process is automatic, the resulting packages can be risky and you should take care when using them. You should do what you can to minimise any risks to people who install your automatically built packages.
However, don't be put off. While packages built this way are not for the average user, when you deploy them in the right circumstances, and with due diligence, the benefits can certainly outweigh any risks.
Why use daily builds?
Testing is the main use for packages built this way, particularly if you opt for automatic daily builds.
Here's why:
- Testers can install the latest code almost straight away, tightening the feedback loop between developers and testers.
- It lowers the barrier to entry for new testers: they can add the PPA and install your package, then receive automatic updates, rather than building from source.
- Visibility of bug fixes: people can easily verify that their bug has been fixed in a version of the code not yet officially released.
There could be some downsides to using daily builds, so they may not be suitable for your project.
Possible downsides include:
- If your project doesn't use feature branches or keep trunk in a buildable state, then daily builds 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 daily builds won't be useful.
- Sometimes users think daily builds are supported releases and this can add to bug noise.
- If users cannot easily go back to their previous version of your software after using daily builds (for example, there is a one-time database upgrade between versions) this may lead to increased support requests.
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.
