TeamCity Build Steps Setup

Question

I'm trying to figure out how to configure TeamCity build steps to accomplish the following tasks:

1. Call a console app that merges the dev branch to the test branch (in TFS) and modifies some of the files manually in the test branch that are used for the projects configurations. This process works perfect and has been tested. Also note, this step does not check in the merged files or modified files to the test branch.
2. This build step will kick off the actual solution build for the test branch. (This is C#.NET, but I don't think that is significant)
3. This build step handles the database migration for any SQL scripts added. (This step has also been tested and works)
4. This step calls another console app. This step will run even if a previous steps fail. If the build has been successful it will check in the pending changes from step 1, and do the deployment of the build. If the build has failed in a previous step, it will undo the pending changes from step 1.

That seems simple enough to do, but I the interaction between steps 1 and 2 is what I don't know how to do. If I use server-side checkout for step 2 it will pull the source from the server and not use my changes in step 1. If I user agent-side checkout, my understanding is that it will create a new workspace and pull the source from the server, again not using my changes in step 1.

Is there a way I can make step 2 build with the pending changes created in step 1? The only other option I can think of is to check in the changes after step 1 and rollback the changeset in step 4 if the build fails. In that case though, how would step 4 know the changeset to rollback?

---

Also I have one smaller question, how can I pass the success of the build as a parameter to step 4? I looked through the built-in parameters but I didn't one for build failure/success?

Thanks!

Answer 1

It would be useful if you could give the VCS name you are using(Git/SVN). I see you question is mainly on 2 main points

• If you are using Teamcity build Steps , where in all build steps are part of a single target you do not have to worry about interaction between Step 1 and Step 2 . All steps can run in the same directory . You always retain your working copy status throughout the sub steps.
• The only glitch in teamcity is that you can not run a build/step "only if a previous step fails". To get around this, you can create a failure
  file in any of the previous steps and run the build only if that file is present. Delete the file at the end of every build just to ensure that there are no accidental issues in the next build.

So, in short your build steps can (1) checkout a branch, (2) merge another branch into it , (3) run build and db deploy, and then (4) commit your code /rollback your db changes if it fails based on a failure file.

For your second question, each teamcity step knows the success status of the entire build and the previous steps as mentioned here . The only step missing is " run step if any of the previous step failed"