[JIRA] [subversion-plugin] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials

5 views
Skip to first unread message

nick.brown@trendcontrols.com (JIRA)

unread,
Jun 5, 2015, 5:40:14 AM6/5/15
to jenkinsc...@googlegroups.com
Nick Brown commented on Bug JENKINS-21785
 
Re: Check for changes in folders linked via svn:externals fails due to missing credentials

Added additional credentials and now have polling without errors however has a strange side effect. I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas?

Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling errors and results in the job triggered every cycle. Last time I tried if I use job parameters rather than variables defined as I mentioned they do work...

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

nick.brown@trendcontrols.com (JIRA)

unread,
Jun 5, 2015, 6:06:15 AM6/5/15
to jenkinsc...@googlegroups.com
Nick Brown edited a comment on Bug JENKINS-21785
Added additional credentials and now have polling without errors however has a strange side effect. I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas?

Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling  errors  fails  and results in the job triggered every cycle. Last time I tried if I use job parameters rather than variables defined as I mentioned they do work...

nick.brown@trendcontrols.com (JIRA)

unread,
Jun 5, 2015, 6:06:15 AM6/5/15
to jenkinsc...@googlegroups.com
Nick Brown edited a comment on Bug JENKINS-21785
Added additional credentials and now have polling without errors however has a strange side effect. I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas?

Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling fails and results in the job triggered every cycle. Last time I tried ,  if I use job parameters rather than variables defined as I mentioned they do work...

nick.brown@trendcontrols.com (JIRA)

unread,
Jun 5, 2015, 6:08:43 AM6/5/15
to jenkinsc...@googlegroups.com
Nick Brown edited a comment on Bug JENKINS-21785
Added Updated to latest of everything yesterday (Jenkins 1.616 and SVN 2.5), added  additional credentials and now have polling without errors  however has . However I have  a strange side effect  when using relative external paths and polling a branch .  

 I have a job that works fine on trunk including with externals but when I replicate that job and tweak the URLs to a branch the external polling still reports it is comparing the revisions from trunk even though the externals are defined with relative paths '../../../etc.' When the job runs it of course does the correct thing getting the relative externals from the branch but the polling log shows it is looking at them in trunk. Any ideas?

Also I still can't use 'Prepare an environment for the run' to define 'Properties Content' variables that can then be used in the module URLs for polling. They do work fine when the job runs but polling fails and results in the job triggered every cycle. Last time I tried, if I use job parameters rather than variables defined as I mentioned they do work...

recena@gmail.com (JIRA)

unread,
Aug 10, 2015, 3:23:05 AM8/10/15
to jenkinsc...@googlegroups.com

Nick Brown, if you are using EnvInject Plugin + Subversion Plugin and you have problems with polling, please take a look to this issue JENKINS-29340.

dan.russell@smartstream-stp.com (JIRA)

unread,
Sep 25, 2015, 6:47:04 AM9/25/15
to jenkinsc...@googlegroups.com

Seems a pretty clunky fix to have to put credentials in for each job that requires externals, shouldn't the plugin at least try the given credentials before failing?

dan.russell@smartstream-stp.com (JIRA)

unread,
Sep 25, 2015, 6:48:03 AM9/25/15
to jenkinsc...@googlegroups.com
dan russell edited a comment on Bug JENKINS-21785
Seems a pretty clunky fix to have to put credentials in for each job that requires externals, shouldn't the plugin at least try the given credentials before failing?


Also does anybody know why this is only an intermittent failure?

recena@gmail.com (JIRA)

unread,
Sep 25, 2015, 7:03:03 AM9/25/15
to jenkinsc...@googlegroups.com

dan russell

If you have ideas to improve this, it would be helpful if you send an email (dev mailing list) with your proposal.

nick.brown@trendcontrols.com (JIRA)

unread,
Nov 10, 2015, 6:42:04 PM11/10/15
to jenkinsc...@googlegroups.com

Manuel, I looked at the linked item and I am using the 'Properties Content' section already yet still for externals I am getting the error despite configuring the extra credentials as required. Any help to resolve this polling glitch would be appreciated

nick.brown@trendcontrols.com (JIRA)

unread,
Nov 10, 2015, 7:18:03 PM11/10/15
to jenkinsc...@googlegroups.com
Nick Brown edited a comment on Bug JENKINS-21785
Manuel, I  looked at the linked item and I am using the 'Properties Content' section already yet still for externals I am getting the  apologise, my realm string had an  error  despite configuring the extra  and it is in fact working fine with additional  credentials  as required .  Any help to resolve this polling glitch would be appreciated

recena@gmail.com (JIRA)

