Let me first explain how we're setting up our build infrastructure.
We use GitHub for source control, and have a separate repository for each project that is used by more than one other projects. Tests are included in the same repository.
Dependencies are all retrieved using NuGet, both external an internal dependencies. We build NuGet packages for each of the projects, and these are exposed as artifacts though the TeamCity NuGet feed. We're using NuGet package restore to avoid checking in packages.
For all internal dependencies, we want to use the latest version. To do this, we have build steps that restore packages for all internal dependencies, update them to the latest version, commit and push the changes. (We're using agent side checkout) This happens before the MSBuild step.
This is nice as dependency references will be updated for local development when getting latest from source control.
We're using snapshot dependencies, with the "include changes from dependencies" option checked. This ensures a build chain is correctly setup, and works fine.
We ignore commits from the build system as part of the VCS trigger, to avoid extra builds.
The problem is the changes that are committed during the build don't play nice with snapshot dependencies. The "Updated dependencies" changes were included in the build, as the MSBuild step runs after the commit and push, however the changes are left in the pending changes list. This results in unnecesarry builds of dependencies, when builds higher up in the chain are started.
Any ideas? Is there a way of:
- Letting TeamCity know that the "Updated dependencies" changes are not pending?
- Having the snapshot dependency's "suitable build" detection to ignore the pending changes, similarly to with the VCS trigger rules?
Or perhaps there is another solution that I've not thought of.
Thanks in advance. As use of NuGet for internal dependencies grows, I can imagine more people looking to work this way.
ps. Attached is a picture of our build steps.