renea So I was able to get the issue you describe by following your test case... but it would appear - at least from my testing - that the issue is really that the additional credentials have not been provided.

As soon as I added additional credentials with the correct realm the polling started to work and the issue disappeared.

The key thing to remember is that svn:externals can be used to leverage the read-access that Jenkins has against the repository where you might have lesser access.

So if I have write access to projecta but no access to projectc, Jenkins may well be locked down so I can only see the projecta job, but by committing an svn:externals pointing at projectc and modifying the build script to tar-gz the contents of that external and sftp it to my computer I can effectively bypass the security permissions on the subversion repository.

The hard part is getting the realm correct, so for example if you run:

$ svn info https://svn.apache.org/repos/private
Authentication realm: <https://svn.apache.org:443> ASF Members
...

Then the realm you want to specify in additional credentials is: <https://svn.apache.org:443> ASF Members

Similarly if subversion is running via svnserve you might see

$ svn info svn://localhost
Authentication realm: <svn://localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680

And again the realm you need to specify in the additional credentials would be: <svn://localhost:3690> cd90323c-3140-4208-9a36-a9a21ef8b680

Can you check whether you actually have specified the realm correctly?

stephenconnolly Okay, this works for me.
I had specified the urls of the externals, not the realm.

From all the test cases presented so far, this is a case of the incorrect realm or no realm being configured.

JENKINS-21785 discussed the externals issue before in great detail. We should limit this one specifically to variables in the URL.

How can you display the realm for a repository? For me with svn 1.8.13 on OSX I get this:

$ svn info
Path: .
Working Copy Root Path: /Users/ari/svn/apache-foundation
URL: https://svn.apache.org/repos/private/foundation
Relative URL: ^/foundation
Repository Root: https://svn.apache.org/repos/private
Repository UUID: 694d45b4-53eb-0310-9336-ddcd440d954d
Revision: 59701
Node Kind: directory
Schedule: normal
Last Changed Author: clr
Last Changed Rev: 59700
Last Changed Date: 2015-06-25 10:54:00 +1000 (Thu, 25 Jun 2015)

which part is the realm that Jenkins is wanting?

I don't understand why its not enough to have credentials already setup in ~/.subversion/auth/... and in the global credentials section in jenkins.
I don't want to provide additional credentials to every project setup because in the 2.4 plugin its not needed and it works there. So why its needed now and why does it not use the global configured svn credentials for the server - i don't have different realms or servers in use because all externals are pointing to the same server but may use a different repository (although it may be the same too) - i don't use variables in repository urls. It would be fine to use the already known credentials because they are identical for the complete server - how to configure that?

Same for me. My svn:externals also point to the same server. Thus the credentials and also the realm of the svn:externals and the main repository are in my case (and probably in 99% of hudson users) identical. Since hudson knows already the credentials of the server I wonder why it does not take the same credentials for the externals (which have exactly the same realm). Entering the credentials twice might be a workaround. However, it looks for me like a bug and since version 2.4 was capable of handling it correctly it's furthermore a regression.

Reopened to discuss the possible regression vs. 2.4 plugin version.

Created JENKINS-29079 to discuss possible improvements of the configuration.

kasparek Hello, Do you think that this ticket is related to JENKINS-23007? Maybe duplicated?

Yes, seems like the same problem with variables and repo URL

kasparek, Hello, Did you see that JENKINS-23007 was resolved recently?

Indeed, that should be ok for the case related to variables in url but does this fix also the case of repos with externals ?

splashnenen, Nothing releated with externals have been included in Subversion Plugin 2.5.2. But if you file an issue with a detailed description including a step by step process in order to reproduce the bug, I'd like to help you.

usecase is this one :

• main configured svn repository is : http://myrepo/example/main_product
• credentials for this repository are set using the 'credentials plugin'
• there are externals which are on the same repository (chechbox 'ignore externals' is obviously unchecked)

The jobs polls the repo and update fails on external if those conditions are verified :
1. there are modifications on both main repository and this external
2. this external is referenced twice

All externals passed ok, the one which is not up to date updates successfully then fails on second check with error "Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled."