unread,
Nov 11, 2015, 4:16:06 AM11/11/15
to jenkinsc...@googlegroups.com

recena@gmail.com (JIRA)

unread,
Nov 11, 2015, 4:17:09 AM11/11/15
to jenkinsc...@googlegroups.com

recena@gmail.com (JIRA)

unread,
Nov 11, 2015, 4:17:10 AM11/11/15
to jenkinsc...@googlegroups.com

john.v.little@gmail.com (JIRA)

unread,
Dec 10, 2015, 10:08:06 AM12/10/15
to jenkinsc...@googlegroups.com

in 15 years of using SVN, I have never had to use the realm, nor even known it existed. We have not found a way to get this yet. We are using assembla.com, and have raised a ticket with them to ask them to check their svnserve.conf files, as obviously we dont have access to this. It would a lot of someone could include some real exmaples of what these realms can be, and the entire string which must be pasted into the "Realm" box of the "additional credentials".

dbeck@cloudbees.com (JIRA)

unread,
Dec 10, 2015, 10:32:03 AM12/10/15
to jenkinsc...@googlegroups.com

We have not found a way to get this yet.

john little What about the dozens and dozens of comments on this issue explaining exactly this? Or the actual issue description that contains one possible way to determine the realm name directly below the giant red test?

recena@gmail.com (JIRA)

unread,
Dec 10, 2015, 10:43:02 AM12/10/15
to jenkinsc...@googlegroups.com

Daniel Beck, I've decided don't add more comment here. There is enough information about this.

john.v.little@gmail.com (JIRA)

unread,
Dec 10, 2015, 11:03:06 AM12/10/15
to jenkinsc...@googlegroups.com

For us, svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo does not return any realm info. It returns:

Path: ourproject
URL: https://subversion.assembla.com/svn/ourrepo
Relative URL: ^/
Repository Root: https://subversion.assembla.com/svn/ourrepo
Repository UUID: 26850efa-2baa-4381-9140-fb0xxxxxxxxx
Revision: 1755
Node Kind: directory
Last Changed Author: me
Last Changed Rev: 1755
Last Changed Date: 2015-12-10 15:23:10 +0100 (Thu, 10 Dec 2015)

john.v.little@gmail.com (JIRA)

unread,
Dec 10, 2015, 11:14:05 AM12/10/15
to jenkinsc...@googlegroups.com

I just realized that jira "hid" 155 comments. I just read them all. we were seeing the following:

<https://subversion.assembla.com:443> Assembla Restricted

Several times, but assumed that the realm could not possible be " Assembla Restricted" as it has spaces in it. We have tried the following under realms:

"<https://subversion.assembla.com:443> Assembla Restricted"

"<https://subversion.assembla.com:443>"

"Assembla Restricted"

and "https://subversion.assembla.com:443"

Not knowing which of these is the right way to go.

soukupmi@gmail.com (JIRA)

unread,
Jan 15, 2016, 8:13:04 AM1/15/16
to jenkinsc...@googlegroups.com

@all: if you encounter this issue, before commenting

  • check that you followed the steps in the issue description at the top of this page
  • start reading at least comment-196458 to find out how your realm string should look like
  • if this does not work keep on reading the comments (including the linked comments)
  • if all this still does not get your installation working --> file a new issue with your stacktrace included

hope this helps and the links make finding what you are looking for easier.

fabien.carmagnac@gmail.com (JIRA)

unread,
Mar 13, 2016, 6:00:03 PM3/13/16
to jenkinsc...@googlegroups.com

"Reposiroty URL" : https://212.227.XXX.YYY:8443/svn/A/trunk/B
Credentials : "user/***"
In "Additional Credentials Realm ", I set : <https://212.227.XXX.YYY:8443> VisualSVN Server
In "Additional Credentials Credentials" , I set "user/***"

Still not work.

fabien.carmagnac@gmail.com (JIRA)

unread,
Mar 13, 2016, 6:01:03 PM3/13/16
to jenkinsc...@googlegroups.com

fabien.carmagnac@gmail.com (JIRA)

unread,
Mar 13, 2016, 6:12:06 PM3/13/16
to jenkinsc...@googlegroups.com

bpettorelli@gmail.com (JIRA)

unread,
Apr 21, 2016, 12:23:02 PM4/21/16
to jenkinsc...@googlegroups.com
Bruno Pettorelli commented on Bug JENKINS-21785
 
Re: Check for changes in folders linked via svn:externals fails due to missing credentials

We can find the realm using curl -I <url_external>

