Triggering dependencies based on a submodule revision

Hello all, 

I have a configuration/layout question that I think should be possible but am not sure what the correct terminology is to find documentation for how this should be set up (an "inter-project Dynamic snapshot dependency?")

To summarize: 

I have a build configuration that is triggering off a git repository with a few submodules. This repo is basically a "meta-repo" which brings together several related but independent pieces to produce a final output, for example:

  • MyMetaRepo
  • | - submodule1 (shared code)
  • | - submodule2 (some data)
  • | - submodule3 (some more data)
  • | - MyBuildScript that operates on submodules 1, 2 and 3

"submodule1" contains both shared code used by MyBuildScript, and a build process to compile "Tool.exe", which is also needed by MyBuildScript to work with data in submodule2 and submodule3

Herein lies the issue I am hoping to resolve: if I add a separate build step and snapshot dependency to build Tool.exe from submodule1 (using MyMetaRepo), then even if I make changes to submodule2 or 3 (the most likely type of change in this setup), Tool.exe will be rebuilt, despite the commit of submodule1 not having changed. (The agent used to run MyMetaRepo build configs is not capable of building Tool.exe itself and I must delegate this to a different agent)

I would like to avoid the rebuild of Tool.exe where possible, but want to retain the correct "parentage" of the Tool.exe as specified by the revision of submodule1. 

Submodule1 can potentially be attached as its own independent VCS root to build Tool.exe to achieve what I want via artifact retention and snapshot compatibility - but I cannot see how I would configure the snapshot dependency chain for this correctly - Essentially what I am looking to do is trigger on push to "MyMetaRepo", which will then "look at" the revision of submodule1 in order to select the snapshot version and artifact dependency of Tool.exe to build or use. 

I realize I can disable the dependency and require users to manually select a snapshot revision of submodule1 but this is less than ideal for the end goal of this configuration as it allows for unintentionally selecting a revision that is not the current commit referenced by submodule1.

I also know it is possible to script artifact retrieval via other means through the TeamCity API - but then you have the possibility of MyBuildScript being run only to find that no compatible binaries have been built for Submodule1.

How should I configure this sort of build dependency the "proper" way? I can't imagine I am the only person that produces binary output of a module in this way and wants to reuse it later. 

Thanks!

Please sign in to leave a comment.