Re: Dynamically populate drop down in builder interface

[Cameron Esfahani]

If I understand your builder code, I think you need to refer to "credentialsId" 
with a @RelativePath.

Something like the following:

public ListBoxModel doFillTestIdItems(Build context, @QueryParameter( 
"credentialsId" ) @RelativePath( ".." ) final String credentialsId )
...

Cameron Esfahani
di...@apple.com

"Even paranoids have enemies."

Henry Kissinger



> On Nov 15, 2017, at 12:27 AM, 'Marco Brondani' via Jenkins Developers 
>  wrote:
> 
> Hello All,
> I have tried and followed the suggestion from Stephen.
> Everything works well when I implement the doFill__Items from the Builder 
> Descriptor.
> I have however problems to retrieve the credentials when doing it from within 
> an Action Descriptor.
>  
> In my builder I have:
>  
> 
> 
> 
> 
>  Action
> 
> 
>
> descriptors="${descriptor.getApplicableActions()}"/>
>   
> Then, within my Actions I’d like to have
>  
> 
> 
> 
> 
>  
> And in the doFillTestIdItems() make a request to the API with the data in 
> credentials.
>  
> public ListBoxModel doFillTestIdItems(Build context, @QueryParameter 
> String credentialsId) {
> 
> final CredentialImpl credential = 
> CredentialsProvider.findCredentialById(credentialsId,
> CredentialImpl.class, context, 
> URIRequirementBuilder.create().build());
> 
> HandleAPI handleAPI = new HandleAPI(credential.getTeamSlug(), 
> credential.getKeyId());
> this.suitesResponse = (SuitesResponse)(handleAPI.callSuitesAPI());
> ListBoxModel items = 
> this.getListOfSuitesFromResponse(this.suitesResponse);
> 
> return items;
> }
>  
> However this returns a java.lang.NullPointerException
>  
> Any help?
> Anyone could point me to an example on GitHub that’s implemented similarly?
>  
> Thank you very much,
> M.-
> 

-- 
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/2A605DED-1812-4BCA-B923-627C6F8CFCE3%40apple.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

this is really work in progress, i.e not even tested on my own before I
propose this in a PR :P
was just for information that I was looking into implementing a fix for
this idea

2017-11-15 16:24 GMT+01:00 Jesse Glick :

> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>  wrote:
> > proposed improvement to Descriptor.configure  (WiP) :
> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>
> If you are soliciting feedback, just file as a PR and mark as
> `work-in-progress`. Easier to gather comments that way.
>
> --
> 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/CANfRfr0%2Bd%2BE1RO8PTVeUHnpvH3367zd6D%
> 2Bwa2%2BAeSTgTd9Zc4Q%40mail.gmail.com.
> 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/CANMVJzn2X3r45HQmUyHYKOFF%3DCrgJvv2TGi_2OOU7Rw0Xz3UMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[Jesse Glick]

On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
 wrote:
> proposed improvement to Descriptor.configure  (WiP) :
> https://github.com/ndeloof/jenkins/tree/JENKINS-48018

If you are soliciting feedback, just file as a PR and mark as
`work-in-progress`. Easier to gather comments that way.

-- 
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/CANfRfr0%2Bd%2BE1RO8PTVeUHnpvH3367zd6D%2Bwa2%2BAeSTgTd9Zc4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

proposed improvement to Descriptor.configure  (WiP) :
https://github.com/ndeloof/jenkins/tree/JENKINS-48018

*tl;dr: *
provide default implementation to Descriptor#configure using databinding.
reset descriptor to default values based on properties types default *or*
convention to declare a public {{property}}_default constant. Also updated
jelly taglibs to use this same constant in form inputs as default value
(until explicitly set)

>>> this configuration mechanism isn't atomic, and
>>> there's some possible race condition for related attributes to have
>>> inconsistent values seen from another thread while the configuration is
>>> being changed.
>>
>> This isn't a new problem, right?
>
> It _would_ be a new problem if you refactored an existing
> configuration form to use the recommended idioms and thereby
> introduced the race condition.

No, this race condition already exists while one submit configuration form,
whenever we use @databound or not, other threads _already_ can see
descriptor in a weird intermediate state. Hopefully one does not update
global configuration every millisecond.

