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.
Related
I have an instance of TFS 2015 with vNext builds working on my DEV branch.
I cloned a working build definition and set the Maps and solution file to the corresponding paths on the Main branch. On the Main branch they fail with the error message: "Could not find a part of the path 'C:\agent4_work\5f9b9727\myTfsProjectName'." This path is not even being created in the _work directory like is when I use the paths for the Dev branch.
Notable similarities between the two builds:
The build steps being used in both cases are the NuGet Installer and Visual Studio Build steps.
Same code exists in both branches.
Notable differences:
Main is the parent branch of DEV
Main has an added permission group to deny certain users from checking in.
My TFS service account is not a member of this group so I don't that applies.
Note: If I change the clone to point to DEV, it doesn't fail.
Can anyone tell me how to solve this mystery? Thanks.
Edit:
I found another difference the working branch has that the Main branch doesn't.
I don't remember adding the Project Build Service to the Dev branch. I also don't know why Main did not have this security setting. After I added the same security credential to Main, builds on Main started working. This raises another question: Does one need to add the Project Build Service to every branch as a second step in order to perform TFS builds?
Usually, the Build service account should be created and added to code repository automatically when the project is created and it will be inherited in every child folders. So the user does not need to add it to other branches/folders manually. For your case, I'm not sure if the user is removed unexpectedly or any other things happen.
Have you set "Items To Build" to correct path?
In Build Definition->Process-Items to build
screenshot from Build Definition
i just updated to Xcode 5 and my project is using GIT, after update completed suddenly question marks appear in project navigator file near each file.
when i am trying to Commit i don't see what files have been changed, i cannot pull also
and when i am trying to push it gives :Push Success" message but the repository on GitHub don't updated.
You probably did not set up your git repository properly. There are ways of adding external git repositories, but they tend not to work well for github (in my experience) and always lead to these sorts of issues.
If you want to set up a remote git repository through github on XCode these are the steps you should take.
Make the repository on github. Make sure to add the .gitignore file for Objective-C.
Clone the repository.
Go to XCode, press "create new project"
Create the project in the folder you cloned the repo to. I always name it the exact same thing, but I don't know if that is necessary.
Make sure not to select create local git repository.
This will definitely create a project that is under version control by a remote git repository hosted on github.
Quick fix is to Create or Save the new project 'outside' the directory (say Desktop) that is not linked to your github/bitbucket
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.
Currently we have a build process as follows:
I do a build into our dev staging environment.
I label this in TFS.
I use SVN bridge to check out that changeset that was labelled.*
If testing for dev staging passes, I use the working copy I checked out to do another build into the next environment.
I don't want to have to use SVN Bridge to have a copy of my code somewhere else for code at a specific version, but I have not found a way to do this natively in TFS (2010).
Is there a way of doing this (point 3 and 4) using TFS, instead of SVN Bridge?
I may be completely misunderstanding what you're trying to do, but it sounds like you need to create a separate workspace, and get the code that was labeled in step 2 into the new workspace.
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:\.