curl will prompt:
HTTP/1.1 401 Authorization Required
Date: <current_date>
Server: Apache/2.2.15 (CentOS)
WWW-Authenticate: Basic realm=<SVN_REALM>
Content-Type: text/html; charset=iso-8859-1

I added the <SVN_REALM> realm value of WWW-Authenticate: Basic realm in the field Additional Credentials/Realm. That do not solve the problem, still have the job failed when it exists change in one of the externals. All externals are on the same SVN project.

recena@gmail.com (JIRA)

unread,
Apr 21, 2016, 1:51:04 PM4/21/16
to jenkinsc...@googlegroups.com

bpettorelli@gmail.com (JIRA)

unread,
Apr 22, 2016, 5:17:04 AM4/22/16
to jenkinsc...@googlegroups.com

channy@videotron.ca (JIRA)

unread,
Aug 18, 2016, 3:47:03 PM8/18/16
to jenkinsc...@googlegroups.com

I just went through this whole thing on my install. None of the ways to find the realm worked for me as I'm using svn+ssh.

Finally enabling the logs in Jenkins on FINE with hudson.scm.CredentialsSVNAuthenticationProviderImpl helped me find the string which was in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name.

I would suggest we add the svn+ssh info to the howto above.

That was painful learning experience.

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

markus.franke@linguwerk.de (JIRA)

unread,
Aug 19, 2016, 3:15:07 AM8/19/16
to jenkinsc...@googlegroups.com

Dear Channy,

you saved my day! At least after changing the Realm of the "Additional Credentials" to the simplified form "svn+ssh://server-name" which you provided, it looks quite promising that it finally works for me.

Best regards and thanks for the thorough analysis.

channy@videotron.ca (JIRA)

unread,
Aug 19, 2016, 9:15:15 AM8/19/16
to jenkinsc...@googlegroups.com
Channy Tremblay updated an issue
 
Change By: Channy Tremblay
h3. Note from the commenters:
h1. This bug has been resolved in Subversion Plugin 2.3. You just need to reconfigure your jobs. You have to add all SVN Credentials as "Additional Credentials" in the job config with correct realm notation "<proto://server:port> SvnRealmName". Please read the comments below.


* Find out the SVN realm name on your client like this:
   {{svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo}}
   * The SVN realm name is set in your SVN Server config svnserve.conf (realm = realm-name). [See man pages here.|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/svnserve.conf.5.html]
*
If you are using svn+ssh your realm will be in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name.
*
Add "Additional Credentials" for **all** repositories involved at the checkout - also for repositories which are referenced by SVN externals.

----
h3. Original Bug Description:

We use svn:externals to map folders of the same repository into the project folders. The 2.1 version of the plugin fails to check for changes and reports a "svn: E200015: No credential to try. Authentication failed" error in the stack trace.

{noformat}
hudson.util.IOException2: revision check failed on https://svn.dummyserver.org/svn/Data/trunk/Dummy
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:736)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:651)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560)
at hudson.model.Run.execute(Run.java:1670)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/Data/trunk/Dummy failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
... 11 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 29 more
{noformat}

channy@videotron.ca (JIRA)

unread,
Aug 19, 2016, 9:16:02 AM8/19/16
to jenkinsc...@googlegroups.com
Channy Tremblay updated an issue
h3. Note from the commenters:
h1. This bug has been resolved in Subversion Plugin 2.3. You just need to reconfigure your jobs. You have to add all SVN Credentials as "Additional Credentials" in the job config with correct realm notation "<proto://server:port> SvnRealmName". Please read the comments below.


* Find out the SVN realm name on your client like this:
   {{svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo}}
   * The SVN realm name is set in your SVN Server config svnserve.conf (realm = realm-name). [See man pages here.|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/svnserve.conf.5.html]
  * If you are using * svn+ssh * your realm will be in the "svn+ssh://server-name" format. No port, no pointy brackets, no extra realm name.

channy@videotron.ca (JIRA)

unread,
Aug 19, 2016, 9:23:04 AM8/19/16
to jenkinsc...@googlegroups.com
Channy Tremblay updated an issue
Change By: Channy Tremblay
Environment: Windows 7 x64 for both hosts and slaves , Linux for both hosts and slaves

guillaume.duff@gmail.com (JIRA)

unread,
Dec 16, 2016, 9:42:05 AM12/16/16
to jenkinsc...@googlegroups.com
Guillaume Dufour commented on Bug JENKINS-21785
 
Re: Check for changes in folders linked via svn:externals fails due to missing credentials

Hello,

