7

We are building embedded software using a Linux setup based on the Yocto project. We have a couple different configurations that we are building for different purposes (but the same target).

I have been struggling with the best way to set up continuous integration for this project. Ideally, I would like to be able to reuse most of the artifacts, so that someone working on a specific layer can get rapid feedback.

However, I haven't found any good suggestions on a way to break these builds apart. Is there a way to separate the various layers we are working on into multiple builds with shared artifacts so that it takes a couple hours for developers to get feedback from each build?

Improve this question
2
  • I'm not entirely sure what you want to do... Why can't you just build all the layers on top of each other? Commented Apr 28, 2014 at 15:20
  • I can- just trying to figure out a way to shorten the build process and make the feedback more targeted. So that if someone makes a change to one file in one layer, they don't have to wait for the whole kernel and all the other layers to be rebuilt to find out they broke something. Commented Apr 28, 2014 at 16:59

1 Answer 1

Reset to default
2

We don't test individual layers. We build and test the entire yocto code base we use.

We have a build script that accepts some arguments:

  1. release, "stable" or latest git HEAD
  2. include ptests or not
  3. include developer tools or not
  4. architecture to build for (e.g. qemu, x86, x86_64)

Now we have multiple builds in our build system:

  • If build against the latest git HEAD we do not do a clean build and just update the meta* layers (rsync -a --delete). Sometimes we have to wipe the folder of this build. These are quick builds.
  • If we do a "release" build, we do a clean build
  • If we do a "stable" build, we do a clean build

Create additional builds as needed (e.g. with ptest or developer tools).

The build script allows us also to copy the downloaded files on releases or define to have a 'no network' build which gets the source files from a folder.

Regarding automated testing we are not that far yet (can't run qemu on the build VM). But the ptest is a good start and we want to automate that in the future. Yocto itself does also provide some options here, but I didn't look into them yet.

Regarding ptests there are some open issues of missing dependencies (like perl ptest), therefore we created an indivual ptest-execution script that only tests packages with the name xy- (where xy is our company shortcut, all packages from us are separated this way). There is also an additional package that only contains ptests for software from public openembedded and yocto layers we want to test.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.