It happened now several times to us that the snapshot dependencies failed to work with Git. That is, we end up with build chains with snapshot dependences where the builds use different commits.
Here is a straightforward way to reproduce the issue:
- commit a change, push it to master
- start a build B1 using configuration C1, using this commit
- wait for the build to finish
- amend the commit locally, push it again to master
- promote the B1 to a configuration C2, that uses the same VCS as C1, and has a snapshot dependency with it
The build B2 of C2 will use the amended commit, not the original one.
The online help says: "Build configurations linked by a snapshot dependency will use the same snapshot of the sources.". This promise is clearly broken.
Another example is when the history of a branch is rewritten (forced push). It seems to confuse TeamCity greatly.
The documentation mentions:
"all builds linked via snapshot dependencies are started by TeamCity with explicit specification of the sources revision. The revision is calculated so that it corresponds to the same moment in time (for the same VCS root it is the same revision number)."
In the case of the amended commit, the revision number can probably not be found, so TeamCity falls back to the time based algorithm, which is a very bad idea in configuration management in general, and doesn't make any sense in the context of Git, that offers 100% reliability for free when using the SHA1.
It looks like the snapshot feature is broken by design, at least for Git.
Is that a known issue?
Are there any plans to fix it?