(See attached 'external error' file)

splashnenen Did you define Additional Credentials and make sure the authentication realm is the exact string used by your SVN server?

splashnenen, I'll try to reproduce this scenario. danielbeck have pointed something important.

I didn't define addintional credentials as the repository is the same than the main one in configuration.
And according to the screenshot, you may check that update is well done on external at first try, so credentials seems to be well considered.
Error pops at second try only, the error message may in fact mask the real problem.

I didn't define addintional credentials as the repository is the same than the main one in configuration.

That's not how it works. See e.g. https://issues.jenkins-ci.org/browse/JENKINS-21785?focusedCommentId=196363&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-196363

Thanks for this information but it doesn't match with the fact that update is well done for external at first check, meaning that credentials are well used, no ? It's only at second check that it fails. Maybe we could check if Manuel is able to reproduce.

it doesn't match with the fact that update is well done for external at first check

According to Stephen Connolly, the reason for this is connection reuse/caching of some kind in SVNKit.

Hello, checked the current behavior - the polling with variables seems to work as far as SVN is concerned now. The remaining problem is, that even if there is default value for the variable to be used for polling and build, the last manually used value (e.g. SVN branch for our case) is used instead of default value (trunk).

e.g. This build is parameterized:
name: SVN_SUBDIR
repo url: svn+ssh://xxx/svn/PROJECT
Default value: trunk

String Parameter:
name: REVISION
default value: HEAD

Source Code Management:
repo url: svn+ssh://xxx/svn/PROJECT/${SVN_SUBDIR}@${REVISION}

if I request the build of branch-ABC, then automatic polling will try to check this branch instead of trunk.

Would you like me to fire this as new independent issue here? (not talking about SVN external for now)

Bye

kasparek Hello. In my opinion, the problem related to SCM Polling + parameterized URL is solved. It would be interesting to create another ticket to address your scenario. Do you agree?

I have added credentials for each external (although it's on the same repository) and i still have the problem : the first update of external is ok then checking if this same external is up to date fails with error (as shown in 'external error.png' screenshot).
It seems there is another thing on that, could you have a look to double check ?
Thanks a lot

aaubert, I'll have to configure a similar scenario using externals.

The issue still present on plugin 2.5.2. Have to use 2.4.5.

Hi kasparek,

Please check my proposal in JENKINS-19560 and related comments in JENKINS-14155

Both relate to handling the "DEFAULT" value and "automatic branch selection_.

I second aaubert comment, this is still not fixed and still breaks for me with 2.5.3 - while 2.4.5 is working.
Credentials are selected in the configuration and it does work while checking for updates on the checkout pointing to externals. But then looking for changes on those externals it fails - but both are in the same repository.
Look at the trace below - it does successfully fetch changes from

https://svn.local.domain/svnrepos/dev/util/branches/1.8

but fails later in the same run trying to look for changes on

https://svn.local.domain/svnrepos/dev/util/branches/1.8

- how could this be, it can fetch data from there but is unable to check the revision later on - seems like a bug to me and reads like aaubert problem.

Updating https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 at revision '2015-09-16T13:05:00.748 +0200'
Fetching 'https://svn.local.domain/svnrepos/dev/util/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/util'
U         util/src/java/de/sf/util/MailSender.java
At revision 52046
Fetching 'https://svn.local.domain/svnrepos/dev/usr/branches/1.8' at -1 into '/home/jenkins/Development/src/usr-1.8/usr'
At revision 52046
At revision 52046
no change for https://svn.local.domain/svnrepos/dev/releases-hooks/trunk/usr-1.8 since the previous build
hudson.util.IOException2: revision check failed on https://svn.local.domain/svnrepos/dev/util/branches/1.8
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:137)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:726)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:861)
	at hudson.scm.SCM.checkout(SCM.java:485)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
	at hudson.model.Run.execute(Run.java:1741)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:408)
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:60)
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:759)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
	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:1032)
	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
	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:21)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
	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:184)
	... 12 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:689)
	... 30 more

FYI: I don't use any variables in URLs, just externals are used.

