Exception Message: Unable to create the workspace '9_20_NAME' 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 D:\Builds\NAME is already mapped in workspace 9_22_NAME. (type MappingConflictException)
Exception Stack Trace: at Microsoft.TeamFoundation.Build.Workflow.Activities.TfCreateWorkspace.Execute(CodeActivityContext context)
at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
So the above has been plaguing me for just over a week now and on the surface it seems like a simple issue, delete or rename the workspaces and move on. However this issue won't shift that easily.
In short I have tried the following:
Cleared Workspaces
Created new build definitions
Moved the build folder location (e.g. D:\builds\name to D:\builds\name-2)
Build machine restart
Uninstalled / Reinstalled TFS (2013 update 3)
Rebuild the build machine and restored the TFS database
I've pretty much narrowed down the issue to something within TFS itself, but for all the good will I cannot find out what.
It's worth noting that when I delete the workspaces (using TFS sidekicks) the builds will run upto a handful of times. I've not narrowed down exactly what causes change from success to failure, however I can delete all the workspaces then run the builds a couple of times without issue and then suddenly this will come back (around 2-3 builds before constant recurring failure).
My solution was to edit my build definitions > Source Settings > Build Agent Folder and change this from a hard coded value to $(SourceDir).
A team member pointed me to this answer but I'm none the wiser as to why this setting would cause this behavior.
You will need to go to the build machine, search for the old workspace that use the same build definition name, delete that one so the build can create new workspace with the same name again. Check this blog: https://mohamedradwan.wordpress.com/2015/08/25/unable-to-create-the-workspace-due-to-a-mapping-conflict/
Also, try to rename your build definition to something unique to see whether this will fix the issue. http://blog.casavian.eu/2014/04/02/build-workspace-issue/
Related
It seems that I've run out of room on my Master node and I need to clear some space in order to reboot my daily tests. Selenium.log is taking up a lot of space and I'm convinced its not currently being used. Would it be safe to delete?
Edit: I deleted the file and upon starting a new build Selenium created a new log file. I didn't experience any issues during this new build either.
You don't say what creates the file, or where it is, but assuming that you can already see the important details from each build in the Jenkins UI (e.g. in the console log, or in test results etc.), then you shouldn't need to keep any files that are sitting in the workspace or elsewhere.
I download visual studio code for mac today. I tried to create a simple asp.net 5 web application following these instructions https://code.visualstudio.com/Docs/ASPnet5
When I open my web application folder in visual studio, it says I need to run a restore command.
I ran the dnu restore command just like the instructions tell me but it seems to always fail.
I receive different errors every time I run it. But most of them are like this one:
CACHE https://www.nuget.org/api/v2/package/System.Threading/4.0.10-beta-22816
SharpCompress.Common.ArchiveException: Could not find Zip file Directory at the end of the file. File may be corrupted.
Restore failed
There is a stack trace as well, but for brevity sake I'll omit it for now
Has anyone experienced this?
Try dnu restore --no-cache.
You may also need to remove previously downloaded files - check ~/.dnx/packages. I removed all files from that folder some time before trying the above. Also, see the comments below, if ~/.dnx/runtimes contains unexpected versions removing them may also work. Note that the current runtime version can be controlled using dnvm.
I never saw the NullReference exception, but I was getting the SharpCompress.Common.ArchiveException. I suspect there was a mismatch from what dnu thought was the cache state with the actual cache state (maybe something timed out the first time or something).
Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately
I have a build step that is part of my deployment configuration. My coworker told me it had worked once in a blue moon
I kept on getting this error consistently when I ran this build step:
Deleting dirPath (qa.comedy.net\aspnet_client\system_web\4_0_30319). [15:22:22]:
[VSMSDeploy] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.\We
\Microsoft.Web.Publishing.targets(3588, 5): Web deployment task failed.((3/28/2012 3:22:22 PM) An error occurred when the request was processed on the remote computer.)
Attempt to perform an unauthorized operation on file '4_0_30319'.
It seems that it is trying to delete the folder
aspnet_client\system_web\4_0_30319 , but has no permission to.
we run this build on a virtual machine.
Any suggestions on how to resolve this?
All help is greatly appreciated.
Thanks
I had this issue deploying as site with msdeploy and teamcity. I resolved it by deleteing these folders from my website aspnet_client\system_web\4_0_30319
Yes you can delete this folder and the next deploy will work, but with the next windows update that runs the asp.net registration tool as part of it's install will add this folder back to all asp.net sites on IIS (with the incorrect permissions) - so your deployment will fail again. You can avoid this by
Giving the deploy user elevated privileges (not a great solution for
obvious reasons)
Add the folder structure to your SC so it gets
deployed instead of the deployment trying to delete it (not ideal, but easiest)
Stop automatic windows updates (not sensible)
You might be able to do
something like this
http://blog.richardszalay.com/2012/12/18/demystifying-msdeploy-skip-rules/
to ignore the folder in deployment (I've not tried this)
As MemeDeveloper mentions in their answer, one way to fix this is to simply ignore that directory. Indeed, this is the easiest fix and doesn't require adding anything to your source control repository or build output. Just add the following to your msdeploy.exe command:
-skip:Directory="aspnet_client"
I wasn’t using TeamCity but I think I also had this issue. I was trying to deploy to Discount ASP.NET using VS2010 WebDeploy. After reading what doglin and Dan posted, I found I could workaround this problem by checking the “Leave extra files on destination (do not delete)” box. That may not be an option for everyone but it worked for me.
I faced the same problem during WebDeploy in TeamCity. I end up elevating privileges for WebDeploy account under which I do WebDeploy task. So the account have enough power to delete those folder (local admin role).
I just downloaded the free trial of Bamboo continuous integration server, and created the first plan with nothing but downloading the source code from the git. I have a local git repository on the bamboo machine so the git URL is pointing to a local path.
The problem is that when I run the job, it never finishes even after waiting for an hour. This is the last lines of the activity log:
07-Apr-2011 20:03:23 Checking out revision f9dc82500914333ed4bbdae5ed038771fd658c3c.
07-Apr-2011 20:03:23 Creating local git repository in '/home/bob/bamboo-home/xml-data/build-dir/DEV-DEV-1/.git'.
From the shell I can go to the directory shown in the log and see that the source code were cloned correctly to the bamboo working directory. But the job will never finish and the log will not have any more update from here. I have to manually terminate the job. Any ideas? Do I miss something?
Just a guess, since the Bamboo instance we have at work pulls from Accurev and not Git, and I've never run into this problem myself - but it may be hung because there isn't a builder defined for that plan. You might try defining a builder (even if it's one that you know will fail) just to see if it makes it to that next step.
I had very similar problem.
It's not very original solution but I just uninstalled bamboo and installed it again.. Now it works now