The issue I am actually having right now is how to handle the case where there is svn:externals and those externals need a different set of credentials... but I am not sure that this use case I am fearing actually works in Jenkins right now
On 8 August 2013 14:30, Stephen Connolly <[email protected]>wrote: > Well I can have the default behaviour be to pick the first nearest > matching credential if the specified credential does not work. That way you > can store the credentials within a folder for use by the jobs within that > folder. Could also provide a helper groovy function to allow resolving > credentials from the template transformer > > > On 8 August 2013 14:18, James Nord (jnord) <[email protected]> wrote: > >> Hi Stephen,**** >> >> ** ** >> >> OK – so just had a play with it.**** >> >> ** ** >> >> There is a slight flaw in your plan – and that is how it would appear to >> break multiple sites and cloudbees templates.**** >> >> ** ** >> >> Looking at the node configuration the credentials the credentials are >> linked by ID not name (which is probably a good thing!), however now we >> need to sync across not only cloudbees templates definitions but also >> credentials and some systems have credentials that others for security >> reasons shouldn’t have and there will be no way of knowing what ID should >> be used in any job template :-o**** >> >> ** ** >> >> /James**** >> >> ** ** >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Stephen Connolly >> *Sent:* 08 August 2013 13:50 >> *To:* [email protected] >> *Subject:* Re: [POLL] how addicted are you to the current Subversion >> plugin's authentication model?**** >> >> ** ** >> >> You will create a credentials domain in the Manage Credentials screen >> which has a specification like: **** >> >> ** ** >> >> URI Scheme: svn+ssh,ssh**** >> >> Hostname and port: include=*.foo.com:22**** >> >> ** ** >> >> You will add the single ssh key into that credential domain.**** >> >> ** ** >> >> When you type in any url that matches the domain specification, then that >> credential will be added to the drop down.**** >> >> ** ** >> >> In the normal case you will not have any global ssh type credentials, so >> as soon as you start to type svn+ssh: the domain requirements will narrow >> down to only those that are in svn+ssh domains... then when you get as far >> as svn+ssh://someserver.foo.com/ any other credential domains for >> different hosts will have been eliminated and you will be left with the >> single choice.**** >> >> ** ** >> >> The connection check will tell you if you have got the required >> credentials as before... I'll see if I can get some screenshots to >> illustrate, but the credential domain screenshot on >> https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Plugin should >> give you a better idea**** >> >> ** ** >> >> On 8 August 2013 13:20, James Nord (jnord) <[email protected]> wrote:**** >> >> Hi Stephen,**** >> >> **** >> >> Can you explain some more about what you mean by “relevant credentials >> for that URL” – and how you may determine what is relevant?**** >> >> **** >> >> Currently for svn+ssh we don’t need to add every single repositrory URL >> into Jenkins: I have defined one and one credential for Jenkins for >> svn+ssh://mysvnserver.foo.com/ even though the repositories are >> actually svn+ssh://mysvnserver.foo.com/svn/repo1, svn+ssh:// >> mysvnserver.foo.com/svn/repo2 etc.. **** >> >> **** >> >> The other thing if you are doing this from a generic usability point is >> perhaps think about if multiple options are available being able to set one >> as a default such that users who are unsure of which option to choose will, >> if they do nothing, get the correct option 80% of the time.**** >> >> **** >> >> /James**** >> >> **** >> >> **** >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Stephen Connolly >> *Sent:* 08 August 2013 13:02 >> *To:* [email protected]**** >> >> >> *Subject:* [POLL] how addicted are you to the current Subversion >> plugin's authentication model?**** >> >> **** >> >> In working on integrating with the Credentials plugin there is, from my >> point of view, a lot of insanity and crazy ways of doing auth.**** >> >> **** >> >> How attached are people to the existing way?**** >> >> **** >> >> The way I want to deliver is that you have a drop down underneath any of >> the module remote url fields which lists the relevant credentials for that >> URL (including none) and you would always make a selection (even if that >> selection is leaving the default of "none" selected)**** >> >> **** >> >> I would like to ditch entirely the existing model of credentials and go >> straight for this simplified model.**** >> >> **** >> >> What do people think?**** >> >> >> >> -- >> Sent from my phone**** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out.**** >> >> ** ** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
