SVN Authentication fails on slave node after upgrade to jenkins

[Daniel Carter]

Hello,

I have a problem after upgrading from hudson 1379 to jenkins 1404,
where all builds on a slave node will start failing.

I've tried upgrading the SVN plugin from 1.20 to the latest 1.24 but
all to no avail.

Inspecting ~/.subversion/auth/svn.simple/ it appears hudson has
rewritten the auth file and removed the password credentials. The
builds start failing after this file gets written to.

Copying the credentials file over from the master fixes this, but then
the next day it will happen again.

There's a related issue about hudson rewriting the credentials
http://issues.jenkins-ci.org/browse/JENKINS-8059,
But in my case i'm not worried about it breaking commandline svn,
rather this is preventing hudson itself doing checkouts.

How should i be configuring authentication? This seems to be
something of a black art with no information either on the plugin wiki
or the inline help.

Regards,
Dan.


Building remotely on myserver
Updating http://myrepo
ERROR: Failed to update http://myrepo
org.tmatesoft.svn.core.SVNCancelException: svn: OPTIONS /SVF/myrepo
failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
287)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
276)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
264)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:
516)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:
98)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:
1001)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:
146)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:
342)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:
330)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:
535)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:
401)
at hudson.scm.subversion.UpdateUpdater
$TaskImpl.perform(UpdateUpdater.java:129)
at hudson.scm.subversion.WorkspaceUpdater
$UpdateTask.delegateTo(WorkspaceUpdater.java:135)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:
725)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:
706)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:
690)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1944)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn:
authentication cancelled
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:
37)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:
32)
at
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:
257)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:
566)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
285)
... 25 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: authentication
cancelled
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
200)

[Matthew...@diamond.ac.uk]

JENKINS-8059 is a major problem for us also. The only way to avoid it that I have found is to roll the Subversion plugin back to version 1.17. There was a change in the way Jenkins does subversion authentication in 1.18, and there are some issues with the new method (!).