for me it's works with svn+ssh but not with https.
I try to add :
{{additionalCredentials: [
[realm: 'My Realm SVN',
credentialsId: 'myId'],
[realm: 'https://192.168.XX.YY:443',
credentialsId: 'myId'],
[realm: 'https://192.168.XX.YY',
credentialsId: 'myId']
]}}
And i still have:
{{hudson.util.IOException2: revision check failed on https://192.168.XX.YY/repos/svnflow/project/trunk/server/com.project.server.webapp
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52)
at hudson.security.ACL.impersonate(ACL.java:213)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:66)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:189)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:195)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:46)


at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)

at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194)
... 14 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:728)
... 32 more
Finished: FAILURE}}

My versions are:

  • Jenkins 2.7.3
  • SVN plugin 2.7.1

So how, i can help you better? (Maybe I can try to do PR, if i can restart the production jenkins in java remot debug....)

guillaume.duff@gmail.com (JIRA)

unread,
Dec 22, 2016, 9:13:07 AM12/22/16
to jenkinsc...@googlegroups.com

Hello, I try to reproduce with a unit test directly on my svn server. com.myapp.server contains 2 externals : com.myapp.server.webapp and another one. But the error not occured.
The changelog file is always empty (<log/>) maybe i must do another previous call to feed it.
How this following test is different as a checkout directly by jenkins 2 ? :

{{
@Test(timeout = 0L)
public void testCheckoutHttpsWithExternalsAndAuthentification() throws Exception {
SystemCredentialsProvider.getInstance().setDomainCredentialsMap(Collections.singletonMap(Domain.global(),
Arrays.<Credentials>asList(
new UsernamePasswordCredentialsImpl(CredentialsScope.GLOBAL, "1-login", null, "mylogin", "mypassword")
)
));

List<SubversionSCM.ModuleLocation> locations = Arrays.asList(
new SubversionSCM.ModuleLocation("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", "1-login",".", SVNDepth.INFINITY.getName(), false)
);
List<SubversionSCM.AdditionalCredentials> additionalCredentials = Arrays.asList(
new SubversionSCM.AdditionalCredentials("Magillem Design Services SVN","1-login"),
new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY:443","1-login"),
new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY","1-login"),
new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow","1-login"),
new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server.webapp","1-login")
);
SCM scm = new SubversionSCM(locations, new UpdateUpdater(), null, null, "", "", "", "", false, false, additionalCredentials);
SCMSource source = new SingleSCMSource(null, "https://192.168..XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", scm);
TaskListener listener = StreamTaskListener.fromStdout();
// First check fetching of all heads. SCMHeadObserver.Collector.result is a TreeMap so order is predictable:
assertEquals("[SCMHead

{'https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server'}

]", source.fetch(listener).toString());
// SCM.checkout does not permit a null build argument, unfortunately.
Run<?,?> run = r.buildAndAssertSuccess(r.createFreeStyleProject());
// Retrieval of heads:
FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds
1")).child("tmp");
Launcher launcher = new Launcher.LocalLauncher(listener);
SCMRevisionState scmRevisionState = scm.calcRevisionsFromBuild(run , ws, launcher, listener);
assertRevision2(source.fetch(new SCMHead("https://192.168.20.150/repos/svnflow/crystalbulb/trunk/server/com.mds.crystalbulb.server"), listener), "null", source, run, listener, launcher, scmRevisionState);
}

private void assertRevision2(@CheckForNull SCMRevision rev, @CheckForNull String expectedFile, @NonNull SCMSource source, @NonNull Run<?,?> run, @NonNull TaskListener listener, Launcher launcher, SCMRevisionState scmRevisionState) throws Exception {
if (rev == null)

{ assertNull(expectedFile); return; }

FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds
1")).child("tmp");
File changelog = new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1
changelog");
source.build(rev.getHead(), rev).checkout(run, launcher, ws, listener, changelog, scmRevisionState);
FilePath file = ws.child("file");
assertEquals(expectedFile, file.exists() ? file.readToString() : null);
}}}

guillaume.duff@gmail.com (JIRA)

unread,
Dec 22, 2016, 9:14:03 AM12/22/16
to jenkinsc...@googlegroups.com
Guillaume Dufour edited a comment on Bug JENKINS-21785
        assertRevision2(source.fetch(new SCMHead("https://192.168. 20 XX . 150 YY /repos/svnflow/ crystalbulb myproject /trunk/server/com. mds myapp . crystalbulb. server"), listener), "null", source, run, listener, launcher, scmRevisionState);

    }

    private void assertRevision2(@CheckForNull SCMRevision rev, @CheckForNull String expectedFile, @NonNull SCMSource source, @NonNull Run<?,?> run, @NonNull TaskListener listener, Launcher launcher, SCMRevisionState scmRevisionState) throws Exception {
        if (rev == null) {
            assertNull(expectedFile);
            return;
        }
        FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1")).child("tmp");
        File changelog = new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1\\changelog");
        source.build(rev.getHead(), rev).checkout(run, launcher, ws, listener, changelog, scmRevisionState);
        FilePath file = ws.child("file");
        assertEquals(expectedFile, file.exists() ? file.readToString() : null);
    }}}

