When checking in some changes to our TFS 2015.4 server, the vNext build agent had an error while in the "Getting Sources" step. The full error is
Some items in shelveset <gated checkin shelveset> were not unshelved because Project Build Service (TEAM FOUNDATION) does not have Read permission for those items.
The problem turned out to be the build authorization scope. I had set it to "Current Project", but there was a file I had branched from another team project's branch into this one, so the authorization scope was not able to include that file's branching.
Changing the scope it to "Project Collection" and re-running the build addressed the problem. I had to do exec the build twice actually as the first time reported...
The working folder D:\agent006\_work\41\s\SomeTrunk is already in use by the workspace ws_41_7;Project Build Service (TEAM FOUNDATION) on computer TFSBUILDSERVER.
Prepare repository failed with exception.
The second and subsequent builds worked properly.
Related
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.
I created a job to get sources from TFS and build the project. Everything worked, until I marked "delete workspace before/after build start/end" in the job. Now I getting "Finished getting version '...'. Retrieved 0 resources". How
to tell Jenkins to re-download the project every time the build starts ?
Configure > Source Code Management > Advanced > Uncheck "Use Update"
The next build should pull everything down again
In my case, this setting was preventing the download after deleting workspace. Seems like it should recognize that the workspace was deleted and start over. I'd consider this a bug in Jenkins.
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
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.
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.