VSTS Build Fails with SVN Forbidden Exception - azure-devops

Question

I have setup a build process in VSTS that is pulling source code from a public facing SVN url. It works great when I manually queue the build from the dashboard or if I schedule a build to run at a certain time. However, when a build gets queued by continuous integration it throws the following exception:
An exception occurred while polling the repository. Error: Microsoft.TeamFoundation.Build2.Server.Extensions.BuildPollingException: Unable to connect to a repository at URL '<Path to the URL I am referencing>' --->
SharpSvn.SvnRepositoryIOForbiddenException: Unable to connect to a repository at URL '<Path to the URL I am referencing>' --->
SharpSvn.SvnRepositoryIOForbiddenException: Access to '<Path to the trunk of the repository>' forbidden
When I look at the event log on the server that Subversion lives on, it shows that the build agent is trying to access the URL with an anonymous login, hence the exception I am seeing.
Has anyone ran into this before? I know I have configured the service endpoint correctly with user credentials since it works when I manually fire off or schedule queue the build. I've done pretty extensive searching on this topic but have not found much info that involves VSTS and SVN issues. Any guidance or questions will be greatly appreciated.

Answer 1

The CI's Polling Job is executed by the Job Agent on the TFS server. Apparently, your Job Agent is configured to run as NT AUTHORITY\NETWORK SERVICE (i.e., as DOMAIN\TFSSERVER$). On the other hand, it looks like you VisualSVN Enterprise instance is configured to use NTLM. In this case, basic credentials are not used by the SharpSvn library the Polling Job uses to access the repository. Unfortunately, that's SharpSvn restriction. You either should provide the computer account (DOMAIN\TFSSERVER$) with the READ access to the SVN repository in the VisualSVN server configuration (to continue using NTLM), or disable NTLM on the VisualSVN server to switch to Basic authentication.
[Few technical details]The anonymous requests you see in SVN logs are part of the normal HTTP request flow implemented in the SharpSvn library:
The library first submits an anonymous request to the server.
If the server rejects the request, the library inspects the WWW-Authenticate response headers to detect the authentication scheme
requested by the server.
The WWW-Authenticate: NTLM header has a higher priority comparing to WWW-Authenticate: Basic. That's why username and password
specified in the connection endpoint are not used at all.
If only the WWW-Authenticate: Basic header is present in the response, the library uses a callback function provided by the client
To request credential information. At this point username and
the password specified in the connection endpoint is provided to the
library by the Polling Job.
[Note 1] The Polling Job does not download any sources from the SVN repository, it only requests the list of files changed since its last successful execution and decided if it's time to schedule a build.
[Note 2] If the Polling job continuously fails for the same reason, it reports each 100th failure to TFS as a failed build providing a reason of the failure.
Alex

Answer 2

I look to be having a similar issue. Using TFS 2015 Update 3 and VisualSVN Server 3.4.6. I get the same error with CI polling. On the SVN Server I get the following errors every time TFS polls: Access denied: 'TFSSERVER$' OPTIONS : [client ]
Here TFSSERVER$ is the computer name of our TFS Server.
So I gave DOMAIN\TFSSERVER$ Read Only permissions at the root of the repository and then things worked OK. Not happy that I had to do that of course.
Filed this bug about it: SVN CI Polling Uses TFS Machine Account Not SVN Account Set in the Service EndPoint

Answer 3

There isn't any big difference between CI and manual/scheduled build for SVN repository. When you configure it to continuous integration, it just keeps checking the SVN repository by the Polling interval you set and then run the build if there is any new change. The only difference between them is that you need to set "Filters" for CI and base on the access forbidden error message you get, you don't have the permission to read the path. So you need to check if your account has the read permission to the path you set in "Filters".