Release Infrastructure/devroot

Revision as of 11:59, 30 June 2011

story

As a developer I need to be able to

• "quickly" build, deploy, test my changes
• with possibility to work offline
• have similar build results than the releasing system so my test results are reliable
• be able to skip reverse dependency builds
• do all that in with a very simple tool

In order to speed up the development process, and be more productive

use case

1. modify one package
2. build it
3. update target device
4. run test cases

1. modify code across the stack (multiple pkgs)
2. recursively build all modified pkgs
3. update target device
4. run test cases

solution

these requirements can be met easily with manual work, there is no missing tools, the real problem is in simplifying and automating

devroot

a tool that wraps all the commands to run that process, automating many manual steps

1. init
2. update
3. build
4. target-flash
5. target-update
6. target-test

init(conf, [path])

takes as input the list of packages the developer will work on (FIXME: more details needed) create a chroot will all operations will run, it is necessary to isolate the build env to not get reliable results fetch all needed sources and extract them in the specified location e.g /home/user/chroot/usr/share/devtree/ chroot, will contain a bootstrap of the desired distro, all the build tools, and the build dependencies of the packages specified open items:

• where te fetch sources? src.rpm or git trees or obs projects?
• do we fetch dependencies? what about reverse dependencies?

update:([path])

update the chroot env, and the sources provide a merge possibility of the newer code and the modifications done locally

build

this should perform

• build (make)
• package
• publish

this is what rpmbuild does, but it would require that we archive the source tree and then rpmbuild would unpack it, also rpm would always flush the buildroot and start building from scratch again. this way is good for releasing but too slow for our purpose. rpmbuild has oprtions we can use to control all those and reach the desired process build in place (no archive) and keep old build data, so rebuilds are much faster (depending on how make detects changes) the build script of OBS should be used as it will produce a similar result as what happens on OBS this covers the build and package, publish is needed to make that package available to the target device this can be done through filesystem or http if build method is called from inside a certain pkg tree e.g /home/user/chroot/usr/share/devtree/pkg1, then it would only build this package if called from the devtree root /home/user/chroot/usr/share/devtree/ the it should detect whcih pkgs have modifications and only build those

target-flash

create an image using mic, and flash it to device, tools and details are device specific. we might skip this method

target-update

connect to device over usb-network and update the device through the published repo e.g. zypper ref;zypper up

target-test(test_package)

connect to device over usb-network and run the test cases provided. a good tool for that would be test-runner-lite part of OTS testing suite