Can TeamCity commit the output of one build to another svn repository, thereby starting another build?

Question

So far, I've only used TeamCity as a continuous build server. No true integration. Now, I have the need to copy the output from one shared project to two other dependent projects, and kick off their automated builds in turn. That is, ProjectA and ProjectB both depend on ProjectC. All three are currently being built by TC when any commit occurs in their respective repositories. What we desire, is for the output of ProjectC to be copied and committed to ProjectA and ProjectB. Such a commit would in turn start the build process of both dependent projects. This seems like it would be a common scenario when talking about continuous integration. Is it not?

To clarify, we're using TeamCity v.4.5.5 (build 9103), SVN, and nAnt as our build runner.

EDIT: I mispoke when I said something about committing to another repository. They actually all three reside in the same physical repository, just at different levels in the hierarchy.

Answer 1

Typically you don't commit build output to your repositories. Are you sure that's what you want?

You can make TeamCity copy the output (artifacts) from one build project into directories of another, but in order to commit it, you'll need to add some scripting, like a batch file or similar.

Answer 2

I don't know whether TeamCity supports this, but this should be easy to script by yourself - as a last step of build in ProjectC add a script that will checkout ProjectC directories (not whole repository, just a directory where you keep binaries of ProjectC) from ProjectA and ProjectB, copy all required files and commit with some autogenerated message - seems quite simple.

However - this is dangerous. Build of ProjectA and ProjectB could break because an API of ProjectC changed, or some untested part of code was broken. This could disorganize work of teams A and B. I would go for solution where new version of libraries are commited once a day / a week / any other time period.

Also, it might be a good idea to create an automated changelog - for example, if you trust quality of your svn log messages, you could create a changelog from all "new" commits included in commited release (or append current log message, if you decide to choose to push new libraries after every commit). This way teams responsible for ProjectA and ProjectB will be able to easily fix their build if new library breaks it - they'll know exacty what was changed, without need to check manually/ask team C.