Committing DLLs to SVN during TeamCity build

1
votes

I would like the TeamCity build process for one project inside an SVN repository to copy its DLLs into a 'lib' subdirectory of another project inside the repository, and then commit.

The project whose lib directory should be updated is 'mapped' to a subdirectory in the TeamCity checkout directory, using VCS checkout rules:

+:proj1/trunk => /
+:proj2/trunk => /Downstream/proj2

Having used MSBuild on the .sln file to build proj1, I am able to use a command line build step to copy the proj1 binaries I need into the proj2 subfolder:

robocopy bin\Debug Downstream\proj2\lib file1.dll file2.dll file3.dll

My problem is that Downstream/proj2 is not an SVN working copy so I cannot run an SVN commit from it.

How can I perform an SVN commit from TeamCity - where is the working copy to commit from? Should I leave out proj2 from the VCS checkout rules, and check it out in my command line step before copying and committing?

It seems strange that TeamCity's working directory has had .svn stripped out.

1
svnmsbuildteamcity
An alternative would be to make a NuGet package containing your Proj1 libraries and store it in TeamCity's NuGet server. Then you can manage those dependencies in Proj2 using NuGet. - mattyB
That's a great suggestion, I would love to use NuGet, but the team architect is keen to store libraries instead so that each project points contains the correct libraries each time it is branched. - Chris B

1 Answers

2
votes

The answer was to install the SVN client onto my agent and change the VCS Checkout mode of the build configuration to 'Automatically on agent (if supported by VCS roots)'. If checkout is done on 'Automatically on server', only an export (without .svn directories) is copied.

Given a working copy in my build agent's working directory, I can then do a non-interactive command line check-in.

One gotcha: since I am committing to a project in the repository that is being checked out by the same build config, I had to edit my trigger rules to not automatically kick off the build configuration if the commit was being made by the non-interactive user that was doing the automated commit. Thankfully I realised after it had only gone round in a loop 3 times :)