If this bug is a problem for you, can I suggest that you (a) vote for it on the Jenkins Jira, and (b) on the Jenkins changelog (http://jenkins-ci.org/changelog) community ratings, indicate that you needed to roll back the latest release because of this bug.

Matthew

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[Daniel Carter]

It's happened about 5 times today... very annoying.

Does anyone have slave nodes working with subversion, i would have
thought it was a very common combination?

I'm going to try write protecting the subversion auth file, and if
that doesn't work i'll try rolling back the subversion plugin to
1.17. What i'm confused about is that JENKINS-8059 is about it
breaking command-line scripts that invoke svn. For me it's stopping
hudson itself from checking out. Surely if 1.18 doesn't work at all
on slave nodes the release would have been pulled, so there must be
some unusual factor at work here.

Regards,
Dan.

[Vincent Hardion]

Hi,

Since the last update of Jenkins (1.398 -> 1.404) and subversion plugin,
the configuration of http proxy (~/.subversion/servers) had been
completely replaced by the default one.

Do you see that before ?

Regards,

Vincent

[Dirk Haun]

On Fri, Apr 1, 2011 at 3:14 PM, Daniel Carter <danthe...@gmail.com> wrote:
>
> Does anyone have slave nodes working with subversion, i would have
> thought it was a very common combination?

We actually switched our slaves over to using svn+ssh recently since
we were seeing the same thing happen. Didn't make the connection with
Jenkins, though. We thought it had to do with another SVN setup change
that we had to make recently (for other reasons, unrelated to
Jenkins).

So, if you don't want to roll back, using the svn+ssh protocol may be
an alternative.

[Daniel Carter]

Hello,

The subversion repository is on the local network, so it shouldn't be
http proxy related, i've never had to configure one.

Thanks,
Dan.

On Apr 1, 2:34 pm, Vincent Hardion <vincent.hard...@synchrotron-

[Daniel Carter]

Does anyone know what this undocumented URL that allows one to enter
subversion credentials is for?

http://myhost:myport/scm/SubversionSCM/enterCredential

Should we be using this instead of the svn commandline client for
setting up authentication?

On Apr 1, 12:03 pm, Daniel Carter <dantheper...@gmail.com> wrote:
> Hello,
>
> I have a problem after upgrading from hudson 1379 to jenkins 1404,
> where all builds on a slave node will start failing.
>
> I've tried upgrading the SVN plugin from 1.20 to the latest 1.24 but
> all to no avail.
>
> Inspecting ~/.subversion/auth/svn.simple/ it appears hudson has
> rewritten the auth file and removed the password credentials. The
> builds start failing after this file gets written to.
>
> Copying the credentials file over from the master fixes this, but then
> the next day it will happen again.
>

> There's a related issue about hudson rewriting the credentialshttp://issues.jenkins-ci.org/browse/JENKINS-8059,

> But in my case i'm not worried about it breaking commandline svn,
> rather this is preventing hudson itself doing checkouts.
>
> How should i be configuring authentication?  This seems to be
> something of a black art with no information either on the plugin wiki
> or the inline help.
>
> Regards,
> Dan.
>
> Building remotely on myserver
> Updatinghttp://myrepo

> ERROR: Failed to updatehttp://myrepo

[Matthew...@diamond.ac.uk]

There are two places in Jenkins where subversion credentials seem to be stored. $JENKINS_HOME/ hudson.scm.SubversionSCM.xml and $JENKINS_HOME/jobs/<jobname>/svn.credentials

I think that the URL you refer to adds to the first of those. Anyhow, I've tried all that, and the ~/.subversion/auth stuff still gets overwritten sometimes.

This stuff is seriously broken at the moment, at least for some users. Well, I guess it's open source, so enjoy!

> -----Original Message-----
> From: jenkins...@googlegroups.com [mailto:jenkinsci-
> us...@googlegroups.com] On Behalf Of Daniel Carter
> Sent: 01 April 2011 15:22
> To: Jenkins Users
> Subject: Re: SVN Authentication fails on slave node after upgrade to
> jenkins
>

> Does anyone know what this undocumented URL that allows one to enter
> subversion credentials is for?
>
> http://myhost:myport/scm/SubversionSCM/enterCredential
>
> Should we be using this instead of the svn commandline client for
> setting up authentication?
>

--

[Frédéric Camblor]

Hi Daniel,

You're right, you should use http://myhost:myport/scm/SubversionSCM/enterCredential to enter your svn credentials and store it in your HUDSON_HOME/hudson.scm.SubversionSCM.xml

While developping scm sync configuration plugin, I noticed subversion plugin is :

- Trying to checkout from svn using HUDSON_HOME/hudson.scm.SubversionSCM.xml

- If it doesn't work, it tries using your ~/.subversion/auth/ content

Drawback of the second one is your should authenticate on your slaves.

PS: beware : if you're using maven release plugin with svnexe scm provider : you will have to provide your svn credentials while releasing. Otherwise, use svnjava scm provider ;)

Frédéric

2011/4/1 Daniel Carter <danthe...@gmail.com>

--
Frédéric Camblor

[Matthew...@diamond.ac.uk]

Unfortunately, entering your credentials into hudson.scm.SubversionSCM.xml does not avoid the JENKINS-8059 problem. Jenkins still overwrites your ~/.subversion/auth/ with the result that using svn from the command line then fails.

 

From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Frédéric Camblor
Sent: 01 April 2011 15:34
To: jenkins...@googlegroups.com
Subject: Re: SVN Authentication fails on slave node after upgrade to jenkins

 

Hi Daniel,

 

You're right, you should use http://myhost:myport/scm/SubversionSCM/enterCredential to enter your svn credentials and store it in your HUDSON_HOME/hudson.scm.SubversionSCM.xml

 

While developping scm sync configuration plugin, I noticed subversion plugin is :

- Trying to checkout from svn using HUDSON_HOME/hudson.scm.SubversionSCM.xml

- If it doesn't work, it tries using your ~/.subversion/auth/ content

 

Drawback of the second one is your should authenticate on your slaves.

 

PS: beware : if you're using maven release plugin with svnexe scm provider : you will have to provide your svn credentials while releasing. Otherwise, use svnjava scm provider ;)

 

Frédéric

2011/4/1 Daniel Carter <danthe...@gmail.com>

Does anyone know what this undocumented URL that allows one to enter
subversion credentials is for?

http://myhost:myport/scm/SubversionSCM/enterCredential

Should we be using this instead of the svn commandline client for
setting up authentication?

 

-- 

[Frédéric Camblor]

Aren't you using some jobs using svn CLI without the --no-auth-cache parameter ?

I faced same problem recently, and I found a job launching an ant script with "svn --username foo --password bar checkout http://xxxxx"

It was bad :-)

2011/4/1 <Matthew...@diamond.ac.uk>

--
Frédéric Camblor

[Daniel Carter]

Ok, so i see how the problem is being masked now:

