Automated optimistic merging and testing of new upstream releases.

• Launchpad Entry: foo

• Created: 19 March 2010

• Contributors: James Westby, DmitrijsLedkovs

• Packages affected:

Summary

Typical workflow for packaging new releases has many manual steps. The aim of this spec is to automatically attempt merging new source code releases, do test builds and run qa checks. Generated reports will give Ubuntu developers an idea of what effort will be required to package new release.

This is a GSoC idea called "Automated optimistic merging and testing of new upstream releases".

Proposed catchy and more obscure name for this tool is CADIE - Completely Automated Developer and Integration Expert (pun).

Release Note

CADIE allows Ubuntu Developers spend less time on repetitive tasks and focus more on creative side of programming.

Rationale

Typical packaging workflow is:

1. Find new code e.g. vcs-import, fresh tarball, new debian package release.
2. Import new code e.g. using bzr merge, merge-upstream or import-dsc commands
3. Do a test clean-build (ppa / pbuilder)
4. Run automated checks
5. Perform human review

We would want to automated all these. Unfortunately last one might require AI, so we will rely on Ubuntu Developers for that one.

Developer stories

TODO

Developer guide with CADIE in place for three cases: snapshot, tarballs, debian.

Assumptions

Target packages must have an up to date lp:ubuntu/package branch.

Packages must have one or more of:

• up to date shared history lp:debian/package
• working debian/watch file
• up to date lp:project branch link

Design

You can have subsections that better describe specific parts of the issue.

Implementation

New code

There three planned streams for new code. If ubuntu version is smaller than Debian, Upstream Tarball or VCS a merge will be attempted with the closest next version.

Last one will be possible when package branches share history with upstream branches. VCS import is targeted at packages which already package snapshots revisions.

Building

After potential merge candidates are identified build jobs should be scheduled. Building will include

1. Attempt merge
2. Push to lp:~cadie/ubuntu/$m/$pkg/merge-$new-version
3. Run source package tests
4. Request recipe build from branch

This will rely on recipe building from launchpad. Alternatively building should be possible locally using pbuilder.

The unresolved question here whether we are going to use regular ppa or special soyuz build job with binary package mangling. Plus we want to have clean ppa for successful test binaries affecting each other, yet still have them available for testing by Ubuntu Developers. See testing.

Testing

1. Lintian should be run after merge on source package creation. $bzr bd --source with lintian hook.
2. Package building building should be done in "qa" mode
   • dh_install --list-missing
   • lintian on success
   • Others

"qa" mode building can be achieved by either using soyuz/lp binary-package mangling. Or by having a funky debhelper package installed which diverts those commands and has wrappper in place to call our additional flags / tests. This needs further discussion

Reporting

1. Page with potential candidates / version comparison with stats. So we know how many packages are we dealing with. Starting with main and then extending with universe.
2. The "queue" page with current status per package.

3. Reports (fail / success & log)

   • Source merging
   • Source package testing
   • Test buildlog
   • Binary package tests
   • Debdiff

Other test / reports will be possible as well. For example finding/identifying & displaying changelog, news, release notes.

Code Changes

Possible areas that might be touched: udd package importer, soyuz, M-o-M

Test/Demo Plan

1. Create "Potential Candidates Page"

2. Create backend runner which attempts merging locally and pushing to launchpad (cron job) with reporting -> plain log files published on e.g. people.ubuntu.com

3. Create script which scans for new merges, does $bzr bd --source lp:~cadie/ubuntu/m/pkg with lintian and publishes reports.
4. Create script to scan for successful dsc and dput them to pbuilder / ppa. Or request branch builds using recipes.

GSoC Questions

• Why did you like this idea?

I've been doing a few merges & syncs. MoM helps a lot, but it's not perfect. With this project implemented it would be easier to start working on Ubuntu because the required steps will be shown by example. And it will make Ubuntu development more fun "Spot what went wrong?" type of game =)

• Why will your proposal benefit Ubuntu?

It will provide archive wide QA check of potential future package versions allowing to spot problems earlier in the development cycle.

Unresolved issues