(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 (https://www.yoctoproject.org/) 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 (http://www.openembedded.org/Layers_FAQ). 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: https://confluence.jetbrains.com/display/TCD18/Version+Control+System+Plugin. I can't resolve how that make sense in the context of BitBake.