We have been using CC.NET as our CI server for a month or so now, which has worked ok with TFS. In the config we were able to specify the TFS server, username, password, project and workspace which is all good.
Now we are moving over to TeamCity mainly because it just seams more solid and is much nicer to use. The problem is getting it work with TFS.
For the purpose of this, both the workspace and machine name are "BuildMachine", username is "BuildUser" TFS project is "$/Project/Dev/Website"
I seam to have set it up correctly, I think, as when testing the connection it is successful. When I run a build I get a TFS error: "RunBuildException when running build stage UpdateSourcesFromServer."
It goes on to say: "No matched workspaces were found. Will recreate workspace and perofming clean checkout."
It then tries to create a new workspace something like this: TeamCity-S-sqa9qe2aulx22gz4rzkogl5kr/BuildUser
It tries to set up some mappings and then fails because: "The working folder C:\ is already in use by the workspace BuildMachine;BuildUser on computer BuildMachine".
This seams ok as this is the workspace that CC.net was using, and c:\project\dev\website is the path to the project. The problem is, why didn't TeamCity pick this up and use this workspace? Why does it try to create its own new one? Any idea how I can fix this?
Thanks
I seem to have fixed this by simply changing the path for the BuildMachine workspace to c:\BuildMachineWorkspace\ instead of just c:\.
I guess this means that the whole of c:\ is no longer a workspace therefore other workspaces can be created on c:\.
Related
I have been slowly attempting to get the TFS build to work. After some other fixes with other issues, I have gotten to the point where the build will throw the below error. Not exactly sure what to make of the error. I have double checked to make sure the Resources folder is in the solution. However, the file called "resources" is not, but there is a file named "resource". I know this is not much info to go on, however I am stumped at this point.
Suggest you first remote to the build agent machine and check if there are corresponding G3.Resources.resources under path G3.Resources.resources C:\agent\work\1\s
\G3DEV\obj\Debug\G3.Resources.resources
Double confirm the Mapping settings correctly and not cloaked some files.
Try to manually use VS or MSBuild command to build your solution directly on your build agent machine. This will narrow down if your issue is related to TFS build definition side or not.
You could also Enable Verbose Debug Mode for TFS Build vNext by add system.debug=true to get more detail log info for trobuleshooting.
I have a working Jenkins TFS setup, but can't figure out how to stop the Jenkins TFS plugin from deleting the whole workspace and downloading it again each time.
I just want it to do the equivalent of "Get Latest" and not delete any files that are up to date.
Here is the message I'm getting in the console when this happens:
Deleting workspace as the configuration has changed since a build was performed on this computer.
I can't figure out what is causing this or how to disable this behavior.
This doesn't always happen when I build the project, so something is causing this to happen.
It can happen even if I don't change any configuration stuff in Jenkins.
Option to "Delete workspace before build starts" option is off.
I have found the message in the Java source for the TFS plugin here, but
don't understand what is causing it: Java TFS Plugin in GitHub
Environment:
Jenkins v2.60.3
TFS plugin 5.121.0
Windows 10 64-bit
Java 1.8
Console log when this happens:
Building on master in workspace D:\Jenkins\workspace\XXX
Deleting workspace as the configuration has changed since a build was performed on this computer.
Downloading list of workspaces from https://tfs.company.com/tfs/Projects...
Deleting workspaces named 'MASTER-XXX' from computer 'ALAN-XXX'...
Deleted 1 workspace(s) named 'MASTER-XXX'.
Querying for remote changeset at '$/XXX' as of 'D2017-08-29T09:46:26Z'...****
In your Jenkins Project configure Page ,there is an option for deleting workspace before build starts in Build Environment section. Double check if you are checking this option or not.
The plugin checks the latest build configuration and compare it with the current job. If there is any difference/change exist, you will see that message. The configuration it checks is the settings in "Source Code Management". Since you mentioned that it also occurs when you didn't do any change, I suspect that it may caused by some variables you used in "Workspace name" changed. You can also check and compare the "build.xml" for the two builds in Jenkins Jobs folder to see what change cause the issue you meet.
When we do team builds using tfs 2013 we occasionally get the following error:
Exception Message: Unable to create the workspace '41_9_UKBOLTFS6' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'.
Details: The path C:\xxx\xxx\xxx is already mapped in workspace 41_9_UKBOLTFS6. (type MappingConflictException)
If we kick off a new build it may succeed, if not we try again and eventually it works without any changes.
I have seen very similar questions posted on stackoverflow about this but non where the workspaces it is complaining about are the same '41_9_UKBOLTFS6'.
We migrated most of our builds from TFS2010 but not all and we never had this issue before.
Does anyone know what is going on?
This occurs (as the error suggests) when you have a workspace clash on the build server. Workspaces are saved as configuration values in the TFS database so clashes are possibly caused by:
you have created a new build definition with the same name as a previous build definition.
some part of your workspace name (or an artifact within your project) is over 260 chars
build definition is not using $(sourcedir) macro in System Settings tab
More details are explained in this article
Possible work-around:
Rename your build definition to something unique.
Looks like you have multiple team builds mapped to the same local directory. Make sure that the Working Directory in all your agents are unique and there is no absolute path in workspace settings of your build definitions
I've run to this issues and blogged about my solution without renaming the build definition. Check it out here: https://christiaanmolendijk.nl/2016/05/23/before-stressing-out-tfs-cache-folder-on-build-server/
Summary of the link:
Go to cache folder: {userprofile}\AppData\Local\Microsoft\Team Foundation\{version}\Cache
Edit file VersionControl.config in Volatile folder
Then go back to the cache folder at {userprofile}\AppData\Local\Microsoft\Team Foundation\{version}\Cache and delete the folders with a GUID as name.
This question already has answers here:
Team Build Error: The Path ... is already mapped to workspace
(24 answers)
Closed 8 years ago.
It's been asked a lot, and for 2 days, I've tried to resolve, with no success. I am running TFS 2012 Express, on Win7. I have installed VS Express edition on that machine. I can check in fine. I am trying to set up a Continuous Integration build.
But, when I force a build on the build server, I get the following error:
Unable to create the workspace '2_1_Server' due to a mapping conflict.
You may need to manually delete an old workspace. You can get a list
of workspaces on a computer with the command 'tf workspaces
/computer:%COMPUTERNAME%'.
Details: The path C:\Builds\Finance is already mapped in workspace
1_1_Server. (type MappingConflictException)
(Not sure where it gets "C:\Builds\Finance" from....)
I then try what it says on my dev machine, and it asks me for my login credentials on the build server. I enter them, and it tells me:
That seems fine, no?
On the server, I check my Build Agent working folder:
d:\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
I am not sure where the conflict is.
Interesting, if I load a different team project on the same server, it builds. I just created a build definition for this project, and it seemed to build successfully. I think it has something to do with the Build Definitions, as these projects were moved from another TFS server.....
Can anyone assist?
Install the free tool Team Foundation Sidekicks, and use it to delete any workspaces for your build server via Tools > Workspace Sidekick (i.e. with your build server's name in the workspace search result's Computer column). (Don't worry; TFS builds will recreate them):
Then go and delete everything under d:\builds on the build server.
Then check the workspace mapping by editing each build def under its Source Settings tab, and ensure they are using $(SourceDir) as part of the path for every mapping defined.
If the builds have the paths hardcoded instead of using the $(SourceDir) token as the root, it might explain the behavior you are seeing.
I am attempting to use CI on a Branch of one of my TFS projects. MSBuild only fails when I try to use a Branch. I point the same Build at the "trunk" project it works fine.
The error I receive from the build log:
Task "Label"
Label TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6763"
Name="Test_SF_20090619.1"
Scope="$/MyProject" Recursive=True
Comments="Label created by Team Build"
Version="BuildServer3D143_66"
Child="Replace" Files="$/" C:\Program
Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(812,5,812,5):
error : No matching items found in $/
in your workspace.
Done executing task "Label" -- FAILED.
Done building target "CoreLabel" in project
"TFSBuild.proj" -- FAILED.
I believe this error is being caused by a lack of source files getting copied to the Build server.
Get task excerpt from build log:
Task "Get"
Get TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6768"
Force=True Overwrite=False
PopulateOutput=False Preview=False
Recursive=True Version="C204806"
Workspace="BuildServer3D143_66"
Done executing task "Get".
This is a full build. There should be about a thousand files listed in the GET.
General Information
TFS 2008
Visual Studio 2008
Established build server (been
running builds for the last year)
Project being branched is a ASP.NET
web stie (2.0 Framework).
Full Build Params
/p:SkipClean=false
/p:SkipInitializeWorkspace=false
/p:ForceGet=true
/p:IncrementalBuild=false
/p:IncrementalGet=false
note: I know IncrementalBuild is redundent but I just wanted to be sure.
Questions:
Are there restrictions on builds off a branch?
Any idea why MSBuild fails to pull files from the branch workspace?
If it's for CI then you're most likely doing an Incremental Get. TFS will only bother to get files it thinks have changed since its last get - e.g. if you delete any files from your server, it will still think you have those files so it won't get them again. In this case you'll need to run the build once with the incremental properties turned off so that it forces a full get of the source. You can do this by overriding the properties in the MSBuild command line box in the Queue Build dialog with:
/p:IncrementalGet=false;ForceGet=true
Another possibility that springs to mind is that the Label task is confused by your branch. It may be that your workspace is set up incorrectly, so check that you're mapping in everything it needs.
I had two issues in this case.
First, the branch security did not give rights to the build service account. I had restricted the branch to our team's Tech Leads and Release Engineers. The build service account needed access as well. What tipped me of was while searching the internet I stumbled upon a posting by someone who had made the same mistake.
The second issue was a little more involved. While cleaning up my build project file, I removed the following section.
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../_stage/MyProject/MySolution.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
Which worked fine on projects I had already built at least once, but if this was a new build, that had not copied source files to the build server, then there would be no files and the build would fail.
Some of you may wonder if my other builds were working either, after all wouldn’t they have old build files. Yes, but I had targets defined that did all the work I actually cared about. So the SolutionToBuild is a little frivalous.