I have a solution checked in to a TFS branch. That solution includes a project located in another TFS branch. Our sys admin creates a build definition so that each time we check code in. An automated build is triggered. The automated build is failing because it doesn’t see the project file of the project located in another branch. What are we doing wrong?
Just as you said, the reason is that "it doesn’t see the project file of the project located in another branch."
During the build, the first step is getting the sources from repository. If missing the needed files for the solution during getting sources, the build will be failed.
In your case, you need to include another branch (which the project located in) in Repository Mappings, means that you need to also get the needed sources from another branch.
Actually, the best way to fix that is adding the project to the solution in the same branch.
Related
I have an existing TFS server (2012) and am transferring a solution from visual source safe. The solution has about 30 projects and compiles fine locally.
I created a build that is triggered manually. In each project I set the property group to match the build configuration.
When I build, only some of the projects make it to the source folder and I get errors for the ones that are missing.
Is there anything else I can check?
In your build definition, go to the Source Settings page. Make sure that the Source Control Folder is set close enough to the root folder to cover all of the projects needed for the build.
I'm trying to deploy a Continuous Integration server where I work.
We used TFVC with the branch to release strategy, but we are having difficulty with something that should be trivial.
We only need the build on the branch that was checked in.
Is it possible to do this without having to change the build definition every time a new branch is created?
I do not want to map the entire folder structure of the repository. Imagine having 10 branches and every check-in, build all? Does not make sense!
Anyone have any idea how to do it?
The CI build for TFVC can’t map and just build target branch like build for Git.
There are some workarounds:
Clone a build definition and change source mapping, Path filters of triggers for each branch.
Add a PowerShell step/task to get recent check-in change by calling get changesets Rest API, then store the related solution/project files in a variable by using Logging Commands, then build these solutions/projects
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
Have a CI build set up in a very simple solution (MVC webapp, Service, MSTest project)
The build shows orange with the following:
Handle MSTest Exception There is no working folder mapping for
/Heartbeat/Source/BvtAutomation/Local.testsettings
Now, here's the kicker, that is not the source branch being built, it is another project altogether! I cannot find any reference to it in the build definition or anywhere in my solution (WinGrep .. the whole nine yards!)
Anyone seen anything similar to this or have a suggestion as to what I might try?
Thanks!
In TFS2010 when building with DefaultTemplate.xaml, the test files to run are not specified relatively to the mapped workspace, but instead by their complete path from Source Control.
So to fix the issue:
Edit your build definition
Go to the Process tab
In the 2. Basic section, select Automated Tests and click the ... button to edit the test settings.
In the Automated Tests dialog, browse for the .testsettings file in the branch you're building.
This may help: select build definition in the Team Explorer, right-click -> Edit build definition. On the 'Workspace' tab you can configure sources to be got to the build machine. HTH
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.