title: Fail build via REST API with TeamCity, from another build config, after build is already finished
body: <p>I have some integration tests that get kicked off by TeamCity on a successful build. I have had success using the TeamCity REST API in order to <em>tag</em> the build as passed or failed, but would actually like to mark the build status as passed or failed (in the same way builds are failed due to compilation or unit test failures).</p>
  
  <p>The <a href="http://confluence.jetbrains.net/display/TW/REST+API+Plugin" rel="nofollow">documentation</a> for the REST API is pretty sparse. Is it just not possible to do this through the REST API or is it undocumented?</p>
  
  <p>Clarification:</p>
  
  <p>Current process is as follows:</p>
  
  <p>"App" TC Build configuration actually builds the application and runs the unit tests.</p>
  
  <p>"Test" TC Build configuration depends on "App" configuration completing successfully. If "App" builds successfully (no compile or unit test failures), "Test" configuration kicks off, which pulls down the build artifacts and runs the live integration tests on the application. Prior to these tests being run, "App" configuration has a status of passing, since it compiled successfully and there were no unit test failures. </p>
  
  <p>What I am trying to do is to change "App" config status to failed, if the "Test" configuration failed. Currently I am merely tagging "App" as passed or failed, but the actual build status is always passing. Essentially I am trying to get the change log or history to show the red X icon for a failed build, rather than the green check mark.</p>
  
  <p>"App" and "Test" are 2 separate TeamCity build configurations. Since they are separate, Build Script Interaction, as suggested by @sharma, will not do the trick, since Build Script Interaction can be used to fail/update the currently running build configuration, whereas I am trying to update/fail a separate and already completed build configuration.</p>
  
  <p>Why do we have 2 separate configs and not just run the tests from the main build? Speed of course! The integration tests take up to 10 minutes to run, and we don't want to slow down the compile cycle just because the integration tests are running.</p>