First of all, we are using TFS 2013 update 3, and the whole system worked well before today's issue.
Today, both of our 2 TFS build agents failed to do successful TFS builds anymore.
I checked the build log, and found the build process failed at the very first step, CoreGet, like below
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(895,5,895,5): error : One or more errors occurred while performing a Get operation
What’s interesting is, it’s not failed to get every file, but just failed to get some files;
What’s more interesting is, the fail-to-get-file-list is not fixed.
In my project, there are more than 10,000 files, and every time, 12 of them is failed to be got, but the files in the 12 are randomly picked (at least I did not find any pattern).The error message for any file is like this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(895,5,895,5): error : C:\Builds\6\NameOfMyFile: Server was unable to process request. ---> Object reference not set to an instance of an object
I checked the local path of build agent, and actually all these files are successfully fetched from TFS server and saved to build agent.
Any ideas what happens?
Could you check the free disk space available on the TFS Server? I got a similar error trying to retrieve files from TFS and it turns out that the disk was full. Clearing up some space fixed it.
This is the full error I got from Visual Studio, for reference:
---------------------------
Microsoft Visual Studio
---------------------------
Error Server was unable to process request. ---> Object reference not set to an instance of an object.
Related
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.
When I attempt to build a Docker image from any of my .NET core projects, if the project's solution file is open in Visual Studio 2017, the Docker build process immediately fails when attempting to create the build context:
ERROR: Error processing tar file(exit status 1): unexpected EOF
If I close the solution, the Docker build succeeds. I assume there is some kind of file locking being done by VS 2017 here that is interfering with Docker creating the build context. Is there something I can add to a .dockerignore file to allow the image build to run while the solution file is open?
I did not previously encounter this problem with project.json-style solutions - I only started getting it once I upgraded these solutions to the new .csproj format in 2017.
After some experimentation I noticed this was associated with my "SQL Server" database project (.csproj)
Visual Studio tends to lock certain files which causes issues for the docker build process, it's possible to confirm this by closing visual studio, and then using powershell and running the docker build command manually for your dockerfile.
There also appears to add an extra process before it starts to execute your dockerfile, copying all the project files into a cache first, regardless of if you need those or not, or even if you intentionally specified for those files to be copied directly within your dockerfile script.
Your solution directory (not shown in the visual studio file explorer) should already have the .dockerignore file created automatically, any files that visual studio locks can be safely added into this file, for my example I added the following two lines to get the build working again;
**/*.dbmdl
**/*.jfm
At first glance, the error message listed as a result of this is not easy to interpret, it lists all the files within the solution as having issues, when in reality the first problem it encounters causes a splurge of errors.
It's also worth noting that certain virus checkers may also cause similar errors, and you will need to create exception rules within those programs.
This post helped me solve this error:
error msg="Can't add file \\?\C:\APP\wea. to tar: archive/tar: missed writing 32 bytes.
my docker build process was also hanging because of introducing a large folder 9+gigs -- had to remove this "copy" from the dockerfile.
Next: I had to close visual studio and restart docker desktop.
This solved the issue.
During our incremental builds, where the repository clean parameter is set to 'false'. Build fails intermittently during get source step with the following error: Unable to perform the get operation because the file already exists locally.
Is there a way to resolve the error without setting the repository clean parameter to true?
#Buck Hodges (Director of Engineering at Microsoft) has given the answer in this case:
The file is writable. When there's a writable file, get will not
overwrite it unless the /overwrite option is used. However, you would
need to figure out how the file is becoming writable. You may want to
go back to the default option of creating a new workspace, running a
build with verbose logs, and see what is making the file writable.
Build vnext agent (1.x) does not provide a way to control whether
/overwrite is included. The new agent (2.x) does specify /overwrite
every time in order to prevent writable files causing problems. The
new agent will be the default in TFS "15" and in VS Team Services.
For one of our build definitions (Scheduled, from monday to friday, at 2:00 AM) we receive the following error message every night:
One or more of the steps defined in the build does not have an
associated task definition
Unfortunately no log is written. Manually queuing a new build works most of the time. The error occurs only for builds scheduled during the night.
I found a link:
https://github.com/Microsoft/vsts-tasks/issues/1170
but that link was not very helpful. They mailed to eachother and MS says they solved some caching issues. Not something we could do by our own.
So has someone the same issue and found a solution?
Additional inforamation:
We are using:
Visual Studio 2015 Update 3
Visual Studio TFS 2015
we are using 3 build servers, but before it starts on any of the build servers, it is already crashed.
There is no log wich can be downloaded: see picture ("Download all logs as zip" can't be clicked)
Only message we receive is: "One or more of the steps defined in the build does not have an associated task definition."
Source Version of failed builds is always "T". Source Version of successful builds is a number (int) -> most recent build has highest number.
Update 20160815:
We are using TFS 2015 update 2. Our architect has planned a meeting, to check if we can update to update 3, maybe the caching fixes from MS will do the thrick.
We have TFS 2015u3 with the same issues. We use scheduled builds and all builds (on 2 build agents) are crashing. As suggested in the GitHub thread I disabled SSH in the TFS Console. It works now again.
The source version "T" means the build agent are running tf get /version:T command which will get the latest version of your source code during build process. Please refer to tf get command for details:
Specifies the maximum version, or the minimum and the maximum
versions, to display in the history data. The default is /version:T
(the latest version).
According to your screen shot, the phenomenon looks like the build is not picked up by any agent. Another possibility is the build process hangs when obtaining the latest version.
You can set up a daily scheduled build to observe if there is such a phenomenon, and you can also go to the "_diag" folder in build agent folder and event view to check if there are any related the logs.
For me, this issue was a bug in SSH Service.
The fix was published by MS here:
https://blogs.msdn.microsoft.com/dstfs/2017/01/06/git-clone-ssh-ci-build-issue-in-tfs-2015-3/
I have bizarre thing happening with my TFS 2013 server. The first build fines, but then subsequent builds keep failing with this message. I have to delete the build definition and recreate it and then melodrama repeats. After creating build definition the first build is always successful. Any ideas?
Exception Message: API resource location 225f7195-f9c7-4d14-ab28-a83f7ff77e1f is not registered on http://tfsserver:8081/tfs/mycollection. (type VssResourceNotFoundException)
Exception Stack Trace: at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d__1c.MoveNext()
Make sure to delete cache folder located under the service account that you choose to run Team Foundation Server.
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Team Foundation\5.0\Cache\
I had exactly the same problem, first build worked fine, every subsequent build failed, running TFS 2013 (Update-4). Clearing the cache folder didn't solve the problem. But after upgrading to Update-5, the TFS-build worked again as expected.