2017-11-15 15:44 GMT+01:00 Jesse Glick :

> On Tue, Nov 14, 2017 at 10:19 PM, Kohsuke Kawaguchi 
> wrote:
> > I suppose we could create a variant of req.bindJSON(this,json) that does
> set
> > null on proeprties that are not specified in JSON.
>
> Yes, that would be a helpful convenience API, and it would make sense
> to call it in a newly introduced default implementation for
> `Descriptor.configure`. For compatibility reasons we could probably
> not change the implementation of `GlobalConfiguration.configure`,
> unfortunately.
>
> >> this configuration mechanism isn't atomic, and
> >> there's some possible race condition for related attributes to have
> >> inconsistent values seen from another thread while the configuration is
> >> being changed.
> >
> > This isn't a new problem, right?
>
> It _would_ be a new problem if you refactored an existing
> configuration form to use the recommended idioms and thereby
> introduced the race condition.
>
> > When this matters some use of
> > 'synchronized' statement is in order anyway.
>
> Would not help. You can synchronize `configure(StaplerRequest,
> JSONObject)` so that the nulling out of all properties followed by the
> setting of most properties is atomic. But that will not protect
> individual `@DataBoundSetter` calls from the proposed C-a-C plugin. We
> would need to introduce a scripting-friendly API for configuring an
> arbitrary object (create new `Describable` or modify existing
> `Descriptor` or `ReconfigurableDescribable`), but without any tie to
> Stapler or web forms, along the lines of
>
> http://javadoc.jenkins.io/workflow-step-api/org/
> jenkinsci/plugins/workflow/steps/StepDescriptor.html#
> newInstance-java.util.Map-
>
> This could live in `structs` though we would then have a problem with
> any affected settings defined in `jenkins-core`.
>
> The more straightforward workaround for such cases is the use of an
> explicit object representing a zero choice, as I mentioned previously.
> This does have an effect on the UI, at least using the currently
> available controls (which would only support a dropdown or a radio
> button list, not a checkbox).
>
> --
> 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/CANfRfr0fLxzZ_4JtTsedFY_-22wdLCJGBuR1e%3DOcKCdD9Zrz%
> 3DA%40mail.gmail.com.
> 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/CANMVJzn0g2StRCR%2B5Q5Vb_ikORphSmM8Xzu%2B-%3DCf6L-5oXxohA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Install plugin from command line

[Jesse Glick]

On Wed, Nov 15, 2017 at 4:15 AM,   wrote:
> Looking at the code I noticed that the plugin uses this two dependencies,
> but they are not specified in the pom file.

They are inherited from a parent, along with much else.

> Is it possible to generate the
> hpi file

Sure, like any other plugin, or indeed Maven-based project:

mvn -DskipTests clean package

-- 
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/CANfRfr18HZVGYvhmw3UtBth5ELgYUBaRqTboLggTwawYGPq_Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[Jesse Glick]

On Tue, Nov 14, 2017 at 10:19 PM, Kohsuke Kawaguchi  wrote:
> I suppose we could create a variant of req.bindJSON(this,json) that does set
> null on proeprties that are not specified in JSON.

Yes, that would be a helpful convenience API, and it would make sense
to call it in a newly introduced default implementation for
`Descriptor.configure`. For compatibility reasons we could probably
not change the implementation of `GlobalConfiguration.configure`,
unfortunately.

>> this configuration mechanism isn't atomic, and
>> there's some possible race condition for related attributes to have
>> inconsistent values seen from another thread while the configuration is
>> being changed.
>
> This isn't a new problem, right?

It _would_ be a new problem if you refactored an existing
configuration form to use the recommended idioms and thereby
introduced the race condition.

> When this matters some use of
> 'synchronized' statement is in order anyway.

Would not help. You can synchronize `configure(StaplerRequest,
JSONObject)` so that the nulling out of all properties followed by the
setting of most properties is atomic. But that will not protect
individual `@DataBoundSetter` calls from the proposed C-a-C plugin. We
would need to introduce a scripting-friendly API for configuring an
arbitrary object (create new `Describable` or modify existing
`Descriptor` or `ReconfigurableDescribable`), but without any tie to
Stapler or web forms, along the lines of