guillaume.duff@gmail.com (JIRA)

unread,
Dec 22, 2016, 9:15:03 AM12/22/16
to jenkinsc...@googlegroups.com
Guillaume Dufour edited a comment on Bug JENKINS-21785
Hello, I try to reproduce with a unit test directly on my svn server. com.myapp.server contains 2 externals : com.myapp.server.webapp and another one. But the error not occured.
The changelog file is always empty (<log/>) maybe i must do another previous call to feed it.
How this following test is different as a checkout directly by jenkins 2 ? :

{{
    @Test(timeout = 0L)
    public void testCheckoutHttpsWithExternalsAndAuthentification() throws Exception {
        SystemCredentialsProvider.getInstance().setDomainCredentialsMap(Collections.singletonMap(Domain.global(),
                Arrays.<Credentials>asList(
                     new UsernamePasswordCredentialsImpl(CredentialsScope.GLOBAL, "1-login", null, "mylogin", "mypassword")
                )
        ));

        List<SubversionSCM.ModuleLocation> locations = Arrays.asList(
                new SubversionSCM.ModuleLocation("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", "1-login",".", SVNDepth.INFINITY.getName(), false)
        );
        List<SubversionSCM.AdditionalCredentials> additionalCredentials = Arrays.asList(
                new SubversionSCM.AdditionalCredentials(" Magillem Design Services Realm of SVN","1-login"),

                new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY:443","1-login"),
                new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY","1-login"),
                new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow","1-login"),
                new SubversionSCM.AdditionalCredentials("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server.webapp","1-login")
        );
        SCM scm = new SubversionSCM(locations, new UpdateUpdater(), null, null, "", "", "", "", false, false, additionalCredentials);
        SCMSource source = new SingleSCMSource(null, "https://192.168..XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server", scm);
        TaskListener listener = StreamTaskListener.fromStdout();
        // First check fetching of all heads. SCMHeadObserver.Collector.result is a TreeMap so order is predictable:
        assertEquals("[SCMHead{'https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server'}]", source.fetch(listener).toString());
        // SCM.checkout does not permit a null build argument, unfortunately.
        Run<?,?> run = r.buildAndAssertSuccess(r.createFreeStyleProject());
        // Retrieval of heads:
        FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1")).child("tmp");
        Launcher launcher = new Launcher.LocalLauncher(listener);
        SCMRevisionState scmRevisionState = scm.calcRevisionsFromBuild(run , ws, launcher, listener);
        assertRevision2(source.fetch(new SCMHead("https://192.168.XX.YY/repos/svnflow/myproject/trunk/server/com.myapp.server"), listener), "null", source, run, listener, launcher, scmRevisionState);

    }

    private void assertRevision2(@CheckForNull SCMRevision rev, @CheckForNull String expectedFile, @NonNull SCMSource source, @NonNull Run<?,?> run, @NonNull TaskListener listener, Launcher launcher, SCMRevisionState scmRevisionState) throws Exception {
        if (rev == null) {
            assertNull(expectedFile);
            return;
        }
        FilePath ws = new FilePath(new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1")).child("tmp");
        File changelog = new File("C:\\Users\\gdufour\\AppData\\Local\\Temp\\hudsonFixedtest\\jobs\\test0\\builds\\1\\changelog");
        source.build(rev.getHead(), rev).checkout(run, launcher, ws, listener, changelog, scmRevisionState);
        FilePath file = ws.child("file");
        assertEquals(expectedFile, file.exists() ? file.readToString() : null);
    }}}

guillaume.duff@gmail.com (JIRA)

unread,
Jan 2, 2017, 8:25:08 AM1/2/17
to jenkinsc...@googlegroups.com

So i debug the plugin and i found why. It's because the format of the realm is not just the realm name but the full name with uri like:
<https://XX.YY.WW.ZZ:PORT> My Realm Name
So it's my fault. sorry

jglick@cloudbees.com (JIRA)

unread,
Jan 30, 2017, 6:05:07 PM1/30/17
to jenkinsc...@googlegroups.com
Jesse Glick closed an issue as Fixed
 

I see no reason for this to have been reopened.

Change By: Jesse Glick
Status: Reopened Closed
Resolution: Fixed
Reply all
Reply to author
Forward
0 new messages