Jenkins-SVN integration bugs and workarounds

Recently I've had to setup Jenkins to build from an https-exposed SVN repo on a Windows slave. I'll describe two gutcha's:


Right off the start, the build fails at checkout:

Unable to access https://mysrv/repo/trunk/ : svn: E175002: OPTIONS /repo/trunk failed 
org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repo/trunk failed
         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
         at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
...
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repo/trunk'
svn: E175002: Received fatal alert: bad_record_mac

...

After some googling, this post provides the basis for the solution.

The part about -Dsvnkit.http.sslProtocols="SSLv3" is correct; however, it is not possible to set this option via the windows service properties. What was in fact needed, was:
edit $JENKINS_HOME/jenkins-slave.xml config file like so:

<executable>C:\Program Files\Java\jre6\bin\java.exe</executable>
<arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://.../slave-agent.jnlp -secret ...fd</arguments>

Should become:

<executable>C:\Program Files\Java\jre6\bin\java.exe</executable>
<arguments>-Xrs -Dsvnkit.http.sslProtocols="SSLv3" -jar "%BASE%\slave.jar" -jnlpUrl http://.../slave-agent.jnlp -secret ...fd</arguments>

 

Note that the -D... comes before the -jar.


Now, this (almost) works, but we are still missing the https svn privileges login + password (which I've entered squarely at the nice but utterly ineffective Jenkins gui https://myjenkins:8080/scm/SubversionSCM/enterCredential):

19:48:52         at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
19:48:52         at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
19:48:52         at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
19:48:52         at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:777)
19:48:52         at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:99)
19:48:52         ... 18 more
19:48:52 Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
19:48:52         at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
19:48:52         at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
19:48:52         at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)

Jenkins svn plugin uses svnkit, which relies on svn credential caching. On a linux slave, to remedy this, one has to perform an svn checkout under the user running Jenkins (usually jenkins). After this, the credentials would be stored in an access-restricted file at the Jenkins user’s home directory  ($JENKINS_HOME). But I’m running this from a Windows slave – things are not as they would appear. The Jenkins service was configured by default to run as the system user, so no matter how many checkout any normal user performs, the data is just not available to the sytem user. In short, this is what was done (credit Gil Shinar):

1)     Login to the machine with an administrator user (we had emea\almtoolsbuild, but one could also just create a jenkins user)

2)     Run svn checkout https://mysrv/repo/trunk/

3)     When the first https certificate request arrives, answer with a "p" (permanant).

4)     When prompted about storing un-encrypted password, answer “yes”   / sorry

5)     Through the windows services window configure the jenkins slave service to run as the user in (1), in our case, emea\almtoolsbuild
 (right click the jenkins service -> properties -> logon tab)

6)     Restart the service so the correct logon will take effect


 

 

Only after all this, the SVN checkout finally worked and Jenkins could go on to do the building. 

 

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com