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 jenkinsci-dev+unsubscr...@googlegroups.com
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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