TeamCity：如何将未版本控制的配置文件放入已签出的存储库中？

Question

I'm using a Git repository to version control my application. My project structure is such that I'm using config files that are localized to each environment the app is running in. These local config files contain things such as SQL connection strings and other info that is pertinent to each environment (each environment has its own SQL Server database, including the test environment in Teamcity). These files are not part of the repository, but are created newly when a new environment is created. In this paradigm, TeamCity is yet another environment and I have created a config file for TeamCity to use for building and running NUnit tests for my application.

My question is: How can I copy this file that is NOT under source control to the folder in which TeamCity checks out the repository? And how can I do this before TeamCity starts building my application? I'm sure this is possible as I've read here that "Machine-specific settings (like configuring SSL communications, etc.) should be configured on each machine using agent-side checkout." How exactly do I go about doing this? I could not find a straightforward answer from the documentation.

I read this thread that mentions the possibility of using multiple roots, which means it will pull the public sources from a public repository and private sources from a private repository with restricted access, and the access would only be given to TeamCity. This is a decent solution and I can see how this could be easier to maintain than having a batch file or something copying the private/local files every time a build is run, but for some reason I don't feel comfortable putting passwords etc. in a repository. I'm not sure why I have this bias (it just seems like it could be vulnerable) and so if anyone has any experience with either or these solutions, I'd love to hear about them. I'd also like to hear opinions on storing sensitive information under a password-protected repository. Is this a safe practice?

Thanks to anyone who can help out.

PS: I've looked at the Edit VCS Root page and the "Custom clone directory on server" setting, but I still don't know how to copy a file to that directory. Does the working directory for TeamCity change or does it stay the same?

Answer 1

I don't like to put passwords in version control either, especially not externally hosted version control like Github.

I just put config files somewhere on the build machine outside of TeamCity and put a Command Line step in the build that copies them in to place before they're needed. Generally,

• set "Command executable" to your copy program
• set "Command parameters" to the source file(s) and target directory.

You don't need to worry about where the TeamCity work directory is, since the Command Line step's current directory will be your build directory and you can use a relative path as the target.

I won't try to give specific examples because I use a different stack than you, but I think the same principle should work.

Answer 2

I ended up going the route of having a second private repository to store configuration files after examining the security aspects of having a public-facing privately-accessible repository that has sensitive information. This technique is described here .

However, that link doesn't address a major issue with using multiple VCS roots - unless the checkout rules are modified, Teamcity copies the first VCS files to the checkout directory, deletes all the files, then copies the second VCS files to the same directory. I have no idea why this behavior was chosen as the default. This obviously fails the build because the original code files are no longer there.

The solution is described here . Basically I had to setup the checkout rules to move the files copied from the first VCS root to a subfolder, and then have checkout rules on the second VCS root to move the config files to the correct location within that subfolder.

Now to the core issue: security implications of storing sensitive information in a public-facing privately-accessible repository. The important adjective here is public-facing. My basic requirement for security in this scenario is that the repository should have as much security as a Windows folder that is secured using the Security tab. The argument I use to justify that it is even more secure as a private Git repository is that is uses either HTTP or SSH security, which one could argue is just as strong, if not stronger, than Windows folder security since these are more exposed than Windows folders. Since this is just going to be storing the login info for the test environment, I'm not too worried about it. All sensitive info for my production environment will be handled manually. But I'm open to opinions on this topic. Hope this solution helps other people. Please feel free to comment/ask questions.