http://javadoc.jenkins.io/workflow-step-api/org/jenkinsci/plugins/workflow/steps/StepDescriptor.html#newInstance-java.util.Map-

This could live in `structs` though we would then have a problem with
any affected settings defined in `jenkins-core`.

The more straightforward workaround for such cases is the use of an
explicit object representing a zero choice, as I mentioned previously.
This does have an effect on the UI, at least using the currently
available controls (which would only support a dropdown or a radio
button list, not a checkbox).

-- 
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/CANfRfr0fLxzZ_4JtTsedFY_-22wdLCJGBuR1e%3DOcKCdD9Zrz%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Install plugin from command line

[mmicu0]

Hello. I reported this issue here like suggested here 
. I'm trying to use the 
"Durable Task Plugin" (link 
) with some 
personal updates. For this reason I got the version 1.14 and I tried to 
generate the hpi file through the command "mvn install". However, I 
obtained this errors:

java.nio.file.NoSuchFileException: MYPATH\target\classes\META-INF\
annotations\org.kohsuke.accmod.Restricted
java.nio.file.NoSuchFileException: MYPATH\target\classes\META-INF\
annotations\hudson.Extension

Looking at the code I noticed that the plugin uses this two dependencies, 
but they are not specified in the pom file. Is it possible to generate the 
hpi file or is it impossible with this configuration?

-- 
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/16957459-1c04-4fc2-9be4-1472c1fbb973%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Credentials Plugin 2.2.0 to require Jenkins 2.60.1+

[Stephen Connolly]

>From http://stats.jenkins.io/pluginversions/credentials.html

28% of people have upgraded credentials to 2.1.16

91% of installations of credentials 2.1.16 are using Jenkins 2.60.1 or newer

It is 2 months since the 2.1.16 release of the credentials plugin. The 72%
of people who have not upgraded to credentials 2.1.16 are more than likely
not feeling the need to upgrade, the plugin works well enough for them.
Consequently, I shall exclude them from my decision on what the baseline
Jenkins requirements are for the next release of the plugin... just because
I release a newer version, does not mean they need to upgrade... as
evidenced by their not upgrading ;-)

My (previously undocumented) 90% threshold has been passed with Jenkins
2.60.1, consequently the Credentials plugin is moving its baseline to 2.60.1

*This is not a debate*, *as maintainer of the plugin I have made the
decision*. If somebody wants to maintain a 2.1.x line and take the work of
back-porting any fixes, I will consider supporting them in that task, but
the time I have will be focused on the 2.2.x line.

Some of the improvements to the credentials API that I want to make require
features of Java 8, hence given that the 90% threshold has been passed, I
am pulling the trigger.

The reason I am sending this announcement is to alert all downstream plugin
developers.

If (after I cut a 2.2.x release) you update your dependency on Credentials
API to 2.2.0 or newer, you will also be moving your Jenkins baseline to
2.60.1+ and your Java baseline version to 8. Please assess the impact to
your users.

An example,
  git, the version that is at least two months old is 3.5.1, the 90%
installation cut-off for git is Jenkins 2.46.1 thus according to my
completely made up decision point (plugin release must be available for at
least 2 months, 90% of users with the plugin installed must be using that
Jenkins version or newer) I would not update the git plugin past Jenkins
2.46.1 just yet... however the month and a half 3.6.0 does currently have
92% of users with Jenkins 2.60.1, so using my measure and assuming that the
december stats follow trend, I would think the git plugin could bump
Jenkins baseline in December... and consequently bump Credentials API
version too...

NOTE: I only co-maintain the git plugin and Mark is probably the decider on
the policy to follow with the git plugin.

I recommend that every plugin developer define their compatibility policy
on their wiki page. I have added my policy for the credentials plugin to
its wiki page:

At least 90% of installations using the most recent version of the plugin
that is at least 2 months old shall be able to upgrade to the latest
version of the plugin.


As a plugin maintainer, the policy you pick is entirely your choice, but I
strongly recommend picking a policy and documenting it as I have done (and
I will be applying the same/similar policy to the other plugins I maintain)