tkrah Thanks so much. Your feedback is awesome. I can work on this bug with your information.

tkrah

Environment

• Jenkins ver. 1.568 (minimum version required by Subversion Plugin)
• Subversion Plugin 2.5.3
• svnserve, version 1.6.17 (r1128011)
• 1 repository with name: external1 (requires credentials)
• 1 repository with name: JENKINS-22542 (requires the same credentials) and its svn:externals property:

  pegaso:JENKINS-22542 recena$ svn propget svn:externals
  svn://192.168.1.106/external1 external1
  

First build (checkout process)

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Checking out a fresh workspace because there's no workspace at /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Cleaning local Directory .
Checking out svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:39:46.217 +0200'
 U        .
Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
A         external1/file1.txt
 U        external1
At revision 3
At revision 4
no change for svn://192.168.1.106/JENKINS-22542 since the previous build
no change for svn://192.168.1.106/external1 since the previous build
Finished: SUCCESS

Second build (update process)

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building in workspace /Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542
Updating svn://192.168.1.106/JENKINS-22542 at revision '2015-09-17T00:40:18.385 +0200'
Fetching 'svn://192.168.1.106/external1' at -1 into '/Users/recena/Development/projects/subversion-plugin/work/workspace/JENKINS-22542/external1'
At revision 3
At revision 4
no change for svn://192.168.1.106/JENKINS-22542 since the previous build
no change for svn://192.168.1.106/external1 since the previous build
Finished: SUCCESS

SCM Polling

Started on Sep 17, 2015 1:05:00 AM
Received SCM poll call on master for JENKINS-22542 on Sep 17, 2015 1:05:00 AM
svn://192.168.1.106/JENKINS-22542 is at revision 4
svn://192.168.1.106/external1 is at revision 3
Done. Took 33 ms
No changes

In Jenkins, Subversion Workspace Version configured to 1.8

I could not reproduce the bug. I'll try with more configurations. Any idea is welcome.

tkrah Are you sure the realm is specified correctly?
See also https://issues.jenkins-ci.org/browse/JENKINS-22542?focusedCommentId=230849 by stephen connolly.

The Realm is NOT h..ps://svn.local.domain/svnrepos/dev/util ,
but should look more like "<h..ps://svn.local.comain> svn users".

When you create a new set of credentials the realm is used as the description.

Hi recena. Thanks for these tests.
To me, your case is correct. To reproduce now, you may try a third run :

• use 'credentials plugin' and set credentials as user/password in the credentials global configuration
• configure your job to use this credential
• make changes in your 'external1' so that the build will update this external
• run this build and you should have the problem which happens during last phase of summary displaying 'No change for...'
  Please let me know if you need any further information.