HUDSON_HOME/hudson.scm.SubversionSCM.xml no doubt has an out of date
password in it. This is never noticed on the GUI because on the master
node it is silently falling back to using ~/.subversion/auth/ and
that is always correct as on the master there is allot of manual and
automated commandline svn checkouts going on.

On the slave it's uses ~/.subversion/auth, but there is some bug
introduced after hudson v1379 that causes svn plugin >1.17 on a slave
to randomly delete the credentials in ~/.subversion/auth

On Apr 1, 3:33 pm, Frédéric Camblor <fcamb...@gmail.com> wrote:
> Hi Daniel,
>

> You're right, you should usehttp://myhost:myport/scm/SubversionSCM/enterCredential

> to enter your svn credentials and store it in your HUDSON_HOME/
> hudson.scm.SubversionSCM.xml
>
> While developping scm sync configuration plugin, I noticed subversion plugin
> is :
> - Trying to checkout from svn using HUDSON_HOME/hudson.scm.SubversionSCM.xml
> - If it doesn't work, it tries using your ~/.subversion/auth/ content
>
> Drawback of the second one is your should authenticate on your slaves.
>
> PS: beware : if you're using maven release plugin with svnexe scm provider :
> you will have to provide your svn credentials while releasing. Otherwise,
> use svnjava scm provider ;)
>
> Frédéric
>

> 2011/4/1 Daniel Carter <dantheper...@gmail.com>

[Daniel Carter]

