I have TeamCity 7 set up to run CI against multiple .Net/VS2010 projects. one of these projects is within a project collection that contains spaces, when I try to run a build on this project it adds it to the queue and says that no agents are compatible. When I click on No Agents it shows all of my agents under the Compatible Agents list.
The other projects I have set up differ only by the project collection they are under. The projects under other collections (with no spaces), and another set up against Git, all work just fine. Unfortunately, due to factors outside my control, renaming the project collection may not be possible at this time.
I have already made sure the project collection name is escaped (My%%20Collection for My Collection, per this JetBrains work item: http://youtrack.jetbrains.com/issue/TW-18726) and cannot find any other information on what to do to make it work.
Does anyone have any ideas why TeamCity will not work for TFS projects under project collections that contain spaces?
This is a bug in TeamCity that has been fixed. Upgrading to version 7.0.3 or later will resolve this issue.
Related
I have one Project in SonarQube with some history and some Confirmed Issues and I need split this project, because of two versions of source code, but I need the history and Issue changes in both projects. How to do this? It is possible somehow clone, duplicate existing Project to another one with different name?
Cloning or duplicating a project is not supported.
You can use the Time machine functionality of SQ to "recreate" the past analyses of the project under another name but it won't recreate the history of changes on issues.
We are currently running multiple branches within TFS 2013:
Development
Release
Trunk
etc.
Each branch has an automated test build. The purpose of these builds is to publish the latest code (and database changes) for each branch to our test server for manual testing. We maintain a separate IIS application for each branch so that different versions can be tested simultaneously.
Each branch has unique .csproj, .xml profile and web.config settings which control which application and database each branch deploys to, which works great.
However when we merge from one branch to another, auto-merge replaces these branch specific settings causing us to deploy our test builds to the wrong URL and database.
I am aware that auto-merge can be completely disabled in Visual Studio settings but is there a way we can continue to use auto-merge except for specific files?
Any suggestions welcome
This is a well known problem with any code promotion model. I would suggest that you move instead to a binary promotion model.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
With a binary promotion model you build the bits once with replaceable parameters and create or use a tool that orchestrates the release and feeds it with the correct variables for each environment.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
I recently built out an end to end scenario using VSO. You can see in the post the passing of the values for each environment.
The software industry is moving towards continuous delivery and continuous integration. Neither of which is possible in a code promotion model.
You could disable auto conflict resolving during merge, but in this case you have to resolve these conflict manually (ignore)
Options -> Source Control -> Visual Studio Team Foundation Server
Attempt to automatically resolve conflicts when they are generated
or you could use tf.exe for merge:
tf.exe merge /discard CS
use a changeset which will be always discard from merge.
TeamCity appears to store the definitions for builds, projects, templates etc as XML internally.
This is exposed in the "Administration > Audit" view where you can see diffs that people made to individual configurations, at URLs like http://teamcityserver/admin/settingsDiffView.html?id=project:project10&versionBefore=8&versionAfter=9&actionId=3151
I'd like to manage a TeamCity setup partially from outside the web interface - e.g. for example keep the build definitions in version control and perhaps programmatically generate them.
Is there any way I can directly upload definitions in this format (or any similar alternative)? I'm aware that there are various APIs and extension points to TeamCity but haven't managed to find any that gives direct access to anything like this.
I can live with the format changing with TeamCity versions if necessary - it would be a reasonable price to pay for the other benefits.
For TeamCity 9.x and newer
As reported by Ganesh in the comments to this answer, an option was added in 9.x that supports changes and versioning through Source Code Management (SCM) tools. Please see his answer for 9.x and beyond.
For TeamCity 8.x and older
It might not be the "approved" way, but you can edit the project files on disk, and those changes will appear in your build configs. I have successfully edited them outside of the Web UI after they were created.
So, you could probably open that folder up as a restricted network share or set up ssh.
You'll find it at $TeamCityData/config/projects/ and then they are stored in subfolders such as $projectName/buildTypes/$buildFile.xml
An example is:
E:\TeamCityData\config\projects\CSandbox\buildTypes\CSandbox_Project1TrunkBuildUnitTest.xml
TeamCity 9 adds a new "Versioned Settings" feature which keeps these XML files under version control and allows changes to be made via the VCS.
In TeamCity 9.0 this can be git or mercurial, and the upcoming TeamCity 9.1 will add support for Perforce and Subversion.
I've been using it with git for a few months and it works quite nicely in practice.
I sometimes have trouble persuading TeamCity to notice changes coming in from the VCS - particularly when deleting projects - but otherwise it's been really useful for standardising configuration and spinning up new job chains quickly.
Another slight annoyance is that you can't configure the location within the repository that the settings come from - it's always .teamcity in the root - so I've had to use multiple branches or repositories to manage multiple TeamCity servers.
I want to be able to build a web project and not its dependencies since I know that I have not modified any of the dependencies since the last build. I am looking to cut down the build time if possible. Is there a way to do this?
You could have a solution by
check the setting in Tools >> Options >> Projects and Solutions >>
Build and Run setting : Only build startup projects and dependencies on Run.
OR
If you want to go for sophistication then :
build >> Configuration Manager
from the "Active solution configuration:" dropdown select ""
give a name to your configuration and keep checked the "Create new project configurations" checkbox.
and then choose that config that you want and set the build or not check boxes.
To accomplish this in something I am working on, I created my own solution, added the projects I needed (including the projects I never wanted compiled), and then in the Configuration Manager turned off the check boxes for building the projects I didn't want to build, just as arora described above.
I've also made a copy of an existing solution (that had 16 components in it), saved it under new name (foo.sln -> foo.mine.sln), and then disabled the build of all the other sub-projects except the one(s) I am working on, that way I know for sure that I got the correct build settings.
It's not the simplest solution, but it works well for me, and takes less than 2 minutes to set up and is easy to understand. I normally add the new solution to the version control ignore list so that it never gets checked in.
Rather than project references you can just add the references to the dlls directly (the Add Reference dialog has tabs for these types, choose browse rather than project and remove the other projects from your solution). I typically create a full lib and web project solution for major development. Then just a solution for the website project for fixes where I don't need updated libs/dlls.
Although it is nice to have them autocompile if they have changed during heavy development. If they haven't changed it just refreshes them and recopies them to the bin folder.
Well one way would be to remove project references. Instead stick to dll references. You could use a post build script for dependent projects that copy the updated dll to the web project whenever they change.
I'm new to TeamCity and we have a number of common projects under source control that are then referenced directly within relevant projects i.e.:
Common
branches
tags
trunk
CommonProject
CommonProject.csproj
Common.sln
ProjectX
branches
tags
trunk
ProjectX.sln
As a result, the reference to "CommonProject.csproj" in "ProjectX.sln" is something along the lines of ....\Common\trunk\CommonProject\CommonProject.csproj which is fine within our development enviroments but when it comes to TeamCity it falls over saying it can't find the path "....\Common\trunk\CommonProject\CommonProject.csproj"
What's the best way around this problem? I've tried adding CommonProject to TeamCity as a dependancy but it still doesn't seem to want to play ball...
Thanks
Tim
We address this by using Externals in Subversion which allows you to pull in stuff from a different (bit of the) repository.
Then, when we're building the solutions, we have those common projects grouped into the same folders with project specific solution - i.e. when we check stuff out we have:
Solution1
+---Project1
+---Project2
+---Project3
+---Common1
+---Common2
Then, separately:
Solution2
+---ProjectA
+---ProjectB
+---ProjectC
+---Common1
+---Common2
Because we have the externals and the directory/folder structure set up this way you should, in theory, be able to checkout (or export) a "solution" to an empty directory and have it build successfully from scratch (subject to all the necessary tools being installed) and therefore TeamCity (or whatever your continuous integration server is) should be able to also be build it from scratch. In fact even before we stared using TeamCity I had this as policy but the value is clearer once you start doing continuous integration.
The appropriate bit of the Subversion Red Book is here: Externals Definitions