Andreas Katzig edited a comment on Bug JENKINS-21785

Thanks for getting back Daniel.

I did what you recommended, but the log doesn't tell me anything interesting:

Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
Attempting auth for URL: svn://svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME

Aug 19, 2014 2:05:19 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
Attempting auth for URL: svn://svnserver:3688/user/xxx/__USER; Realm: <svn://svnserver:3688> REALMNAME

Aug 19, 2014 2:05:20 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
Attempting auth for URL: svn://svnserver:3698/Library/branches/yyy-0.1/Tools/Tool1; Realm: <svn://svnserver:3698> REALMNAME

Aug 19, 2014 2:05:21 PM FINE hudson.scm.CredentialsSVNAuthenticationProviderImpl requestClientAuthentication
Attempting auth for URL: svn://svnserver:3688/xxx/code/trunk; Realm: <svn://svnserver:3688> REALMNAME

The build to which the log above belongs failed again.
I figured out that the build always fails the first time some changes are checked in to SVN (still funny that the next checkout/build will succeed).

To explain our SVN infrastructure a bit:

  • We use initial checkout paths which contain only svn:externals, which are pointing to different source paths and also different repositories (as you can see with the port number).
  • The error "hudson.util.IOException2: revision check failed on ..."always happens on the first external - in case of the above log it's "svn://xxx:3688/zzz/code/trunk".
  • The external property pointing to the same repo is defined like this: "^/zzz/code/trunk localpath"
  • External properties pointing to different repositories are defined like this: "svn://svnserver:3698/remotepath localpath"

Screenshot from the SVN settings within the build job:

What I saw in the SCM logs was that some repositories are trying to connect to the SVN server via IP, which would not work when the realm is defined with the hostname.
This doesn't affect the current build I'm talking about though, or at least not in a way I'm able to comprehend.

Unfortunately the SCM log does not show which build job triggert SVN activity - I set the log level to "finer" (and will try below), maybe I'll find something that helps.

I will also try to replace the circumflex "^" in the external definition with the absolute hostname. Will give feedback if that helped, but I would hate to change that for our 20+ repositories with 5 externals checkout paths each (would > 100 changes)

After checking the next build, which succeeds, I'm also sure that SVN is not trying to connect to the server via IP instead of the hostname.

Any more clues?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to