Is it possible to prevent a build chain from being

Question

I have the following set-up in TeamCity 7.1.3:

Project A

• Build & Deploy A
• Test A (Quick)
• Test A (Slow)
• Test A (Very Slow)

Project B

• Build & Deploy B
• Test B (Quick)
• Test B (Slow)

All of the tests for A depend on 'Build & Deploy A' and all of the tests for B depend on 'Build & Deploy B'. The dependencies are all snapshot dependencies with the following settings:

• Do not run new build if there is a suitable one
• Only use successful builds from suitable ones
• Run build on the same agent

All of the tests have VCS triggers. The slow tests only run when particular folders in source control are changed. When a commit is made to project A, the following projects are added to the build queue:

• Build & Deploy A
• Test A (Quick)
• Test A (Slow)
• Test A (Very Slow)

Pre-commit builds run with higher priority in the build queue. As such, if while 'Build & Deploy A' is running a pre-commit check is made to project B, the build queue then looks like:

• Build & Deploy B
• Test B (Quick)
• Test B (Slow)
• Test A (Quick)
• Test A (Slow)
• Test A (Very Slow)

The problem with this set-up is that it will mean that the tests for A are run after project B has been deployed. This is an issue as the deployment of project B overwrites some of the files required by project A. The files which are being overwritten by the personal build are deployed files which are not in the checkout folder which is why they are not rolled back. Is there any way to enforce that the build chain for the tests isn't interrupted?

If I remove the 'Do not run new build if there is a suitable one' setting from the dependency, each of the tests will require a full build and deploy. The slower tests can't depend on other tests to make a linear chain as sometimes 'Test A (Very Slow)' is run, but 'Test A (Slow)' isn't.

Unfortunately it isn't currently possible to split the build and deploy to create artefacts.

Is there any way to efficiently set this up in TeamCity?

Answer 1

Here's what I'm gathering:

• A and B should be considered mutually exclusive.
• A should always have a lower build priority than B, but
• Once started, A should not be interrupted.

There may be a way to fight TeamCity on this; I don't know. If you're open to changing your process a bit, one of these might work for you :

1. Clone your environment such that A and B can be deployed to different targets. This would allow them run completely independently of one another. Use multiple build agents (at least one each for A and B) to allow the faster, higher priority B to execute at the same time as the slower, lower priority A. (This, I think, would be a significant perk.)
2. Make your process more atomic. Merge the various build/deploy/test pieces into a single configuration, thus ensuring that pending portions of the A build chain can't be displaced by B.

Answer 2

I solved the problem by making both 'build & deploy' build configurations write a text file to the deployment folder containing the build type and build number. All tests compare the values in the text file to the current builds snapshot dependencies. If they values are different, re-trigger the build (forcing dependencies to be rebuilt) and then cancel the current build.

Cancel build by calling:

http://teamcity.jetbrains.com/guestAuth/ajax.html?comment=<CommentMessage>&submit=Stop&buildId=<BuildId>&kill

How to trigger build with dependencies set to rebuild:

Is it possible to force a TeamCity build to rebuild dependencies when triggered over HTTP?

This means that when a test is running out of step, the deployment will be re-triggered and then the tests will run.