Tracking Integration With Yocto/OpenEmbedded

Yocto is an Open Source project (based, in turn, on OpenEmbedded and bitbake) that allows you to create your own custom Linux distribution and build everything from sources (like Gentoo does). It's mostly used for embedded software development and has support from many hardware vendors. Having source build in place allows you to customize almost everything. In recent years I was faced with problem of development integration - to allow distributed development teams to cooperate and to supply their updates effectively for central build system(s). The purpose of this process:

• to know if the build is successful after each delivery
• to have high resolution of builds (to allow regression tests)
• and (of course) to launch automated tests after each build

So we need some channel that would allow to effectively detect new software versions and trigger a build based on them. There are two general approaches for this problem:

1. enable a "drop space" for files with source code and detect the newest one and use it for the build
2. connect directly to development version control systems and detect changes there

1st method is easier to implement (no need to open any repository for access from vendor side). 2nd method, however, is more powerful as allows you to do "topic builds", based on "topic branches", so I'll focus on second approach there. bitbake supports so called AUTOREV mechanism for that purpose.

SRCREV = "${AUTOREV}" PV = "${SRCPV}"

If it's specified such way latest source revision in the repository is used. Revision number (or SHA) is used as a package version, so it's changed automatically each time new commit is present on given branch - that's the purpose we place ${SRCREV} inside PV (package version) veriable. Having such construction in your source repository-based recipes allows you to compose builds from appropriate heads of selected branches. Of course, on each release preparation, you need to fork each input repository and point to proper branches in your distro config file. Then the process should be safe from unexpected version changes and you can track any anomaly to single repository change (ask vendor to revert/fix it quickly if needed or stick to older version to avoid regression for a while).