Assemblies deleted between run of two TeamCity build configurations

0
votes

We have a teamcity with build configuration "Build (Trunk)" and "Deploy CI (Trunk)".

The "Build (Trunk)" has a VCS trigger "Triggers a build after a VCS check-in is detected" and its goal is to build the assemblies for deploy.

The "Deploy CI (Trunk)" has a Finish Build Trigger "Wait for a successful build in: Build (trunk)" and depends on the "Build (Trunk)" with an option "Run build on the same agent".

Sometimes the "Build (Trunk)" succeeds, the dlls are there (there is a build step that checks that) and "Deploy (Trunk)" fails because it is missing some dll for the deploy that was already build (and checked).

I end up with an error in the "Deploy (Trunk)" [MSBuild.ExtensionPack.Framework.Assembly] D:\TeamCity\buildAgent\work\d11b43f69b1be1cb\Source\Product\Build.xml(191, 9): File not found: D:\TeamCity\buildAgent\work\d11b43f69b1be1cb\Source\Product\output\Release\Application\Server\bin\Product.Server.dll

The dlls are there at the end of "Build (Trunk)" but somehow are missing in "Deploy (trunk)". Same issue occurs for another build configurations (unit tests).

When this happen, I generally run Build (Trunk) wit "clean all files in the checkout directory before the build" and it works. We are currently using TeamCity 10, but it happened on the TeamCity 9.

I have no idea how to determine the root cause and would like an advice on that.

2
teamcity
You probably want to investigate dependencies between builds and explicitly add artifacts to your build configuration which you can then download into your deploy configuration confluence.jetbrains.com/display/TCD9/Build+Dependencies+Setup – KeepCalmAndCarryOn
Yea, the shared snapshot with running multiple build configurations over it was the culprit. I posted the sequence of events as the answer. Thanks a lot for pointing me to right direction. – jahav

2 Answers

0
votes

You need to setup the first build configuration to publish your created artifacts to a common "Artifacts" directory, then create a snapshot dependency in the Deploy build configuration that will run once the artifacts are created. And in your second build configuration access the artifacts in the common location.

0
votes

I figured it out (thanks for directions). Basically it was a trouble with snapshot dependencies and multiple triggers. The Deploy must have snapshot dependency in correct version it expects. If the Build is run again (it has separate trigger from deploy: build on new revision), before the deploy for the former is run (separate trigger: when build is done), the Deploy detects it and performs clean checkout of the VCS:

[16:26:52] : Will perform clean checkout. Reason: The project sources on the agent are newer than requested

But the clean checkout will delete the dlls that are already in the checkout directory and thus they are not present to deploy.

Example (why "Deploy #4257" failed) - only one agent is present:

[16:17:25] Build #4257 was triggered because SVN has new commit, build has started.
[16:21:05] Build #4258 was triggered because of new commit, but only one agent can build, so the build waits for now.
[16:22:39] Build #4257 finished.
[16:22:39] Build #4258 starts, because agent is now free.
[16:22:45] Deploy #4257 was triggered, because Build #4257 finished, but can't be started, because Build #4258 is running now.
[16:26:51] Build #4258 finished.
[16:26:51] Deploy #4257 starts, but detects that in snapshot is newer revision than expected. According to its trigger, there should be revision from Build #4257, but instead there is revision from Build #4258. It will perform the clean checkout of snapshot before running its build steps and the built dlls (the wrong newer dlls from build #4258) are deleted.