Filtering Server Changes by Solution
TeamCity Add-in allows filtering TeamCity server changes ( any changes you have committed to the source control systems enabled in the TeamCity Add-in options, as well as your personal builds), which you can see in the My Changes window, as well as dotCover snapshots created on the TeamCity server: both can be filtered by the currently opened solution.
When you are working on several solutions simultaneously, filtering your changes by a solution makes it easier to review your changes. By default, filtering server changes is off. To enable it, press Control+Shift+Alt+T T or choose in the main menu.
For TeamCity Add-in to find suitable configurations to filter your changes or code coverage data, the following requirements must be met.
Requirements to version control settings
Case Sensitivity
Version control settings are case-sensitive. Make sure that your local version control settings and those specified on the TeamCity server are configured in the same way.
Checkout paths
If TeamCity Add-in finds suitable configurations for personal builds, but cannot find such configurations to filter your changes by a solution, this may mean that the checkout path on the TeamCity server points to a directory located deeper than the one monitored by your local settings.
For example, locally you have configured your source root as A/B/C/**, while in the build configuration on the TeamCity server you have specified the VCS root as A/B/C and added a checkout rule like +:D=>... This means that TeamCity actually monitors the path A/B/C/D.
Example
Let's consider a typical case when TeamCity Add-in cannot find suitable configurations and a workaround for it.
Settings that do not work
- Version control
In your version control system you have following directories:
root/src withsources androot/testsrcwith tests.- TeamCity server
On the TeamCity server you have 2 build configurations that use the same Version Control Root. The VCS root configured is
root.The first build configuration compiles the sources, so it has a checkout rule specified that points to
root/src.The second build configuration runs tests and has a checkout rule specified that point to
root/testsrc.- Developer's machine
On your machine your checkout includes everything under
root.
In such case the TeamCity Add-in will not be able to find suitable configurations because the configurations on TeamCity monitor directories located deeper in the structure.
Workaround
- Perforce
If the root directory is
root, you should add 2 views:root/src(include)root/testsrc(include)
- Subversion
Open Subversion settings in the options (), in the Search Changes in area, select Manually specified directories and click Autodetect. This will add the root directory.
Click Add and specify
root/src.Click Add and specify
root/testsrc.- Team Foundation Server
Specify the following TFS mappings:
root/src(active)root/testsrc(active)
Requirements to TeamCity user permissions and settings
If your version control settings are configured correctly and TeamCity Add-in still cannot find a suitable configuration, the problem may be in your user permissions on the TeamCity server. You should have permissions to view and run builds for the corresponding build configuration on the TeamCity server in order to be able to perform a personal build from TeamCity Add-in.
You can view your roles and permissions in different TeamCity projects on the My Settings and Tools page in the TeamCity web UI. If you do not have sufficient permissions to run a build of the desired configuration, contact your TeamCity administrator.
By default, personal builds are enabled on the TeamCity server. However, there is an option to disable personal builds. Make sure that personal builds are enabled on your TeamCity server for the desired configuration.