Somehow your screenshots are cut off - I cant see any Test-Connection
Button?!

Anyway, implementing a test-connection is actually quite easy using a
validateButton element. It works like this:

supposed, in your .jelly form you have the input-fields named "user",
"url" and "key", then you can write in your jelly:

<f:validateButton title="${%Test Connection}" progress="${%Testing...}"
method="testConnection" with="user,url,key"/>

In your corresponding DescriptorImpl you then simply put a method that
gets the parameters specified in the with="..." attribute like this:

public FormValidation doTestConnection(@QueryParameter String user,
@QueryParameter String url, @QueryParameter String key) throws IOException {
        ...
}

you get the idea ...
 -Fritz

On 21.11.2016 22:11, iwarapter wrote:
> Hi,
> 
> I'm currently in the process of creating a new credentials provider and
> looking for feedback on the based where to implement its authentication
> with the backend. 
> 
> I have two ways i can probably go with this one is provide the
> authentication through credentials similar to the kubernetes plugin for
> example:
> 
> <https://lh3.googleusercontent.com/-hXbsw3-YWd4/WDNgjt84AHI/AAAAAAAAACg/tWrThothLN0yJchUEJT7b3l26jJNsHMaQCLcB/s1600/Screen%2BShot%2B2016-11-21%2Bat%2B20.59.05.png>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The alternative is i provide it directly using something similar to the
> private key source
> <https://github.com/jenkinsci/ssh-credentials-plugin/blob/master/src/main/java/com/cloudbees/jenkins/plugins/sshcredentials/impl/BasicSSHUserPrivateKey.java#L270>
> mechanic used in the ssh-credentials plugin:
> 
> <https://lh3.googleusercontent.com/-AOC4CXYnZsc/WDNhde8cBQI/AAAAAAAAACo/uUVEYKp22Wct31TJ8AmPbSo0y1CG8PNcQCLcB/s1600/Screen%2BShot%2B2016-11-21%2Bat%2B20.56.38.png>
> 
> 
> The problem with the second option is providing a 'Test Connection'
> style button is very hard (i have no idea if Jelly could even do it).
> Whilst providing that feature with the first option is easy, however it
> seems a little silly using the original credentials provider as i would
> have to implement a new credential impl (for tokens). Am i over thinking
> this? I'm aware poor choices early on have the potential to cause alot
> of pain later down the line.
> 
> Happy for feedback!
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/6366b390-4a7b-4880-b35b-e661cc73d645%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/6366b390-4a7b-4880-b35b-e661cc73d645%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b1b6122a-7357-1b9d-1f5b-39c16cf729fc%40fritz-elfert.de.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to