I've recently started to encounter a problem with a new build agent that I have added to my TFS agent pool. The agent runs my build the first time without any problem. However, all subsequent builds fail with this error "##[error]The directory is not empty". This occurs on the initial startup of the build when it is trying to download files from TFS.
Keep in mind that I have set the "clean" option to true for the build and also set the Build.Clean variable to "all"
I've done searches online for this error and most of the info I am finding states that the directory is in-use and that is why it cannot be deleted. The strange thing is that I can manually delete the folder using Windows Explorer and there is no error reported of files in-use. Once I do that, the build will work again, but only on the first run. Why is it that the TFS vNext build cannot delete this folder? Is there a log that I reference that provides more details other than "directory is not empty"?
You could set system.debug=true to enable verbose Debug Mode for TFS vNext Build.
In addition, you could also check the agent log under agent path\_diag path here.
If there are more information for troubleshooting.
Back to your issue, please try to stop you build agent service and restart again. Also update your build agent to latest version.
Besides, you could also choose another driver such as D:\ or E:\ if you are using c:\agent\ which may do the trick.
Related
I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
I have been slowly attempting to get the TFS build to work. After some other fixes with other issues, I have gotten to the point where the build will throw the below error. Not exactly sure what to make of the error. I have double checked to make sure the Resources folder is in the solution. However, the file called "resources" is not, but there is a file named "resource". I know this is not much info to go on, however I am stumped at this point.
Suggest you first remote to the build agent machine and check if there are corresponding G3.Resources.resources under path G3.Resources.resources C:\agent\work\1\s
\G3DEV\obj\Debug\G3.Resources.resources
Double confirm the Mapping settings correctly and not cloaked some files.
Try to manually use VS or MSBuild command to build your solution directly on your build agent machine. This will narrow down if your issue is related to TFS build definition side or not.
You could also Enable Verbose Debug Mode for TFS Build vNext by add system.debug=true to get more detail log info for trobuleshooting.
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.
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.