P.S. it may be some time before I cut a 2.2.0 release of credentials... or
it could be quite soon... I have made the decision and I think it fair to
provide warning as early as possible

-Stephen

-- 
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/CA%2BnPnMxcjeMBNiUFkf3J6oqCEQitgo6TaZNc%3DD2kjM3MsAH%3DGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Adopt a plugin] AWS Cloudformation Plugin

[laszlo]

Hey folks,

how did this pan out?

As far as I see it's still Nathan that's the official maintainer on the 
wiki.

Eventually I can also help maintaining this plugin.

Best regards,
Laszlo


On Friday, July 28, 2017 at 11:29:17 PM UTC+2, Daniel Beck wrote:
>
>
> > On 28. Jul 2017, at 22:25, Robert Burden  > wrote: 
> > 
> > I would like to be made maintainer of the AWS Cloud formation Plugin. 
> > 
> > As per the instructions (
> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin) I have reached 
> out to the current maintainer (Nathan Good) and he said he is ok with it 
> (See attached email). 
> > 
> > My Jenkins ID and my GitHub id are both: Burden50 
> > 
> > Please let me know if you require any further information. 
>
> I made you a committer (possibly pending invitation to the jenkinsci org) 
> and the default assignee in Jira. 
>
> Welcome aboard! 
>
> Remember to remove the adopt-this-plugin label from the wiki page if you 
> haven't already. 
>
> If you're planning major refactorings, consider opening a PR and pinging 
> @jenkinsci/code-reviewers to get some assistance. 
>
>

-- 
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/04129e6b-0fb8-4ec1-89b3-4a15ff027b96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Dynamically populate drop down in builder interface

['Marco Brondani' via Jenkins Developers]

Hello All,
I have tried and followed the suggestion from Stephen.
Everything works well when I implement the doFill__Items from the Builder 
Descriptor.
I have however problems to retrieve the credentials when doing it from within 
an Action Descriptor.

In my builder I have:






 Action








And in the doFillTestIdItems() make a request to the API with the data in 
credentials.


public ListBoxModel doFillTestIdItems(Build context, @QueryParameter 
String credentialsId) {

final CredentialImpl credential = 
CredentialsProvider.findCredentialById(credentialsId,
CredentialImpl.class, context, 
URIRequirementBuilder.create().build());

HandleAPI handleAPI = new HandleAPI(credential.getTeamSlug(), 
credential.getKeyId());
this.suitesResponse = (SuitesResponse)(handleAPI.callSuitesAPI());
ListBoxModel items = this.getListOfSuitesFromResponse(this.suitesResponse);

return items;
}

However this returns a java.lang.NullPointerException

Any help?
Anyone could point me to an example on GitHub that’s implemented similarly?

Thank you very much,
M.-


From: jenkinsci-dev@googlegroups.com  on behalf 
of Stephen Connolly 
Sent: Sunday, October 29, 2017 8:52:15 AM
To: jenkinsci-dev@googlegroups.com
Subject: Re: Dynamically populate drop down in builder interface


On Sun 29 Oct 2017 at 06:43, 'Marco Brondani' via Jenkins Developers 
> wrote:
Hello,
I have a plug-in that uses Jenkins credentials to store API key and details 
necessary to make requests when the plug in runs.
However, to improve the Builder interface, I'd like to use the credentials to 
make a request to the API and automatically populate the drop down in the 
builder itself.
How can I do that?

The credentials are not accessible in the jelly so I can't just set a js script 
to make the Ajax.

Any help would be greatly helpful.

It’s a fairly standard pattern, you just have the doFill___Items method in the 
DescriptorImpl reference the required fields with @QueryParam

Eg see doFillRepositoryItems in 
https://github.com/jenkinsci/gitea-plugin/blob/master/src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMSource.java



Thank you,
Marco

--
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/HE1P195MB018878B3F690F248A739D586F5580%40HE1P195MB0188.EURP195.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
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/CA%2BnPnMywMueDt_JJ9YBnobRG433MTmh5oKAmSi_oghVQ0RD_Fw%40mail.gmail.com.
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/DB6PR04MB30628CCC4FA3BA60C2458BFCF5290%40DB6PR04MB3062.eurprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.