Programmatic build suitability with Yocto/BitBake

(I'm posting in this subforum because I think I will need to write a plugin to accomplish what I want)

We are using Yocto ( to build full Linux distributions. Right now, I am using TeamCity as basically a thin wrapper around "bitbake our-linux-image". BitBake fully manages the dependencies between components - it knows what it has to rebuild and what it does not (based on upstream revisions). So while we have 20-30 or so in-house components (with their own git repos and revision history) that make it into our final image, these dependencies and revisions are not visible to TeamCity. 

Furthermore, my build configuration doesn't actually have any VCS roots. I manually clone a layer manifest which describes the revisions of each layer to use ( But it doesn't seem useful to have either the layer manifest nor the layers themselves as VCS roots in TeamCity, because at the end of the day, we don't really care about their revisions. The layer and/or layer manifest changes relatively infrequently - it's the revisions of the actual components we care about. And those can change regardless of the layers or layer manifest.

That's the long-winded motivation for my actual question that follows. Say I have a build configuration A that runs "bitbake our-linux-image". At the end of the A build, I can generate a list of all the component revisions that were used. But I currently have no way of creating a build configuration B with a snapshot dependency on A, since as I described, we have no VCS roots. What I'd like to do is use the generated list of component revisions from A in the B configuration snapshot dependency. Is there a way for me to write a plugin to do this?

Perhaps I would need to write a VCS plugin to do this, which actually exposes the underlying component revisions? But then I'm not sure how I would accomplish the "building of a patch from version to version" requirement: I can't resolve how that make sense in the context of BitBake.



Hi Chris,

Snapshot dependencies don't require VCS Roots, at all. You can use dependencies without them. But as I just mentioned in the other topic, I'm afraid that that makes also TeamCity oblivious to what happens with the VCS.

You could have a plugin, but it seems to me that it would make more sense to simply have a script within a build step that runs that. You can extract it as a meta runner to have it anywhere where you want.


HI Denis, thanks again for the info. As mentioned in the other post I'll probably end up writing a plugin. I could certainly write a script that manually detects whether the underlying stuff to build has changed (and in fact I might do that in the meantime), but ultimately I'd like a high level of integration with TeamCity's UI. So plugin it is :)


Thanks again,



Regarding what you said about VCS roots: I am also using Yocto to do builds for a company project. We have our own layer which contains recipes for company-specific packages. That layer is in its own git repository. I found it is useful to have an "umbrella" git repository to manage the layers for a particular build, using git submodules to track the git repositories for each layer.

Some people apparently find git submodules confusing. But I find the submodules feature is fine, and suits this purpose well.


Please sign in to leave a comment.