I've narrowed down the cause a little after making ~/.subversion/auth/
svn.simple/* read only on the slave.

Seeing totally bizarre behavior, jenkins is storing some hidden state
somewhere...

Most jobs ran happily.
One particular job failed with permission denied (see below) on the
auth file while processing a particular subdirectory. So it must be
that job that was overwriting the credentials.
I've no idea why it is doing that, i've wiped out the workspace many
times to no avail.
I've created a new job by cloning the original, that that new job is
running fine.
I've deleted the original job, restarted hudson, cloned the cloned job
and given the second clone the original name, and now it fails again
with the same error on the same subdirectory, totally bizare!!
I've cloned that again and given it a 3rd name, that job is running
fine. So hudson is storing something against the original job name,
but outside of the job directory?

That error is:

16:51:09 Started by user anonymous
16:51:09 Building remotely on myslave
16:51:09 Updating http://myserver/myrepo/trunk
16:51:12 ERROR: Failed to update http://myserver/myrepo/trunk
16:51:12 org.tmatesoft.svn.core.SVNException: svn: REPORT /SVF/repos/
myrepo/!svn/vcc/default failed
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
291)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
276)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
264)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:
266)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:
1263)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:
820)
16:51:12 at
org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:
564)
16:51:12 at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:
401)
16:51:12 at hudson.scm.subversion.UpdateUpdater
$TaskImpl.perform(UpdateUpdater.java:129)
16:51:12 at hudson.scm.subversion.WorkspaceUpdater
$UpdateTask.delegateTo(WorkspaceUpdater.java:135)
16:51:12 at hudson.scm.SubversionSCM
$CheckOutTask.perform(SubversionSCM.java:725)
16:51:12 at hudson.scm.SubversionSCM
$CheckOutTask.invoke(SubversionSCM.java:706)
16:51:12 at hudson.scm.SubversionSCM
$CheckOutTask.invoke(SubversionSCM.java:690)
16:51:12 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:
1944)
16:51:12 at hudson.remoting.UserRequest.perform(UserRequest.java:
118)
16:51:12 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
16:51:12 at hudson.remoting.Request$2.run(Request.java:270)
16:51:12 at java.util.concurrent.Executors
$RunnableAdapter.call(Executors.java:441)
16:51:12 at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:303)
16:51:12 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
16:51:12 at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
16:51:12 at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
16:51:12 at java.lang.Thread.run(Thread.java:619)
16:51:12 Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn:
REPORT /SVF/repos/myrepo/!svn/vcc/default failed
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
200)
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
146)
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
16:51:12 ... 23 more
16:51:12 Caused by: org.tmatesoft.svn.core.SVNException: svn: REPORT
request failed on '/SVF/repos/myrepo/!svn/vcc/default'
16:51:12 svn: OPTIONS /SVF/repos/myrepo/trunk/some/sub/directory
failed
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:
64)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:
51)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:
644)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
285)
16:51:12 ... 22 more
16:51:12 Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn:
REPORT request failed on '/SVF/repos/myrepo/!svn/vcc/default'
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
200)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:
642)
16:51:12 ... 23 more
16:51:12 Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn:
OPTIONS /SVF/repos/myrepo/trunk/some/sub/directory/ failed
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
200)
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
146)
16:51:12 at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
291)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
276)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:
264)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:
516)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:
98)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:
1001)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getFile(DAVRepository.java:
265)
16:51:12 at org.tmatesoft.svn.core.wc.SVNUpdateClient
$1.fetchFile(SVNUpdateClient.java:554)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addFileWithHistory(SVNUpdateEditor.java:
1532)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addFile(SVNUpdateEditor.java:
1462)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addFile(SVNUpdateEditor.java:
1134)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNAmbientDepthFilterEditor.addFile(SVNAmbientDepthFilterEditor.java:
103)
16:51:12 at
org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addFile(SVNCancellableEditor.java:
107)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:
398)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:
85)
16:51:12 at
org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
16:51:12 at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
16:51:12 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
$FragmentContentDispatcher.dispatch(Unknown Source)
16:51:12 at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
16:51:12 at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
16:51:12 at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
16:51:12 at org.apache.xerces.parsers.XMLParser.parse(Unknown
Source)
16:51:12 at
org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
16:51:12 at org.apache.xerces.jaxp.SAXParserImpl
$JAXPSAXParser.parse(Unknown Source)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:
754)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:
719)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:
216)
16:51:12 at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:
364)
16:51:12 ... 23 more

[Mick]

I have noticed that turning off the 'Use update' option in the Source
Code Management section has helped the reliability of my builds.
Jenkins ver. 1.399 with Subversion plugin 1.20
BTW
I downloaded svn plugin 1.17 file http://mirrors.jenkins-ci.org/plugins/subversion/1.17/subversion.hpi
loaded into hudson and after restart, hudson reports in pluginManager/
installed that the plugin is version 1.20 and MANIFEST.MF in plugins/
subversion/META-INF also shows
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: kohsuke
Build-Jdk: 1.6.0_20
Extension-Name: subversion
Implementation-Title: subversion
Implementation-Version: 1.20
Group-Id: org.jvnet.hudson.plugins
Short-Name: subversion
Long-Name: Hudson Subversion Plug-in
Url: http://wiki.hudson-ci.org/display/HUDSON/Subversion+Plugin
Plugin-Version: 1.20
Hudson-Version: 1.375
Plugin-Developers: Many:kohsuke abayer dodok1 dty huybrechts mindless
pgweiss stephenconnolly etc:

Also tried the hudson download, it is the same.

Mick

On Apr 1, 5:01 pm, Daniel Carter <dantheper...@gmail.com> wrote:
> I've narrowed down the cause a little after making ~/.subversion/auth/svn.simple/* read only on the slave.

>
> Seeing totally bizarre behavior, jenkins is storing some hidden state
> somewhere...
>
> Most jobs ran happily.
> One particular job failed with permission denied (see below) on the
> auth file while processing a particular subdirectory. So it must be
> that job that was overwriting the credentials.
> I've no idea why it is doing that, i've wiped out the workspace many
> times to no avail.
> I've created a new job by cloning the original, that that new job is
> running fine.
> I've deleted the original job, restarted hudson, cloned the cloned job
> and given the second clone the original name, and now it fails again
> with the same error on the same subdirectory, totally bizare!!
> I've cloned that again and given it a 3rd name, that job is running
> fine.  So hudson is storing something against the original job name,
> but outside of the job directory?
>
> That error is:
>
> 16:51:09  Started by user anonymous
> 16:51:09  Building remotely on myslave

> 16:51:09  Updatinghttp://myserver/myrepo/trunk
> 16:51:12  ERROR: Failed to updatehttp://myserver/myrepo/trunk

> 644)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn ection.java:

> 285)
> 16:51:12        ... 22 more
> 16:51:12  Caused by: org.tmatesoft.svn.core.SVNErrorMessage:svn:
> REPORT request failed on '/SVF/repos/myrepo/!svn/vcc/default'
> 16:51:12        at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
> 200)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPCon nection.java:
> 642)
> 16:51:12        ... 23 more
> 16:51:12  Caused by: org.tmatesoft.svn.core.SVNErrorMessage:svn:
> OPTIONS /SVF/repos/myrepo/trunk/some/sub/directory/ failed
> 16:51:12        at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
> 200)
> 16:51:12        at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:
> 146)
> 16:51:12        at
> org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn ection.java:

> 291)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn ection.java:
> 276)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConn ection.java:
> 264)
> 16:51:12        at

> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(D AVConnection.java:

> 216)
> 16:51:12        at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPCon nection.java:

> 364)
> 16:51:12        ... 23 more
>
> On Apr 1, 2:14 pm, Daniel Carter <dantheper...@gmail.com> wrote:
>
>
>
>
>
>
>
> > It's happened about 5 times today... very annoying.
>
> > Does anyone have slave nodes working with subversion, i would have
> > thought it was a very common combination?
>
> > I'm going to try write protecting the subversion auth file, and if
> > that doesn't work i'll try rolling back the subversion plugin to
> > 1.17.  What i'm confused about is that JENKINS-8059 is about it

> > breaking command-line scripts that invokesvn.  For me it's stopping

> > hudson itself from checking out.  Surely if 1.18 doesn't work at all
> > on slave nodes the release would have been pulled, so there must be
> > some unusual factor at work here.
>
> > Regards,
> > Dan.
>
> > On Apr 1, 1:04 pm, <Matthew.Web...@Diamond.ac.uk> wrote:
>
> > > JENKINS-8059 is a major problem for us also. The only way to avoid it that I have found is to roll the Subversion plugin back to version 1.17. There was a change in the way Jenkins does subversion authentication in 1.18, and there are some issues with the new method (!).
>
> > > If this bug is a problem for you, can I suggest that you (a) vote for it on the Jenkins Jira, and (b) on the Jenkins changelog (http://jenkins-ci.org/changelog) community ratings, indicate that you needed to roll back the latest release because of this bug.
>
> > > Matthew
>
> > > > -----Original Message-----
> > > > From: jenkins...@googlegroups.com [mailto:jenkinsci-
> > > > us...@googlegroups.com] On Behalf Of Daniel Carter
> > > > Sent: 01 April 2011 12:03
> > > > To: Jenkins Users
> > > > Subject:SVNAuthentication fails on slave node after upgrade to
> > > > jenkins
>
> > > > Hello,
>
> > > > I have a problem after upgrading from hudson 1379 to jenkins 1404,
> > > > where all builds on a slave node will start failing.
>

> > > > I've tried upgrading theSVNplugin from 1.20 to the latest
>
> ...
>
> read more »

[Daniel Carter]

It failed for the same reason but on another job over the weekend,
would update 5 files, then fail to create an auth file for one
particular subdirectory.
Then next time it polled SCM it would do the same... 3000 build
failure emails on monday morning... the upgrade hasn't been too
popular with the workmates. I've one more thing to try and then i'll
have to downgrade from jenkins to hudson.

On Apr 1, 5:01 pm, Daniel Carter <dantheper...@gmail.com> wrote:
> I've narrowed down the cause a little after making ~/.subversion/auth/
> svn.simple/* read only on the slave.
>
> Seeing totally bizarre behavior, jenkins is storing some hidden state
> somewhere...
>
> Most jobs ran happily.
> One particular job failed with permission denied (see below) on the
> auth file while processing a particular subdirectory. So it must be
> that job that was overwriting the credentials.
> I've no idea why it is doing that, i've wiped out the workspace many
> times to no avail.
> I've created a new job by cloning the original, that that new job is
> running fine.
> I've deleted the original job, restarted hudson, cloned the cloned job
> and given the second clone the original name, and now it fails again
> with the same error on the same subdirectory, totally bizare!!
> I've cloned that again and given it a 3rd name, that job is running
> fine.  So hudson is storing something against the original job name,
> but outside of the job directory?
>
> That error is:
>
> 16:51:09  Started by user anonymous
> 16:51:09  Building remotely on myslave

> 16:51:09  Updatinghttp://myserver/myrepo/trunk
> 16:51:12  ERROR: Failed to updatehttp://myserver/myrepo/trunk

> ...
>
> read more »

[Matthew...@diamond.ac.uk]

> I've one more thing to try and then i'll
> have to downgrade from jenkins to hudson.

The bug is probably present in Hudson as well. It was introduced in version 1.18 of the Subversion plugin, which was released before the Hudson/Jenkins split. If you do find that it's been fixed in Hudson, please let this know.

It is probably sufficient to downgrade the Subversion plugin in Jenkins to 1.17. That's not a long-term solution, obviously.

Please continue to post what you find (and add to the Jira ticket as appropriate). This bug is causing us grief also.

[Matthew...@diamond.ac.uk]

I am running a monitor to alert me as soon as somebody (Jenkins) rewrites the credentials in ~/.subversion/auth/svn.simple, and at this point it looks like this happens during the subversion update at the start of a job. I'm still waiting on more cases to see if that is always the pattern, but it is consistent with what you observe.

For folks who are following this thread, please remember to add any relevant information to the https://issues.jenkins-ci.org/browse/JENKINS-8059 as well. You can also watch or vote for this issue.

> -----Original Message-----
> From: jenkins...@googlegroups.com [mailto:jenkinsci-

> us...@googlegroups.com] On Behalf Of Mick
> Sent: 02 April 2011 10:49
> To: Jenkins Users

> Subject: Re: SVN Authentication fails on slave node after upgrade to
> jenkins
>

> I have noticed that turning off the 'Use update' option in the Source
> Code Management section has helped the reliability of my builds.

--

[Frédéric Camblor]

Maybe some important information would be to trace which plugins (and which versions) are installed on your jenkins instance :-)

If I take the scm-sync-configuration plugin example, I can tell I do some black magic with jenkins credentials (not at the job startup though :)) => maybe there are some plugin around there which are acting the same ;)

Frédéric

2011/4/4 <Matthew...@diamond.ac.uk>

--
Frédéric Camblor

[Matthew...@diamond.ac.uk]

Reading the ticket history, I don’t get the impression that more information is required. There’s even a suggested patch there, and the bug is almost certainly related to the major changes in the subversion plugin that were made in version 1.18 of the plugin. What we’re actually waiting for is one of the Jenkins core developers to take a look at this, and decide what needs to be done.

 

Jenkins is in many ways an excellent product, it’s free and open source, so I guess I can’t complain too much, but it IS frustrating that this problem, which is a blocker for a number of users, has been around for so long.

 

From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Frédéric Camblor
Sent: 04 April 2011 15:33
To: jenkins...@googlegroups.com
Subject: Re: SVN Authentication fails on slave node after upgrade to jenkins

 

Maybe some important information would be to trace which plugins (and which versions) are installed on your jenkins instance :-)

 

If I take the scm-sync-configuration plugin example, I can tell I do some black magic with jenkins credentials (not at the job startup though :)) => maybe there are some plugin around there which are acting the same ;)

 

Frédéric

2011/4/4 <Matthew...@diamond.ac.uk>

I am running a monitor to alert me as soon as somebody (Jenkins) rewrites the credentials in ~/.subversion/auth/svn.simple, and at this point it looks like this happens during the subversion update at the start of a job. I'm still waiting on more cases to see if that is always the pattern, but it is consistent with what you observe.

For folks who are following this thread, please remember to add any relevant information to the https://issues.jenkins-ci.org/browse/JENKINS-8059 as well. You can also watch or vote for this issue.

 

-- 

[Daniel Carter]

On Apr 4, 9:43 am, <Matthew.Web...@Diamond.ac.uk> wrote:
> > I've one more thing to try and then i'll
> > have to downgrade from jenkins to hudson.
>
> The bug is probably present in Hudson as well. It was introduced in version 1.18 of the Subversion plugin,

To be clear i wasn't planning on cross grading to the latest oracle
hudson, as you say that probably has the same bug, but rather
downgrading to hudson 1379 from which i upgraded.

I'm not convinced it's soley due to the subversion > 1.18. I was
running hudson 1379 with svn plugin 1.20 and the slave ran fine. It
was upgrading hudson 1379 to jenkin 1404 that broke builds on the
slave for me.

I've now updated the password in ~/.hudson/
hudson.scm.SubversionSCM.xml ( via the secret URL /scm/SubversionSCM/
enterCredential ) and deleted the .subversion directory, and i've had
now slave authentication errors for >24 hours which is good news.
Jenkins is not writing anything to the .subversion/auth directory.

You might like to give that a try, though note im my case i am not
running any build scripts that invoke commandline svn, it was the
jenkins svn updates themselves that would fail after jenkins rewrote
the auth file. So in my case there is no .subversion/auth directory
on the slaves now. Maybe if it's created by commandline svn then
jenkins will start re-writing it?

As an aside it would be useful, when configuring a job, if hudson
warned you that the svn credentials it has stored failed to
authenticate and it is falling back to the commandline auth files, and
thus any builds on slaves will fail.

Regards,
Dan.

[Daniel Carter]

On Apr 5, 1:28 pm, Daniel Carter <dantheper...@gmail.com> wrote:
>, and i've had
> now slave authentication errors for >24 hours which is good news.

Of course i meant NO authentication errors there...