renea You are speaking about the Realm i can specify when using Additional Credentials. However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them. I can't specify a Realm in the global credentials - i've just configured there my URI spec to be https, the hostname to be svn.local.domain and the path part to be /svnrepos/** .
Looking at the help of Description part when creating new credentials it reads:

A description for the domain, not used by Jenkins itself.

So something wrong there if i need to add a Realm to a description field which is not used.

Hi aaubert,

• I used credentials-plugin to set my credentials.
• I configured my job to use this credentials.

I'm going to try your third and fourth step.

recena

I got it instantly failing with this recipe:

1. create a new svn repository /tmp/JENKINS-22542 with svnadmin create and configure svnserve.conf, use default passwd stuff.
2. start it svnserve -d --foreground -r /tmp/JENKINS-22542
3. go to /tmp/import directory and create 3 dirs there: root, link1, link2
4. do a svn import for for those 3
5. go to /tmp/checkout and do a svn checkout svn://localhost:3690/
6. now create a file in link1 directory which contains:

   link2 svn://localhost:3690/link2
   link1 svn://localhost:3690/link1
   

1. now cd to root directory and do a svn propset svn:externals --file ../link1/test .
2. do a svn ci . on root

1. Now configure a freestyle build job which uses current credentials plugin and subversion plugin and point configuration to:
   svn://localhost:3690/root

1. Add global credentials there for harry/harryssecret using the passwd stuff from svnserve. Run it - works.
2. Now do a "svn add test" in the link1 directory and commit it.
3. Now trigger a second build - it fetches the changed file but fails on calcChangeLog(..)
4. Run it again - works now again.
5. Edit the "test" file and switch lines and commit the change.
6. Trigger the build again - failing again.

tkrah I was under the same assumption. But as of 2.5.0 there is a regression (in my eyes) that whenever you use externals you need to specify additional (but the same) credentials.
These credentials are only used for changelog calculations.

Can you try with additional credentials specified?
And yes, the description field for credentials is not used by jenkins. But the value which is automatically filled in there when you create the credentials matches the realm name.

renea

Gotcha - that's interesting. If i specify additional ones with the Realm although its the "same" it does work. But that's imho clearly a regression - i second your opinion. It works without that in 2.4.5. I would understand that you need additional ones if the external is pointing to another repository which needs different credentials than the already configured ones on the module. But that is not the case here. How to tell people that they need to specify the same credentials twice for the same repository - i am not convinced that this is the way it should be. From a logical point of view its seems illogical to me todo that - i won't ever come to this "workaround" or solution because its called "Additional Credentials". It should imho work like in 2.4.5 with the ones already set.

renea, tkrah

I agree, it is illogical (and an UX issue). I'll solve it this night.

recena to save you some time searching:

I looked earlier this year but haven't had the time to really dive in, fix and test.
I came to the conclusion that the fault is likely in SubversionChangeLoguilder.Java:128

        ISVNAuthenticationProvider authProvider =
                CredentialsSVNAuthenticationProviderImpl
                        .createAuthenticationProvider(build.getParent(), scm, null);

The null should (I think) be the module location, but I'm not sure how situation with different modules including externals are to be handled.

However i did not even considered to configure additional ones because i don't need them. The external points to the same repository, i am just using global credentials and configured to job to use them.

You'll get nowhere by refusing to do what everyone tells you is the solution to this issue. That additional credentials are needed has been posted in numerous comments to this issue for over a year. I realize that having to do this is a bit annoying (been there, reconfigured 400 jobs), but for now the solution for externals and variables is to use Additional Credentials.

It works without that in 2.4.5.

I think It was always supposed to fail as a security measure as stephenconnolly explained in a comment above. He once told me that there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there.

I don't refuse anything - i just try to understand why this is failing now and if there is some good reason - at least the changelog for subversion should mark a breaking change here so that users know about.
Imho its just not logical - its called Additional - not "External Credentials" - why can't Jenkins just provide the same configured gobal credentials automatically in that case?
Another thing which is confusing - if this is a security measure - its imho failing, because it does fetch the external changes but does only fail on Changelog generation - if its for security, it should fail already fetching the external stuff but it fails only for changelog stuff - why is this difference, i would expect to fail completly and not to be able to fetch the external stuff and failing later on the not so important changelog (in case of security terms)? I am just trying to understand why this should be the "official" solution to that problem - it seems not logical and at least until now i did not read something why Jenkins can't provide a better solution to that case than doubling all credentials configuration.

Another Idea - if this is the proposed solution - why keeping the first credentials option at all? Just remove it and rename "Additional Credentials" to "Credentials" and users are forced to set some Credentials there. They won't do it twice and i would work out-of-the box, how about that?

Another thing which is confusing - if this is a security measure - its imho failing

Please let me repeat:

… there's an issue with SVNKit reusing the same connection to download externals when it should not. Since 2.5 updated SVNKit to a new version, it's likely some part of that behavior was changed there.

I'm not 100% sure this is the cause here, but it looks like a possible culprit.

If there is an issue there - can you link the upstream bugreport from SVNKit in this ticket please?

tkrah

I did more tests with this environment and everything is working fine.

I'm going to try with your environment, svn:externals against the same repository.

hallelujah! It seems I found the bug!

@Manuel: We are eager to hear the story + when the fix will come out...

@ Manuel Eagerly awaiting your fix. Since we use LTS releases, we ask for a new LTS bugfix release asap.

bangalore AFAIK, LTS policy only applies to Jenkins CORE.

Yes, SVN plugin is independent from Jenkins core since 1.4xx (I don't recall the exact version).
You can just update the plugin when it gets released.

The new version will be bundled into Jenkins core in 1.625.2, I suppose

oleg_nenashev SVN plugin has been detached from core since 1.310. And we're still bundling 1.54 due to the change to credential storage in Subversion 2.0.

You can update any plugin to any version compatible with the release you're running. For Subversion plugin, this is 1.568 and newer.

danielbeck, I meant here (bundled).

Prove that an established instance's update to 2.x will go smoothly. We've so far not done that due to concerns that credential migration is a breaking change. Given how Stephen Connolly tightened security on externals, it's almost certainly breaking existing setups for users that are still on 1.x.

recena, if you have a minute, please tell us what the bug was! There seem to be a number of people, including me, waiting eagerly to know what was the cause of our troubles

Hi,

I said I had found the bug but if you configure the additional credentials in a right way, everything works fine.

In my case, I configured a credentials (in additional credentials) using this realm <svn://192.168.1.106:3690> example real. It is very important that the realm is written rightly. Here you can see two console outputs (SCM Polling):

Started on Sep 22, 2015 10:24:00 PM
Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:24:00 PM
svn://192.168.1.106/JENKINS-22542 is at revision 7
svn://192.168.1.106/external1 is at revision 4
svn://192.168.1.106/external2 is at revision 1
Done. Took 0.18 sec
No changes

Started on Sep 22, 2015 10:26:00 PM
Received SCM poll call on master for JENKINS-22542 on Sep 22, 2015 10:26:00 PM
svn://192.168.1.106/JENKINS-22542 is at revision 8
  (changed from 7)
svn://192.168.1.106/external1 is at revision 4
svn://192.168.1.106/external2 is at revision 1
Done. Took 24 ms
Changes found

Regards,

Hi,

can you please tell me how to configure the additional credentials when the Subversion server is using a HTTPS connection because

<https://svn/repo> Subversion Repository

didn't seem to work.

Regards,
Philip

recena - so just for understanding - is this default behaviour going to be fixed to use the configured default credentials when searching for additional credentials and nothing extra is configured to get this one working - or whats the proposed solution in an UX friendly way?

pschoemig Please read JENKINS-21785.

pschoemig, you have to use realm. It is a string. To know this value, I followed these basic steps:

1. Remove my .subversion folder (in my local development environment)
2. Checkout the source code. This was the output

pegaso:temp recena$ svn co https://subversion.assembla.com/svn/jenkins-26318/
Error validating server certificate for 'https://subversion.assembla.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.assembla.com
 - Valid: from Wed, 16 Apr 2014 13:31:17 GMT until Thu, 24 Mar 2016 19:30:40 GMT
 - Issuer: http://certs.godaddy.com/repository/, GoDaddy.com, Inc., Scottsdale, Arizona, US
 - Fingerprint: ec:9f:9d:b2:39:e1:34:81:7b:27:f6:51:30:8b:ac:41:5b:62:09:19
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://subversion.assembla.com:443> Assembla Restricted Area
Password for 'recena':

You can see my realm: <https://subversion.assembla.com:443> Assembla Restricted Area

Regards,

tkrah, the main goal here is to verify that there is no bug. If we want to improve this, we should file a new ticket for that.

recena depends on the point of view of the person. To me (and like read above to others too) this one is a regression to 2.4.x plugin because you need to specify "Additional Credentials" for the "same" repository. This is - you agreed upon - illogical todo. So to me this is a Bug - i can of cause just open a new ticket which referes to this ticket which has a known workaround and the UX issue, which is caused by this workaround, is tracked at this new ticket - e.g. getting rid of the first credentials dialog and just have the "Additional" one like proposed.
Opinions?

tkrah, recena , there is already a ticket: JENKINS-29079 .

tkrah, I think it is more interesting if we close this ticket and continue working on JENKINS-29079.

In this ticket there is enough information to clarify this UX issue.

If kasparek agree, I propose to close this ticket.