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.
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.
We have been using Sonarqube for about the last 2 months on our TFS 2017 server. Overall it has been very helpful, but a few weeks ago one of our builds started failing due to Sonarqube returning a 401 error (Unauthorised).
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Failed to request and parse 'http://sonarqube.local:9000/api/settings/values?component=MYPROJECTNAME%3Amaster': The remote server returned an error: (401) Unauthorized.
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Could not authorize while connecting to the SonarQube server. Check your credentials and try again.
The curious thing about this is that other builds from other projects are working absolutely fine, using the same API token. I've even created a new Sonarqube endpoint in the failing project, then again in a known good project - again using the same API key on both - only for the same thing to happen. One fails with the above error, the other is fine.
I thought this might have been a security/permission option within sonarqube itself, so I tried creating a completely new sonarqube project but again - one TFS project fails, while another succeeds when both are pointing to this new project.
I suspect this issue stems from the TFS project's security settings, but after comparing a good project with the bad project, nothing is jumping out at me as to what the cause may be - they seem to be set up the same. I enabled debugging on both a good build and the bad build and compared the outputs. As far as I can tell, the only real difference between the two is that the "Failing" build is picking up a sonar.password from somewhere whereas the good build is not:
Good:
2017-10-12T15:13:07.1067146Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]
2017-10-12T15:13:07.2785974Z ##[debug] arguments = /c ""Y:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe" begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.7" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master""
Bad:
2017-10-12T15:11:19.5733714Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]********
2017-10-12T15:11:19.5733714Z ##[debug] Path: Z:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe
2017-10-12T15:11:19.5733714Z ##[debug] Arguments: begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.3" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.password=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master"
(Note: Although the good/bad ran on different build agents in this instance, the agents are identical and I've confirmed that "good" projects work on all of our agents while the "bad" project fails with the same result on all agents).
However, I have no idea where it's getting this password from - there is no sonar.properties file in the repository. To be absolutely sure, I cloned the repository for the failing TFS project, pushed it into a repository in a working TFS project, replicated the build and it works.
I've checked the logs from Sonarqube itself and they are less than helpful
What could I have missed?
TFS 2017 is 15.117.26714.0
Sonarqube is 6.5.0.27846
Sonarqube task version is 3.0.2
EDIT: I have managed to get a temporary workaround for this by editing the build task to NOT insert sonar.password into the command line and this works. That does prove that the root issue is the task pulling this mystery password from "somewhere" but I'm still at a loss as to where it would be picking it up. I cannot find much information on what sets MSBuild.SonarQube.ServerPassword
Based on the (401) Unauthorized. Generally speaking you need to specify the authentication token in the SonarQube service endpoint in TFS: click! To obtain a user token in SonarQube follow these steps However, according to the troubleshooting you have done and one project worked, another not work, this should not related to your issue.
Just be sure the sonar.login and sonar.password properties in SonarQube.Analysis.xml are commented out, otherwise the token won't be used.
Also suggest you to compare the build definition of good build and bad build. Another way is creating a new build definition only with sonar qube related task for the bad project. To see if the authentication works, this will narrow down if the issue related to build definition.
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/
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.
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.