Is it possible to schedule two jobs after each other - where one only runs if VCS changes?


We have just recently starting using TeamCity instead of CruiseControl for some of our builds.

What I have setup is a configuration template that does the following:

  1. Build the software from a subversion repos
  2. Restores a database backup to a given SQL server
  3. Upgrades the database to the version that matches the built software
  4. Runs some performance tests in code that utilizes the newly restored database.

I want this to execute nightly, for both the trunk and for a latest release tag to be able to compare performance metrics.

This setup is easily done in TeamCity letting the Tag configuration depend on a succesfull build of the Trunk configuration.

The challenge is, that the restore database and upgrade step takes several hours to complate for both trunk and tag. Actually so long that it becomes hard to run both configurations during the night.

So one solution, could be that the Tag build, only does the three first steps, if there was actually some changes in the Tag branch. I.e. we have had to create a hot fix to a previous release.

Is it possible in Team City to create such a schedule?

1. Run Trunk configuration completely every night (step 1-4)
2. When finished, investigate Tag in Subversion
    a. If pending changes - do all 4 steps
    b. If no pending changes only measure performance

Let me know if any of you need any further details to answer this.

Best regards

Comment actions Permalink


It is not possible to execute some build steps and to skip others. You can create four different build configurations and configure Snapshot dependencies with option "Do not run new build if there is a suitable one". In this case you will need to set finish build trigger on the 4th build in build configuration.

Comment actions Permalink

Hi Alina

It sounds like Snapshot dependencies is the way to go if I want to build this scenario.

In the meantime I have discovered, that the reason my build step is taking so long, is that the SQL server backup I restore was in the middle of a Rebuild of Full Text indexing when it was backed up.

For SQL server, this means that as soon as it is restored, it will continue doing full text indexing. And that leaves a big, heavy IO footprint on the server.

So my current solution to the problem has been to restore the database manually, wait 5 hous for Full Text indexing to complete, take a new backup and use this backup set in my nightly restore/test cycle.

During the weekend each build only took 3 hours each.

Which means I have no problem running both of the configurations fully every night.

But thanks for your reply, which I have marked as an answer - for future reference.

And this just concludes what is always the case when trying to optimize something. Measure first, optimize later. Often the measurements reveals a hidden bottleneck.

Best regards


Please sign in to leave a comment.