Subversion Authorization Failed Only for Maven Release Plugin
Hi All,
I'm using TeamCity 7.1.3 on Windows.
I have a weird case where the Maven Release Plugin fails with the error authorization failed:
[org.myself.foo:bar-app] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare
(default-cli) on project bar-app: Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: E170001: Commit failed (details follow):
svn: E170001: Unable to connect to a repository at URL 'http://localhost/SVG/repos/Demos/Foo/trunk'
svn: E170001: OPTIONS of 'http://localhost/SVG/repos/Demos/Foo/trunk': authorization failed: Could not authenticate to server: rejected Basic challenge (http://localhost)
The weird thing: I have two identical build servers - this build works fine on one, but fails on the other.
(Windows 2008 server with SVN 1.7 installed)
The check-out of sources works fine with the same credentials, the build fails trying to tag the code in SVN.
I kept the default SVN connection settings in TeamCity:
URL: http://localhost/SVG/repos/Demos/Foo/trunk
User name: Administrator
Password: *******
Default config directory: Use default config directory
Externals support: Full support (load changes and checkout)
Anyone encountered such a problem?
Is there a way to clean up the SVN cache ib the build agent?
Thanks,
Eyal
Please sign in to leave a comment.
I got it!
The SVN credentials are cached in
C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\Subversion\auth\svn.simple
(on Windows 2008, and using simple authentication)
This folder had a file on the server that works correctly, but the same folder was empty on the server on which the build fails.
I found this post:
http://mszalbach.blogspot.co.uk/2011/02/maven-release-plugin-and-commit_05.html
and added the -Dusername -Dpassword parameters to the Maven command line parameters.
After I executed the build once, the credentials file was created on the server.
Then I removed these parameters, and the build kept working.
I'm still not sure why the SVN credentials were not cached properly on the second build server.
Thanks,
Eyal