I recently created a PlasticSCM account and I am in the step of creating a new distributed Plastic Cloud repository. However, whenever I tried to create it, I encounter the following errors
No connection could be made because the target machine actively refused it 127.0.0.1:8084
Window that appears when I tried to create the distributed repository
What can I do to proceed on this? Thanks!
I got this same issue in Unity when I tried to remove the Organization name from the autofilled Repository name.
The Repository Name field defaulted to:
Project#OrganizationName#cloud
I changed it to: PROJECT. That's when I got the error message
Updating only the project name and leaving the original autofilled part with "OrganizationName" and "cloud" solved the problem for me: New-Project-Name#OrganizationName#cloud
By default, any changes to the Repository Field also updates the Workspace Name.
Found some information later: UNITY PLASTIC SCM Setup Guide under "Create a workspace and repo" (hidden in navigation further down the page)
Related
My team decided to integrate our code with Xcode Server to use Continuous Integration. We use a Mac Mini for host the Xcode Server, and we can create bots without problems in this machine, but the integration proccess always fails.
We have in "Repositories" tab selected the branch where we want run the bot, and we get next error:
Assertion: Configured project or workspace could not be found, it may
have been renamed or moved after the bot was created
How could we solve this? We didn't move the .xcarchive
Make sure you created the bot from the same project workspace that will be downloaded from the repository.
i.e. Download the project locally. Open the workspace. Now create the bot from there.
I solved this issue only changing the way to host locally the project. We have the project in SVN with trunk and some branches and I was downloading all project locally, so, after some tries changing the structure of one branch for test, I downloaded each branch separately. After this, I created the bot for each branch and now it runs successfully.
So, the solution is: Download separately each branch and trunk, and after create the bots.
For a specific project in my TFS 2015, a vNext build agent is unable to sync source code from the repository.
Only message I can see in log file is:
Starting: Get sources
Syncing repository: RDW (TFVC)
Workspace Name: ws_d565d474_34;Build\1b470f52-2a65-4b67-a68a-b8c32cebcad5
Done syncing repository RDW to version C283662 (workspace version -1)
Note that "workspace version -1". If I check the work folder on my build agent server is empty (not even created). Still the workspace on TFS side is created (checked with TF).
I checked the permissions assigned to the account I'm running the agent on and all seems fine.
I can't find anything in the log, nor on TFS, nor on agent computer.
It is happening only for one project. I tried with a different build server but the outcome is the same.
Does anyone have any tip on what should I check in order to try to solve this problem?
Thanks
I found the answer to my problem. I had the permission inheritance switched off on the folder in the source control under which all of my branches lied.
I do analyse the problem in a bit more details here http://blog.majcica.com/2015/12/24/tfs-2015-build-agent-failing-syncing-the-repository/
The build agent service account needs to be a member of the Build Service Accounts group.
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.
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:\.