Re: New plugin

[DuMaM]

Thanks for all those suggestions. I will apply them and will return to you 
for further guidance. 

piątek, 22 marca 2024 o 11:53:49 UTC+1 db...@cloudbees.com napisał(a):

> On Fri, Mar 22, 2024 at 11:12 AM DuMaM  wrote:
>
>> My work environment requires from me to give users privileges to create 
>> new jobs, but I need to lock creation of non pipeline jobs.
>> I could take a solution proposed a long time ago by Daniel Beck, but I 
>> fought that maybe it's a good place for a more universal plugin for that 
>> purpose, so I tweaked his code a bit.
>>
>
> Please note that this doesn't actually do what you seem to claim it does. 
> It _hides_ the job type from the job creation form, but CLI, remote API, 
> etc. still allow job creation. See e.g. 
> https://issues.jenkins.io/browse/JENKINS-52728?focusedId=344840=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-344840
>  
> in which I point out this limitation (and suggest ExtensionFilter as 
> alternative). If I claimed somewhere that hide-maven actually prevents job 
> creation, I apologize for the mistake.
>

-- 
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/e4c0b320-bdcb-431b-b715-8d0d7a861d35n%40googlegroups.com.

Re: New plugin

['Daniel Beck' via Jenkins Developers]

On Fri, Mar 22, 2024 at 11:12 AM DuMaM  wrote:

> My work environment requires from me to give users privileges to create
> new jobs, but I need to lock creation of non pipeline jobs.
> I could take a solution proposed a long time ago by Daniel Beck, but I
> fought that maybe it's a good place for a more universal plugin for that
> purpose, so I tweaked his code a bit.
>

Please note that this doesn't actually do what you seem to claim it does.
It _hides_ the job type from the job creation form, but CLI, remote API,
etc. still allow job creation. See e.g.
https://issues.jenkins.io/browse/JENKINS-52728?focusedId=344840=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-344840
in which I point out this limitation (and suggest ExtensionFilter as
alternative). If I claimed somewhere that hide-maven actually prevents job
creation, I apologize for the mistake.

-- 
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/CAMo7PtJ3ggDSMoCp9KTHjFZzDA2F0%3DJmPKA3vGP5bn%3DrwKt-0w%40mail.gmail.com.

RE: New plugin

['Winter, Markus' via Jenkins Developers]

Your problem with the restart is because you configure it in the constructor. 
But this is an Extension which is only created once at startup and not every 
time a check is performed.
So you will need to fill the projectTypes list in the filter method (and don't 
make it a class field).
You might also consider of storing the list in LockProject class (as transient 
field) and just use it in the filter. In LockProject you need a to fill the 
list in the configure method and you need to ensure it is filled when loaded 
(overwrite load method probably).


From: jenkinsci-dev@googlegroups.com  On Behalf 
Of DuMaM
Sent: Freitag, 22. März 2024 11:12
To: Jenkins Developers 
Subject: New plugin

You don't often get email from 
nowak.bartos...@gmail.com<mailto:nowak.bartos...@gmail.com>. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Hi,

I'm looking for some answers to questions which pop out during plugin 
development.
https://github.com/DuMaM/lock-project-plugin

My work environment requires from me to give users privileges to create new 
jobs, but I need to lock creation of non pipeline jobs.
I could take a solution proposed a long time ago by Daniel Beck, but I fought 
that maybe it's a good place for a more universal plugin for that purpose, so I 
tweaked his code a bit.

Now i have a functional plugin which can block creation of any job type. It 
still requires some work but i kind of suck on one issue.

I don't understand why it always requires a restart to apply changes from 
system config.
Could somebody step in and help me here?

I'm also seeking information about:
* ways of testing Jenkins plugins - I wasn't able to find a detailed 
documentation
* process how i can introduce it to jenkinsci org

Thanks
--
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/61bdadc2-c276-4a72-a0a0-d4017bbdc023n%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-dev/61bdadc2-c276-4a72-a0a0-d4017bbdc023n%40googlegroups.com?utm_medium=email_source=footer>.

-- 
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/AS1PR02MB78470BDE491EABA79178CEC787312%40AS1PR02MB7847.eurprd02.prod.outlook.com.

New plugin

[DuMaM]

Hi,

I'm looking for some answers to questions which pop out during plugin 
development.
https://github.com/DuMaM/lock-project-plugin

My work environment requires from me to give users privileges to create new 
jobs, but I need to lock creation of non pipeline jobs.
I could take a solution proposed a long time ago by Daniel Beck, but I 
fought that maybe it's a good place for a more universal plugin for that 
purpose, so I tweaked his code a bit.

Now i have a functional plugin which can block creation of any job type. It 
still requires some work but i kind of suck on one issue.

I don't understand why it always requires a restart to apply changes from 
system config.
Could somebody step in and help me here?

I'm also seeking information about:
* ways of testing Jenkins plugins — I wasn't able to find a detailed 
documentation
* process how i can introduce it to jenkinsci org

Thanks

-- 
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/61bdadc2-c276-4a72-a0a0-d4017bbdc023n%40googlegroups.com.

Re: Error in Javadoc when attempting to publish a new plugin version

[Stéphane BOBIN]

Hi Basil!

Great, thanks, I will try that 

-- Stéphane

Le mar. 5 mars 2024 à 18:09, Basil Crow  a écrit :

> You can reproduce locally by running mvn clean verify -Pjenkins-release
> and on CI by enabling incrementals
> .
> Be sure to use the same version of Java you intend to use when doing the
> release, as different Java versions produce different errors.
>
> --
> 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/CAFwNDjqEWaYB9Kb21Mkzr9VCW9H8v6%2BG%3Dr6_UpuaGg3PyTUTnA%40mail.gmail.com
> 
> .
>

-- 
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/CAMQQ2s%3Dz9Y2%2B8n7Dh32swKG6vpUQ53ZbCkWeaptJXW4nS1mReg%40mail.gmail.com.

Re: Error in Javadoc when attempting to publish a new plugin version

[Basil Crow]

You can reproduce locally by running mvn clean verify -Pjenkins-release and
on CI by enabling incrementals
. Be
sure to use the same version of Java you intend to use when doing the
release, as different Java versions produce different errors.

-- 
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/CAFwNDjqEWaYB9Kb21Mkzr9VCW9H8v6%2BG%3Dr6_UpuaGg3PyTUTnA%40mail.gmail.com.

Error in Javadoc when attempting to publish a new plugin version

[Stéphane BOBIN]

Hi all!

Sorry, it is probably a newbie question. I was just attempting to publish a 
new version of my plugin (mvn release:prepare release:perform) and I got 
plenty of errors in the Javadoc I recently added in my code. I didn't have 
these errors while building and testing (mvn clean install). 

   - How can I get the errors sooner in my workflow?
   - Can I run "mvn release:prepare" safely to get these errors before 
   without running remote stuff and getting into a wrong state?

Thanks for your help.

Stephane

-- 
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/6478e6ac-8e49-43fd-b12a-dd007dcb4c22n%40googlegroups.com.

Re: New plugin - Support for Azure credentials via the Kubernetes Credentials Provider

['Tue Dissing' via Jenkins Developers]

Perfect. Thanks. Request submitted: 
https://github.com/jenkins-infra/repository-permissions-updater/issues/3746

lørdag den 13. januar 2024 kl. 12.52.31 UTC+1 skrev jone...@gmail.com:

> Hi,
>
> You can follow 
> https://www.jenkins.io/doc/developer/publishing/requesting-hosting/ in 
> order to host your plugin
>
> Best way is to start with 
>
> mvn archetype:generate -B -DarchetypeGroupId=io.jenkins.archetypes 
> -DarchetypeArtifactId=empty-plugin -DhostOnJenkinsGitHub=true 
> -DarchetypeVersion=1.23 -DartifactId=
>
> And then implement the extension and tests. It will ensure you have all 
> the require files matching the archetype.
>
> If you follow correctly all steps, the plugin can be hosted and released 
> in matter of days on the plugin center.
>
> Regards,
>
> On Friday, January 12, 2024 at 4:52:40 PM UTC+1 tue.d...@ufst.dk wrote:
>
>> Hi Jenkins Dev,
>>
>>  
>>
>> We need to use Azure to provision build agents and therefore need to 
>> store the azure creds (service principal or a managed identity) as a 
>> jenkins credential. As we are deploying on Kubernetes we rely on the 
>> Kuberneters 
>> Credentials Provider plugin 
>> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin> 
>> for all our credentials.
>>
>> This plugin does not currently support the azure credentials types.
>>
>>  
>>
>> I have created this PR 
>> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94>
>>  
>> in order to support both the service principal and the managed identity, 
>> but as indicated here 
>> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94#issuecomment-1867550472>,
>>  
>> this is best supported by a separate plugin.
>>
>>  
>>
>> Can’t find any existing support for this. I therefore believe the best 
>> way forward are to implement a new plugin to handle this – just as is the 
>> case with for example 
>> https://plugins.jenkins.io/bitbucket-kubernetes-credentials/. Please let 
>> me know if there’s another way that is preferred.
>>
>>  
>>
>> Suggested name: azure-kubernetes-credentials-plugin.
>>
>>  
>>
>>  
>>
>> Venlig hilsen
>>
>>  
>>
>> *Tue Sørensen Dissing*
>>
>> Chefkonsulent
>>
>> DevOps
>>
>>  
>>
>> +45 72 37 77 61 <+45%2072%2037%2077%2061>
>>
>> tue.d...@ufst.dk
>>
>>  
>>
>> [image: Udviklings- og Forenklingsstyrelsen] <http://www.ufst.dk>
>>
>>  
>>
>> Udviklings- og Forenklingsstyrelsen
>>
>> Osvald Helmuths Vej 4, 2000 Frederiksberg
>>
>> www.ufst.dk
>>
>>  
>>
>> Sådan behandler vi persondata <https://www.ufst.dk/privatlivspolitik/>
>>
>> Udviklings- og Forenklingsstyrelsen er en del af Skatteforvaltningen
>>
>>  
>>
>

-- 
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/41a8ad57-212c-420d-b944-b22e76f4fa63n%40googlegroups.com.

Re: New plugin - Support for Azure credentials via the Kubernetes Credentials Provider

[Valentin Delaye (jonesbusy)]

Hi,

You can follow 
https://www.jenkins.io/doc/developer/publishing/requesting-hosting/ in 
order to host your plugin

Best way is to start with 

mvn archetype:generate -B -DarchetypeGroupId=io.jenkins.archetypes 
-DarchetypeArtifactId=empty-plugin -DhostOnJenkinsGitHub=true 
-DarchetypeVersion=1.23 -DartifactId=

And then implement the extension and tests. It will ensure you have all the 
require files matching the archetype.

If you follow correctly all steps, the plugin can be hosted and released in 
matter of days on the plugin center.

Regards,

On Friday, January 12, 2024 at 4:52:40 PM UTC+1 tue.d...@ufst.dk wrote:

> Hi Jenkins Dev,
>
>  
>
> We need to use Azure to provision build agents and therefore need to store 
> the azure creds (service principal or a managed identity) as a jenkins 
> credential. As we are deploying on Kubernetes we rely on the Kuberneters 
> Credentials Provider plugin 
> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin> for 
> all our credentials.
>
> This plugin does not currently support the azure credentials types.
>
>  
>
> I have created this PR 
> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94> 
> in order to support both the service principal and the managed identity, 
> but as indicated here 
> <https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94#issuecomment-1867550472>,
>  
> this is best supported by a separate plugin.
>
>  
>
> Can’t find any existing support for this. I therefore believe the best way 
> forward are to implement a new plugin to handle this – just as is the case 
> with for example 
> https://plugins.jenkins.io/bitbucket-kubernetes-credentials/. Please let 
> me know if there’s another way that is preferred.
>
>  
>
> Suggested name: azure-kubernetes-credentials-plugin.
>
>  
>
>  
>
> Venlig hilsen
>
>  
>
> *Tue Sørensen Dissing*
>
> Chefkonsulent
>
> DevOps
>
>  
>
> +45 72 37 77 61 <+45%2072%2037%2077%2061>
>
> tue.d...@ufst.dk
>
>  
>
> [image: Udviklings- og Forenklingsstyrelsen] <http://www.ufst.dk>
>
>  
>
> Udviklings- og Forenklingsstyrelsen
>
> Osvald Helmuths Vej 4, 2000 Frederiksberg
>
> www.ufst.dk
>
>  
>
> Sådan behandler vi persondata <https://www.ufst.dk/privatlivspolitik/>
>
> Udviklings- og Forenklingsstyrelsen er en del af Skatteforvaltningen
>
>  
>

-- 
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/bcd6c4ad-4bf4-4ecc-af21-919c43e5de2fn%40googlegroups.com.

New plugin - Support for Azure credentials via the Kubernetes Credentials Provider

['Tue Sørensen Dissing' via Jenkins Developers]

Hi Jenkins Dev,

We need to use Azure to provision build agents and therefore need to store the 
azure creds (service principal or a managed identity) as a jenkins credential. 
As we are deploying on Kubernetes we rely on the Kuberneters Credentials 
Provider 
plugin<https://github.com/jenkinsci/kubernetes-credentials-provider-plugin> for 
all our credentials.
This plugin does not currently support the azure credentials types.

I have created this 
PR<https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94> 
in order to support both the service principal and the managed identity, but as 
indicated 
here<https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/94#issuecomment-1867550472>,
 this is best supported by a separate plugin.

Can't find any existing support for this. I therefore believe the best way 
forward are to implement a new plugin to handle this - just as is the case with 
for example https://plugins.jenkins.io/bitbucket-kubernetes-credentials/. 
Please let me know if there's another way that is preferred.

Suggested name: azure-kubernetes-credentials-plugin.


Venlig hilsen

Tue Sørensen Dissing
Chefkonsulent
DevOps

+45 72 37 77 61
tue.diss...@ufst.dk<mailto:tue.diss...@ufst.dk>

[Udviklings- og Forenklingsstyrelsen]

Udviklings- og Forenklingsstyrelsen
Osvald Helmuths Vej 4, 2000 Frederiksberg
www.ufst.dk

Sådan behandler vi persondata<https://www.ufst.dk/privatlivspolitik/>
Udviklings- og Forenklingsstyrelsen er en del af Skatteforvaltningen

-- 
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/AM0PR10MB3716C3E424C2B703AB4D3DF9E86F2%40AM0PR10MB3716.EURPRD10.PROD.OUTLOOK.COM.

Re: New Plugin version not updated on Jenkins IO Plugin page

['Ricardo DeLemos' via Jenkins Developers]

OK. Thanks!

On Thursday, July 13, 2023 at 12:07:48 AM UTC-4 Mark Waite wrote:

> On Wednesday, July 12, 2023 at 10:04:55 PM UTC-6 Ricardo DeLemos wrote:
>
> Yes. The 2 versions (1.2.0 and 1.2.1) showed up 15 minutes after I have 
> send you the previous email. It is all set now.
>
> Just for reference on the next update: the 1.2.0 version took over 6hr to 
> show up on https://plugins.jenkins.io/, while 1.2.1 showed up after 1 hr. 
> It is just the time that the batch process ran to update the wiki page (~ 6 
> hours)?
>
>
> No, that's just the "luck of the draw" for the times when the plugins site 
> is rebuilt.  I believe it is rebuilt approximately every 6 hours.
>  
>

-- 
*CONFIDENTIALITY NOTICE:* The information contained in this message may be 
privileged and/or confidential. It is the property of CrowdStrike.  If you 
are not the intended recipient, or responsible for delivering this message 
to the intended recipient, any review, forwarding, dissemination, 
distribution or copying of this communication or any attachment(s) is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately, and delete it and all attachments from your 
computer and network.

-- 
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/1e8fb9d0-2264-46ff-b546-804a55a165den%40googlegroups.com.

Re: New Plugin version not updated on Jenkins IO Plugin page

[Mark Waite]

On Wednesday, July 12, 2023 at 10:04:55 PM UTC-6 Ricardo DeLemos wrote:

Yes. The 2 versions (1.2.0 and 1.2.1) showed up 15 minutes after I have 
send you the previous email. It is all set now.

Just for reference on the next update: the 1.2.0 version took over 6hr to 
show up on https://plugins.jenkins.io/, while 1.2.1 showed up after 1 hr. 
It is just the time that the batch process ran to update the wiki page (~ 6 
hours)?


No, that's just the "luck of the draw" for the times when the plugins site 
is rebuilt.  I believe it is rebuilt approximately every 6 hours.
 

-- 
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/0199409d-3e9d-4966-afbe-6fdf6ece0ba1n%40googlegroups.com.

Re: New Plugin version not updated on Jenkins IO Plugin page

['Ricardo DeLemos' via Jenkins Developers]

Yes. The 2 versions (1.2.0 and 1.2.1) showed up 15 minutes after I have 
send you the previous email. It is all set now.

Just for reference on the next update: the 1.2.0 version took over 6hr to 
show up on https://plugins.jenkins.io/, while 1.2.1 showed up after 1 hr. 
It is just the time that the batch process ran to update the wiki page (~ 6 
hours)?

Thanks for your help!
-Ricardo

On Wednesday, July 12, 2023 at 11:56:59 PM UTC-4 Mark Waite wrote:

> On Wednesday, July 12, 2023 at 8:57:48 PM UTC-6 Ricardo DeLemos wrote:
>
> Hi Mark,
>
> I have created a new release (1.20) following your recommendation, but I 
> still do not see the new release in 
> https://plugins.jenkins.io/crowdstrike-security/releases/  
> . I have 
> created a version 1.2.0, which I see on 
> https://repo.jenkins-ci.org/releases/io/jenkins/plugins/crowdstrike-security/.
>  
> I *do not see* a 1.2.0-SNAPSHOT in 
> https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/crowdstrike-security/
> .
>
> I have tried again, creating a 1.2.1 release, and got the same result. 
> This was the versions set on the pom on the release 1.2.0
>
> 
> ...
> crowdstrike-security-1.2.0
> 
> 1.2.0
> 
> 
> 
> io.jenkins.tools.bom
> bom-2.332.x
> 1210.vcd41f6657f03
> pom
> import
> 
> 
> 
> 
> 1.0.0
> ...
> 
>
>
> I see https://plugins.jenkins.io/crowdstrike-security/ showing 3 
> releases, 1.0.0, 1.2.0, and 1.2.1.  I assume that means all is OK for you?
>
> Mark Waite
>

-- 
*CONFIDENTIALITY NOTICE:* The information contained in this message may be 
privileged and/or confidential. It is the property of CrowdStrike.  If you 
are not the intended recipient, or responsible for delivering this message 
to the intended recipient, any review, forwarding, dissemination, 
distribution or copying of this communication or any attachment(s) is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately, and delete it and all attachments from your 
computer and network.

-- 
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/43ce210f-8761-425f-abad-0169fee7faa3n%40googlegroups.com.

Re: New Plugin version not updated on Jenkins IO Plugin page

[Mark Waite]

On Wednesday, July 12, 2023 at 8:57:48 PM UTC-6 Ricardo DeLemos wrote:

Hi Mark,

I have created a new release (1.20) following your recommendation, but I 
still do not see the new release in 
https://plugins.jenkins.io/crowdstrike-security/releases/  
. I have created 
a version 1.2.0, which I see on 
https://repo.jenkins-ci.org/releases/io/jenkins/plugins/crowdstrike-security/. 
I *do not see* a 1.2.0-SNAPSHOT in 
https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/crowdstrike-security/
.

I have tried again, creating a 1.2.1 release, and got the same result. This 
was the versions set on the pom on the release 1.2.0


...
crowdstrike-security-1.2.0

1.2.0



io.jenkins.tools.bom
bom-2.332.x
1210.vcd41f6657f03
pom
import




1.0.0
...



I see https://plugins.jenkins.io/crowdstrike-security/ showing 3 releases, 
1.0.0, 1.2.0, and 1.2.1.  I assume that means all is OK for you?

Mark Waite

-- 
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/1bd99da4-d196-47cc-a127-26d2e6dbb45bn%40googlegroups.com.

Re: New Plugin version not updated on Jenkins IO Plugin page

['Ricardo DeLemos' via Jenkins Developers]

Hi Mark,

I have created a new release (1.20) following your recommendation, but I 
still do not see the new release in 
https://plugins.jenkins.io/crowdstrike-security/releases/  
. I have created 
a version 1.2.0, which I see on 
https://repo.jenkins-ci.org/releases/io/jenkins/plugins/crowdstrike-security/. 
I *do not see* a 1.2.0-SNAPSHOT in 
https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/crowdstrike-security/
.

I have tried again, creating a 1.2.1 release, and got the same result. This 
was the versions set on the pom on the release 1.2.0


...
crowdstrike-security-1.2.0

1.2.0



io.jenkins.tools.bom
bom-2.332.x
1210.vcd41f6657f03
pom
import




1.0.0
...


On Wednesday, July 12, 2023 at 12:17:07 AM UTC-4 Mark Waite wrote:

> The 1.1.0 release is not available on repo.jenkins-ci.org.  
> https://repo.jenkins-ci.org/artifactory/releases/io/jenkins/plugins/crowdstrike-security/
>  
> shows a 1.0.0 release that was delivered in 2022.  Since a tag has been 
> created in the repository, I recommend that you declare the 1.1.0 release 
> as "lost" and create a 1.2.0 release.
>
> You'll need to run the maven release process 
> , 
> though I believe you'll first need to make some changes to your pom file.  
> The version in the pom should be 1.2.0-SNAPSHOT rather than 1.1.0, then 
> when you run `mvn release:prepare release:perform` you'll choose the 
> release as 1.2.0.
>
> You can make your maintenance effort easier by modernizing the plugin by 
> following the steps in the "Improve a plugin" tutorial 
> .
>
> Mark Waite
>
> On Tuesday, July 11, 2023 at 10:08:20 PM UTC-6 Ricardo DeLemos wrote:
>
>> Hello,
>> I have released a new version of the plugin in GitHub (
>> https://github.com/jenkinsci/crowdstrike-security-plugin) and I can see 
>> the new release there, but after waiting more than 6hr, I could not see the 
>> new release version in 
>> https://plugins.jenkins.io/crowdstrike-security/releases/
>>
>> There was a error in the plugin version in the pom file, and that was 
>> corrected and the label moved to the correct commit, but there is no update 
>> on the plugin page.
>>
>> How can I force the plugin page to get updated with the new version?
>>
>> Thanks, 
>> Ricardo 
>>
>> --
>>
>> *CONFIDENTIALITY NOTICE:* The information contained in this message may be 
>> privileged and/or confidential. It is the property of CrowdStrike.  If you 
>> are not the intended recipient, or responsible for delivering this message 
>> to the intended recipient, any review, forwarding, dissemination, 
>> distribution or copying of this communication or any attachment(s) is 
>> strictly prohibited. If you have received this message in error, please 
>> notify the sender immediately, and delete it and all attachments from your 
>> computer and network.
>>
>>
-- 
*CONFIDENTIALITY NOTICE:* The information contained in this message may be 
privileged and/or confidential. It is the property of CrowdStrike.  If you 
are not the intended recipient, or responsible for delivering this message 
to the intended recipient, any review, forwarding, dissemination, 
distribution or copying of this communication or any attachment(s) is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately, and delete it and all attachments from your 
computer and network.

-- 
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/7f2de32a-7845-4c16-bf22-83002f825279n%40googlegroups.com.

Re: New Plugin version not updated on Jenkins IO Plugin page

[Mark Waite]

The 1.1.0 release is not available on 
repo.jenkins-ci.org.  
https://repo.jenkins-ci.org/artifactory/releases/io/jenkins/plugins/crowdstrike-security/
 
shows a 1.0.0 release that was delivered in 2022.  Since a tag has been 
created in the repository, I recommend that you declare the 1.1.0 release 
as "lost" and create a 1.2.0 release.

You'll need to run the maven release process 
, 
though I believe you'll first need to make some changes to your pom file.  
The version in the pom should be 1.2.0-SNAPSHOT rather than 1.1.0, then 
when you run `mvn release:prepare release:perform` you'll choose the 
release as 1.2.0.

You can make your maintenance effort easier by modernizing the plugin by 
following the steps in the "Improve a plugin" tutorial 
.

Mark Waite

On Tuesday, July 11, 2023 at 10:08:20 PM UTC-6 Ricardo DeLemos wrote:

> Hello,
> I have released a new version of the plugin in GitHub (
> https://github.com/jenkinsci/crowdstrike-security-plugin) and I can see 
> the new release there, but after waiting more than 6hr, I could not see the 
> new release version in 
> https://plugins.jenkins.io/crowdstrike-security/releases/
>
> There was a error in the plugin version in the pom file, and that was 
> corrected and the label moved to the correct commit, but there is no update 
> on the plugin page.
>
> How can I force the plugin page to get updated with the new version?
>
> Thanks, 
> Ricardo 
>
> --
>
> *CONFIDENTIALITY NOTICE:* The information contained in this message may be 
> privileged and/or confidential. It is the property of CrowdStrike.  If you 
> are not the intended recipient, or responsible for delivering this message to 
> the intended recipient, any review, forwarding, dissemination, distribution 
> or copying of this communication or any attachment(s) is strictly prohibited. 
> If you have received this message in error, please notify the sender 
> immediately, and delete it and all attachments from your computer and network.
>
>

-- 
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/423ac891-7c74-44c3-a290-a2daaa0121c2n%40googlegroups.com.

New Plugin version not updated on Jenkins IO Plugin page

['Ricardo DeLemos' via Jenkins Developers]

Hello,
I have released a new version of the plugin in GitHub 
(https://github.com/jenkinsci/crowdstrike-security-plugin) and I can see 
the new release there, but after waiting more than 6hr, I could not see the 
new release version 
in https://plugins.jenkins.io/crowdstrike-security/releases/

There was a error in the plugin version in the pom file, and that was 
corrected and the label moved to the correct commit, but there is no update 
on the plugin page.

How can I force the plugin page to get updated with the new version?

Thanks, 
Ricardo 

-- 
*CONFIDENTIALITY NOTICE:* The information contained in this message may be 
privileged and/or confidential. It is the property of CrowdStrike.  If you 
are not the intended recipient, or responsible for delivering this message 
to the intended recipient, any review, forwarding, dissemination, 
distribution or copying of this communication or any attachment(s) is 
strictly prohibited. If you have received this message in error, please 
notify the sender immediately, and delete it and all attachments from your 
computer and network.

-- 
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/0c1db780-17fc-42c3-a039-09b0eb971ee7n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexis Tual]

Thanks all for your answers, after discussing it internally at Gradle, we 
won't be able to implement all those new (for us) requirements and maintain 
them over time without help.


On Thursday, May 25, 2023 at 7:05:39 PM UTC+2 m...@basilcrow.com wrote:

> In addition to what Mark wrote, I would want to see some of our top
> open-source Gradle-based Jenkins plugins (e.g., Gradle, Terraform,
> Checkmarx, Jira Trigger, etc.) upgraded to use the latest
> gradle-jpi-plugin toolchain, a recent LTS release as the Jenkins core
> baseline, and a recent plugin Bill of Materials (BOM) and inspect the
> resulting JPI that is produced to ensure it is up to parity with a JPI
> produced with the maven-hpi-plugin toolchain (e.g., equivalent
> manifest entries, equivalent compiler options, etc). Right now, most
> of the abovementioned plugins are using an ancient Jenkins core
> baseline and an ancient plugin Bill of Materials (BOM), which does not
> speak to the viability of the gradle-jpi-plugin toolchain.
>
> In general the gradle-jpi-plugin toolchain needs to be at feature
> parity with the maven-hpi-plugin toolchain before we could accept new
> plugin hosting requests. That means, in addition to what Mark
> described, that every feature in jenkinsci/plugin-pom and
> jenkinsci/maven-hpi-plugin should have an equivalent in
> gradle-jpi-plugin, including Java 11/17 support for running unit
> tests, integration with the latest versions of JUnit/Mockito/Hamcrest
> out-of-the-box, opt-in code formatting using our project-wide Spotless
> configuration, equivalents to our Maven Enforcer rules, etc. Since I
> am constantly adding new features to plugin-pom/maven-hpi-plugin, this
> implies a commitment to proactively follow such development and
> sideport the same features to the gradle-jpi-plugin toolchain as they
> are introduced.
>

-- 
*
CONFIDENTIALITY NOTICE*: The contents of this email message, and any 
attachments, are intended solely for the addressee(s) and may contain 
confidential, proprietary and/or privileged information legally protected 
from disclosure. If you are not the intended recipient of this 
communication, or if you received this communication by mistake, please 
notify the sender immediately and delete this message and any attachments. 
If you are not the intended recipient, you are hereby notified that any 
use, retransmission, dissemination, copying or storage of this message or 
its attachments is strictly prohibited.

-- 
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/5cdc88ef-560c-4418-8e8c-746a8e12c54cn%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Basil Crow]

In addition to what Mark wrote, I would want to see some of our top
open-source Gradle-based Jenkins plugins (e.g., Gradle, Terraform,
Checkmarx, Jira Trigger, etc.) upgraded to use the latest
gradle-jpi-plugin toolchain, a recent LTS release as the Jenkins core
baseline, and a recent plugin Bill of Materials (BOM) and inspect the
resulting JPI that is produced to ensure it is up to parity with a JPI
produced with the maven-hpi-plugin toolchain (e.g., equivalent
manifest entries, equivalent compiler options, etc). Right now, most
of the abovementioned plugins are using an ancient Jenkins core
baseline and an ancient plugin Bill of Materials (BOM), which does not
speak to the viability of the gradle-jpi-plugin toolchain.

In general the gradle-jpi-plugin toolchain needs to be at feature
parity with the maven-hpi-plugin toolchain before we could accept new
plugin hosting requests. That means, in addition to what Mark
described, that every feature in jenkinsci/plugin-pom and
jenkinsci/maven-hpi-plugin should have an equivalent in
gradle-jpi-plugin, including Java 11/17 support for running unit
tests, integration with the latest versions of JUnit/Mockito/Hamcrest
out-of-the-box, opt-in code formatting using our project-wide Spotless
configuration, equivalents to our Maven Enforcer rules, etc. Since I
am constantly adding new features to plugin-pom/maven-hpi-plugin, this
implies a commitment to proactively follow such development and
sideport the same features to the gradle-jpi-plugin toolchain as they
are introduced.

-- 
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/CAFwNDjqW5tWqrOGTzmLc5641Q%2BCm19-xzzrzB13K09j5rtzkJA%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Mark Waite]

On Thursday, May 25, 2023 at 9:07:41 AM UTC-6 at...@gradle.com wrote:

Thanks for the quick answer!

On Thursday, May 25, 2023 at 3:16:30 PM UTC+2 Mark Waite wrote:

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

Sure, I can start a dedicated page with what we have and enrich later (see 
below)
 


I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

My understanding of 
https://www.jenkins.io/doc/developer/publishing/releasing-cd/ is that this 
step will just set the Maven repository credentials as secrets on the 
relevant Github repository.
The actual continuous release will happen only if using 
https://raw.githubusercontent.com/jenkinsci/.github/master/workflow-templates/cd.yaml,
 
or am I missing something ? People maybe just have their own workflow using 
credentials to publish ?
 


I can't explain why that query does not accurately show the contents of the 
jenkinsci repositories, but I'm confident that it does not.  I see over 200 
references to maven-cd.yml in files that are named either cd.yml or cd.yaml 
in the .github/workflows directories of repositories in the jenkinsci 
GitHub organization.
 


I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

Currently the Github action uses Maven to rebuild and publish 
https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh#L8
.
We could either provide a similar Github action, or simply a template and 
some docs on how to use it, but first I'd like to make sure it's used.

Getting a step back, I'd be curious to know why it requires rebuilding 
since it's supposed to be built already on ci.jenkins.io and published to 
the incrementals repository. The automatic releasing would just consist in 
promoting from the incrementals repository to the release repository in 
Artifactory.


The ci.jenkins.io machine is intentionally not considered "trusted".  We 
don't place credentials on ci.jenkins.io
 

 
Thanks!

-- 
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/559cbeef-e675-4779-ac7c-f1a407d2d874n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexis Tual]

Thanks for the quick answer!

On Thursday, May 25, 2023 at 3:16:30 PM UTC+2 Mark Waite wrote:

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

Sure, I can start a dedicated page with what we have and enrich later (see 
below)
 


I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

My understanding of 
https://www.jenkins.io/doc/developer/publishing/releasing-cd/ is that this 
step will just set the Maven repository credentials as secrets on the 
relevant Github repository.
The actual continuous release will happen only if using 
https://raw.githubusercontent.com/jenkinsci/.github/master/workflow-templates/cd.yaml,
 
or am I missing something ? People maybe just have their own workflow using 
credentials to publish ?
 


I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

Currently the Github action uses Maven to rebuild and publish 
https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh#L8.
We could either provide a similar Github action, or simply a template and 
some docs on how to use it, but first I'd like to make sure it's used.

Getting a step back, I'd be curious to know why it requires rebuilding 
since it's supposed to be built already on ci.jenkins.io and published to 
the incrementals repository. The automatic releasing would just consist in 
promoting from the incrementals repository to the release repository in 
Artifactory.
 
Thanks!

-- 
*
CONFIDENTIALITY NOTICE*: The contents of this email message, and any 
attachments, are intended solely for the addressee(s) and may contain 
confidential, proprietary and/or privileged information legally protected 
from disclosure. If you are not the intended recipient of this 
communication, or if you received this communication by mistake, please 
notify the sender immediately and delete this message and any attachments. 
If you are not the intended recipient, you are hereby notified that any 
use, retransmission, dissemination, copying or storage of this message or 
its attachments is strictly prohibited.

-- 
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/e0d43946-98bb-4ec0-bab5-cfae4283cfa8n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Mark Waite]

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

-- 
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/b2c3fcc5-2518-41c1-9153-290e31cc29ccn%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexis Tual]

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details
The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library 
(https://github.com/jenkins-infra/pipeline-library/pull/654 and 
https://github.com/jenkins-infra/pipeline-library/pull/652) enable quality 
checks and incremental builds on ci.jenkins.io. Where can we document this 
and would it be ok to re-enable Gradle support ?
One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?
Thanks!


On Tuesday, March 28, 2023 at 10:12:12 PM UTC+2 m...@basilcrow.com wrote:

> On Mon, Mar 27, 2023 at 7:27 AM 'Herve Le Meur' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
> > For those using buildPluginWithGradle() from the shared pipeline 
> library, we could add a note about it in the logs.
>
> This was done in jenkins-infra/pipeline-library#629 
> .
>

-- 
*
CONFIDENTIALITY NOTICE*: The contents of this email message, and any 
attachments, are intended solely for the addressee(s) and may contain 
confidential, proprietary and/or privileged information legally protected 
from disclosure. If you are not the intended recipient of this 
communication, or if you received this communication by mistake, please 
notify the sender immediately and delete this message and any attachments. 
If you are not the intended recipient, you are hereby notified that any 
use, retransmission, dissemination, copying or storage of this message or 
its attachments is strictly prohibited.

-- 
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/f8a5a9c1-8b7a-4d86-bca7-462959aa1f46n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Basil Crow]

On Mon, Mar 27, 2023 at 7:27 AM 'Herve Le Meur' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:
> For those using buildPluginWithGradle() from the shared pipeline library,
we could add a note about it in the logs.

This was done in jenkins-infra/pipeline-library#629
.

-- 
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/CAFwNDjqOfVGV13p0HKr6GqHFEU7zv4-CHuAftFS2ap%2BK5XoYig%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['Herve Le Meur' via Jenkins Developers]

For those using buildPluginWithGradle() from the shared pipeline library,
we could add a note about it in the logs.

On Wed, Mar 22, 2023 at 6:38 PM Basil Crow  wrote:

> Here are the most popular plugins still using Gradle for their build:
>
> gradle 232,746
> multiple-scms 22,241
> allure-jenkins-plugin 17,121
> terraform 5,046
> checkmarx 4,502
> jira-trigger 3,996
> blackduck-detect 2,838
> npm-yarn-wrapper-steps 2,152
> ez-templates 2,145
> templating-engine 1,742
> synopsys-coverity 1,480
>
> Multiple SCMs is already deprecated. Gradle, Allure, Checkmarx, and
> the Synopsys plugins appear to be maintained by corporate teams that
> may have their own build system policies. Terraform, Jira Trigger, NPM
> and Yarn Wrapper and Steps, EZ Templates, and Templating Engine appear
> to be community-maintained.
>
> I wonder if there is a way we could more clearly communicate to the
> above parties that we offer only partial support for Gradle and full
> support only for Maven.
>
> --
> 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/CAFwNDjoXcdRte%3DXuUwp9XbTcFte_kiT4-CBqXqvgJzzRU98LcQ%40mail.gmail.com
> .
>

-- 
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/CAL-LwjwAPHyt62E5YxZBt-7ySEVZSpiPb0BeUB1fXF2BxbmX4A%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Basil Crow]

Here are the most popular plugins still using Gradle for their build:

gradle 232,746
multiple-scms 22,241
allure-jenkins-plugin 17,121
terraform 5,046
checkmarx 4,502
jira-trigger 3,996
blackduck-detect 2,838
npm-yarn-wrapper-steps 2,152
ez-templates 2,145
templating-engine 1,742
synopsys-coverity 1,480

Multiple SCMs is already deprecated. Gradle, Allure, Checkmarx, and
the Synopsys plugins appear to be maintained by corporate teams that
may have their own build system policies. Terraform, Jira Trigger, NPM
and Yarn Wrapper and Steps, EZ Templates, and Templating Engine appear
to be community-maintained.

I wonder if there is a way we could more clearly communicate to the
above parties that we offer only partial support for Gradle and full
support only for Maven.

-- 
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/CAFwNDjoXcdRte%3DXuUwp9XbTcFte_kiT4-CBqXqvgJzzRU98LcQ%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['Daniel Beck' via Jenkins Developers]

On Fri, Dec 16, 2022 at 7:43 PM sghil...@gmail.com 
wrote:

> > Last I checked, generated poms were also invalid, which is a problem for
> any consumers of these artifacts that do more than just download the hpi.
>
> I believe this was fixed in 2019 as v0.31.0
> .
>

Great, thanks for the correction. Seems "last I checked" was quite a while
ago :)

-- 
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/CAMo7PtL4o7HbOOoVnrd3x2qRRm6YExfwE9z7qL4Sgdyfr_tuwg%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[sghil...@gmail.com]

Hi all,

I've been maintaining the gradle-jpi-plugin for the last several years. I'm 
in support of this decision. My most recent OSS plugin used maven as well 
to take advantage of the excellent tooling the community has put together.

I elaborated a bit more on the mentioned issues in the repository 
,
 
but wanted to share here as well.

My main goal for maintaining this plugin is compatibility with new Gradle 
versions for the internal plugins I manage. Most of the evolution over the 
past several years have been in support of this. For example, there are now 
more than 400 acceptance tests that are easily run against arbitrary 
versions of Gradle (including pre-releases) and Java.

I think feature parity with maven-hpi-plugin is achievable and would unlock 
some productivity gains, but I don't have the bandwidth or the need for 
this myself. I would be supportive of anyone who wanted to take that on.

> Last I checked, generated poms were also invalid, which is a problem for 
any consumers of these artifacts that do more than just download the hpi.

I believe this was fixed in 2019 as v0.31.0 
.

Best,
Steve
On Friday, December 16, 2022 at 1:37:34 AM UTC-8 mc.ca...@gmail.com wrote:

> I submitted a dedicated issue 
>  on the 
> plugin's repository outlining the TODOs and linking to this discussion.
>
> On Thursday, 8 December 2022 at 21:53:36 UTC+1 db...@cloudbees.com wrote:
>
>> On Wed, Dec 7, 2022 at 11:20 AM Alexander Brandes  
>> wrote:
>>
>>> There's no support for automated releases (CD, JEP-229), missing 
>>> metadata for the plugin page and a few other limitations, which don't make 
>>> it a great experience using it.
>>>
>> …
>>>
>> I would be ready to lift this restriction again if the JPI plugin 
>>> developers provide the same scope of tools like we have for Maven.
>>>
>>
>> Is the maintainer of Gradle JPI Plugin aware of these requirements and/or 
>> this discussion? I don't see him in cc.
>>
>

-- 
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/373899d7-a696-4748-a0c7-fcefccfe42een%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexander Brandes]

I submitted a dedicated issue 
 on the plugin's 
repository outlining the TODOs and linking to this discussion.

On Thursday, 8 December 2022 at 21:53:36 UTC+1 db...@cloudbees.com wrote:

> On Wed, Dec 7, 2022 at 11:20 AM Alexander Brandes  
> wrote:
>
>> There's no support for automated releases (CD, JEP-229), missing metadata 
>> for the plugin page and a few other limitations, which don't make it a 
>> great experience using it.
>>
> …
>>
> I would be ready to lift this restriction again if the JPI plugin 
>> developers provide the same scope of tools like we have for Maven.
>>
>
> Is the maintainer of Gradle JPI Plugin aware of these requirements and/or 
> this discussion? I don't see him in cc.
>

-- 
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/325e27f3-adca-4e0c-9d8a-7ea515b5f063n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['Daniel Beck' via Jenkins Developers]

On Wed, Dec 7, 2022 at 11:20 AM Alexander Brandes 
wrote:

> There's no support for automated releases (CD, JEP-229), missing metadata
> for the plugin page and a few other limitations, which don't make it a
> great experience using it.
> …
> I would be ready to lift this restriction again if the JPI plugin
> developers provide the same scope of tools like we have for Maven.
>

Is the maintainer of Gradle JPI Plugin aware of these requirements and/or
this discussion? I don't see him in cc.

-- 
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/CAMo7Pt%2BkEXs0CQ054sugWZaDU-7kmsCsTwPkps_vMQOfi%3D21AQ%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['wfoll...@cloudbees.com' via Jenkins Developers]

+1

On Thursday, December 8, 2022 at 8:27:13 AM UTC-8 Adrien Lecharpentier 
wrote:

> +1 as well from me.
>
> Le jeu. 8 déc. 2022 à 17:19, Damien Duportal  a 
> écrit :
>
>> +1
>>
>> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
>>
>>> +1.
>>>
>>> At least such a move will make it very explicit for any new plugin that 
>>> only Maven really has /production/ support for Jenkins plugin dev.
>>>
>>> I think that we should still "allow" new plugins to use Gradle if they 
>>> wish so. But then they'll be very well aware that they got to be ready for 
>>> a lot of pain and much meta-work around the tooling itself for developing 
>>> their plugins.
>>> Which right now might be overlooked by new developers joining the 
>>> community and thinking that choosing one or another is simply a matter of 
>>> taste and habits.
>>>
>>> Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :
>>>
>>>> +1
>>>>
>>>> On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes  
>>>> wrote:
>>>> >
>>>> > Hey everyone,
>>>> >
>>>> > the Gradle JPI plugin lacks fundamental support of the jenkins.io 
>>>> infrastructure.
>>>> > There's no support for automated releases (CD, JEP-229), missing 
>>>> metadata for the plugin page and a few other limitations, which don't make 
>>>> it a great experience using it.
>>>> >
>>>> > Additionally, worth to note, the components mentioned above aren't 
>>>> new. People are proactively switching away from Gradle to Maven for better 
>>>> support and acceptance of our tooling, see ivy-plugin/49 for example.
>>>> >
>>>> > For the reasons stated, I would like to propose, that new plugin 
>>>> hosting requests use Maven, to have better toolchain support.
>>>> > I would be ready to lift this restriction again if the JPI plugin 
>>>> developers provide the same scope of tools like we have for Maven.
>>>> >
>>>> > Best,
>>>> > Alexander Brandes, for the hosting team
>>>> >
>>>> > --
>>>> > 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-de...@googlegroups.com.
>>>> > To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com
>>>> .
>>>>
>>>> -- 
>>>> 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-de...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com
>>>> .
>>>>
>>> -- 
>> 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-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/d1c3337b-075d-4978-8baa-78ef4d5a18d2n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Adrien Lecharpentier]

+1 as well from me.

Le jeu. 8 déc. 2022 à 17:19, Damien Duportal  a
écrit :

> +1
>
> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
>
>> +1.
>>
>> At least such a move will make it very explicit for any new plugin that
>> only Maven really has /production/ support for Jenkins plugin dev.
>>
>> I think that we should still "allow" new plugins to use Gradle if they
>> wish so. But then they'll be very well aware that they got to be ready for
>> a lot of pain and much meta-work around the tooling itself for developing
>> their plugins.
>> Which right now might be overlooked by new developers joining the
>> community and thinking that choosing one or another is simply a matter of
>> taste and habits.
>>
>> Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :
>>
>>> +1
>>>
>>> On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes 
>>> wrote:
>>> >
>>> > Hey everyone,
>>> >
>>> > the Gradle JPI plugin lacks fundamental support of the jenkins.io
>>> infrastructure.
>>> > There's no support for automated releases (CD, JEP-229), missing
>>> metadata for the plugin page and a few other limitations, which don't make
>>> it a great experience using it.
>>> >
>>> > Additionally, worth to note, the components mentioned above aren't
>>> new. People are proactively switching away from Gradle to Maven for better
>>> support and acceptance of our tooling, see ivy-plugin/49 for example.
>>> >
>>> > For the reasons stated, I would like to propose, that new plugin
>>> hosting requests use Maven, to have better toolchain support.
>>> > I would be ready to lift this restriction again if the JPI plugin
>>> developers provide the same scope of tools like we have for Maven.
>>> >
>>> > Best,
>>> > Alexander Brandes, for the hosting team
>>> >
>>> > --
>>> > 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-de...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com
>>> .
>>>
>>> --
>>> 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-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com
>>> .
>>>
>> --
> 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/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAKwJSvwL_u384_cXKACe_kcuOQ%2Ba%2BgSxHCqcGbooHri0eQB%2BxA%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Damien Duportal]

+1

Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :

> +1.
>
> At least such a move will make it very explicit for any new plugin that 
> only Maven really has /production/ support for Jenkins plugin dev.
>
> I think that we should still "allow" new plugins to use Gradle if they 
> wish so. But then they'll be very well aware that they got to be ready for 
> a lot of pain and much meta-work around the tooling itself for developing 
> their plugins.
> Which right now might be overlooked by new developers joining the 
> community and thinking that choosing one or another is simply a matter of 
> taste and habits.
>
> Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :
>
>> +1
>>
>> On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes  
>> wrote:
>> >
>> > Hey everyone,
>> >
>> > the Gradle JPI plugin lacks fundamental support of the jenkins.io 
>> infrastructure.
>> > There's no support for automated releases (CD, JEP-229), missing 
>> metadata for the plugin page and a few other limitations, which don't make 
>> it a great experience using it.
>> >
>> > Additionally, worth to note, the components mentioned above aren't new. 
>> People are proactively switching away from Gradle to Maven for better 
>> support and acceptance of our tooling, see ivy-plugin/49 for example.
>> >
>> > For the reasons stated, I would like to propose, that new plugin 
>> hosting requests use Maven, to have better toolchain support.
>> > I would be ready to lift this restriction again if the JPI plugin 
>> developers provide the same scope of tools like we have for Maven.
>> >
>> > Best,
>> > Alexander Brandes, for the hosting team
>> >
>> > --
>> > 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-de...@googlegroups.com.
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com
>> .
>>
>> -- 
>> 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-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com
>> .
>>
>

-- 
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/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Baptiste Mathus]

+1.

At least such a move will make it very explicit for any new plugin that
only Maven really has /production/ support for Jenkins plugin dev.

I think that we should still "allow" new plugins to use Gradle if they wish
so. But then they'll be very well aware that they got to be ready for a lot
of pain and much meta-work around the tooling itself for developing their
plugins.
Which right now might be overlooked by new developers joining the community
and thinking that choosing one or another is simply a matter of taste and
habits.

Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :

> +1
>
> On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes 
> wrote:
> >
> > Hey everyone,
> >
> > the Gradle JPI plugin lacks fundamental support of the jenkins.io
> infrastructure.
> > There's no support for automated releases (CD, JEP-229), missing
> metadata for the plugin page and a few other limitations, which don't make
> it a great experience using it.
> >
> > Additionally, worth to note, the components mentioned above aren't new.
> People are proactively switching away from Gradle to Maven for better
> support and acceptance of our tooling, see ivy-plugin/49 for example.
> >
> > For the reasons stated, I would like to propose, that new plugin hosting
> requests use Maven, to have better toolchain support.
> > I would be ready to lift this restriction again if the JPI plugin
> developers provide the same scope of tools like we have for Maven.
> >
> > Best,
> > Alexander Brandes, for the hosting team
> >
> > --
> > 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/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com
> .
>
> --
> 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/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com
> .
>

-- 
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/CANWgJS7Ngft3CgytKLxq5NJ8qWFeNGGq_XXFWmp1dhS-hRgZFw%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Basil Crow]

+1

On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes  wrote:
>
> Hey everyone,
>
> the Gradle JPI plugin lacks fundamental support of the jenkins.io 
> infrastructure.
> There's no support for automated releases (CD, JEP-229), missing metadata for 
> the plugin page and a few other limitations, which don't make it a great 
> experience using it.
>
> Additionally, worth to note, the components mentioned above aren't new. 
> People are proactively switching away from Gradle to Maven for better support 
> and acceptance of our tooling, see ivy-plugin/49 for example.
>
> For the reasons stated, I would like to propose, that new plugin hosting 
> requests use Maven, to have better toolchain support.
> I would be ready to lift this restriction again if the JPI plugin developers 
> provide the same scope of tools like we have for Maven.
>
> Best,
> Alexander Brandes, for the hosting team
>
> --
> 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/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com.

-- 
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/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['Daniel Beck' via Jenkins Developers]

On Wed, Dec 7, 2022 at 11:20 AM Alexander Brandes 
wrote:

> There's no support for automated releases (CD, JEP-229), missing metadata
> for the plugin page and a few other limitations, which don't make it a
> great experience using it.
>

Last I checked, generated poms were also invalid, which is a problem for
any consumers of these artifacts that do more than just download the hpi.

-- 
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/CAMo7PtJ3uDczz36EygL%2BB%2BM%2BsLfcKcMnLzA3%2BwHoy5om2NTd_A%40mail.gmail.com.

Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexander Brandes]

Hey everyone,

the Gradle JPI plugin lacks fundamental support of the jenkins.io 
infrastructure.
There's no support for automated releases (CD, JEP-229), missing metadata 
for the plugin page and a few other limitations, which don't make it a 
great experience using it.

Additionally, worth to note, the components mentioned above aren't new. 
People are proactively switching away from Gradle to Maven for better 
support and acceptance of our tooling, see ivy-plugin/49 
<https://github.com/jenkinsci/ivy-plugin/pull/49> for example.

For the reasons stated, I would like to propose, that new plugin hosting 
requests use Maven, to have better toolchain support.
I would be ready to lift this restriction again if the JPI plugin 
developers provide the same scope of tools like we have for Maven.

Best,
Alexander Brandes, for the hosting team

-- 
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/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com.

Re: Releasing a new plugin fails due to 'Check interesting categories' failure

[Karl Henselin]

Can you let us know what you did to resolve the issue? I am facing the same 
problem.
Thanks,
Karl

On Tuesday, July 19, 2022 at 8:48:32 AM UTC-5 jgl...@cloudbees.com wrote:

> https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/releases 
> seems to be working now?
>

-- 
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/164231b9-bc9b-4449-9a27-69f3081d2d6dn%40googlegroups.com.

Re: Releasing a new plugin fails due to 'Check interesting categories' failure

['Jesse Glick' via Jenkins Developers]

https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/releases seems
to be working now?

-- 
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/CANfRfr3uPw1NViWH873gup_B5Pqb781GAF4ETo_MCXyaRENywQ%40mail.gmail.com.

Re: Releasing a new plugin fails due to 'Check interesting categories' failure

['Gavin Mogan' via Jenkins Developers]

gh api /repos/jenkinsci/bmc-change-manager-imstm-plugin/releases
10++ jq -e -r '.[] | select(.draft == true and .name == "next") | .body'
11++ egrep '[⚠]|:(boom|tada|construction_worker):'

Seems like it gets "releases" for the plugin, looks for a draft named
"next" and then checks for any of those emojis/phrases

I'm also not seeing a failure, just that it says there's no
interesting items in the release notes.


On Mon, Jul 18, 2022 at 12:22 PM Marit M  wrote:
>
> https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/runs/7396269153?check_suite_focus=true
>
> Though I added an appropriate category label ( enhancement) to the PR before 
> merging.https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/pull/2
>
> Please advise how to proceed.
> Thanks,
> Marit.
>
> --
> 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/2a4e7dc6-e7ce-4890-ab7a-ac5289babc2an%40googlegroups.com.

-- 
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/CAG%3D_DuvBqU%3D%3DRw00fEGoXiO2LnNN0zK6b5_nF5LXADYxx8pHUQ%40mail.gmail.com.

Releasing a new plugin fails due to 'Check interesting categories' failure

[Marit M]

https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/runs/7396269153?check_suite_focus=true

Though I added *an appropriate category label* ( enhancement) to the PR 
before 
merging.https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/pull/2

Please advise how to proceed.
Thanks,
Marit.

-- 
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/2a4e7dc6-e7ce-4890-ab7a-ac5289babc2an%40googlegroups.com.

Re: New plugin for showing dynamic header across Jenkins

[Anil Kumar]

Hey Gavin,

Thanks for sharing your thoughts.

*Easier than the existing system notice box? What does dynamic mean in this
case*

- I felt the existing system notice box content gets unnoticed and my way
of showing the header at the top has more visibility.
- By dynamic I mean we can have the environment variables in the content
and it gets parsed and shown appropriately.
For example, "Current jenkins home is at ${System.getenv("JENKINS_HOME")}"
gets translated with the appropriate Jenkins home value. We can have
if-else checks as well. We are leveraging GStringTemplateEngine to achieve
this.

*I recommend against explicitly supporting HTML, your plugin will get
flagged by security allowing XSS and other exploit types. Recommend you use
the jenkins sanitization system, which supports allowing raw html, but also
(by default) supports safe html only, or markdown (like my above screenshot
says).*

- Thanks for this suggestion. Will leverage jenkins sanitization system for
this.

*I personally don't see me using the plugin as my jenkins install is just
mine, so take my comments as you will*

- It is extremely useful when you are maintaining a number of Jenkins
instances which in our case is ~5000. I agree that if you are alone using
your Jenkins, it is of no use.

*Hope is the best thing!*

PCS Anil Kumar Chukkala,
8130922822




On Sat, Jul 2, 2022 at 4:33 AM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

>
>- Header content will be dynamic and easy to update for administrators.
>
> Easier than the existing system notice box? What does dynamic mean in this
> case
> [image: image.png]
>
>- Header content will have an expiry date and post expiry it would not
>be shown.
>
> I could potentially see that useful
>
>- Header content will support HTML elements.
>
> I recommend against explicitly supporting HTML, your plugin will get
> flagged by security allowing XSS and other exploit types. Recommend you use
> the jenkins sanitization system, which supports allowing raw html, but also
> (by default) supports safe html only, or markdown (like my above screenshot
> says).
>
> I personally don't see me using the plugin as my jenkins install is just
> mine, so take my comments as you will
>
> On Thu, Jun 30, 2022 at 10:16 PM Anil Kumar  wrote:
>
>> Attaching the screenshots for better visibility...
>>
>> On Friday, July 1, 2022 at 10:43:31 AM UTC+5:30 Anil Kumar wrote:
>>
>>> Hello everyone,
>>>
>>> We recently updated our Jenkins to display a common header across
>>> Jenkins that helps in communicating with the users.
>>>
>>> It serves in notifying users for a variety of use cases like sharing
>>> updates about ongoing system outages or maintenance windows, sharing
>>> product updates and announcements, and collecting user feedback as well.
>>>
>>> We could not find any plugin which does this and would like to create a
>>> plugin and open source it.
>>>
>>> Let us know your thoughts.
>>>
>>> *Plugin brief*
>>>
>>>- Include a common header across Jenkins.
>>>- Header content will be dynamic and easy to update for
>>>administrators.
>>>- Header content will have an expiry date and post expiry it would
>>>not be shown.
>>>- Header content will support HTML elements.
>>>
>>> *Sample screenshots[image: Screenshot 2022-07-01 at 10.41.47 AM.png]*
>>>
>>> *[image: Screenshot 2022-07-01 at 10.39.03 AM.png][image: Screenshot
>>> 2022-07-01 at 10.40.31 AM.png]*
>>>
>>> Thanks,
>>> Anil Kumar
>>>
>> --
>> 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/1b4a6508-7a51-45df-b9d0-10daf37fc195n%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAG%3D_DuvBEkCrsaQbOLRiEnEtR3tvxfwcTboa%3DnTM2QSK4AVtEg%40mail.gmail.com
> 
> .
>

-- 
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 

Re: New plugin for showing dynamic header across Jenkins

['Gavin Mogan' via Jenkins Developers]

   - Header content will be dynamic and easy to update for administrators.

Easier than the existing system notice box? What does dynamic mean in this
case
[image: image.png]

   - Header content will have an expiry date and post expiry it would not
   be shown.

I could potentially see that useful

   - Header content will support HTML elements.

I recommend against explicitly supporting HTML, your plugin will get
flagged by security allowing XSS and other exploit types. Recommend you use
the jenkins sanitization system, which supports allowing raw html, but also
(by default) supports safe html only, or markdown (like my above screenshot
says).

I personally don't see me using the plugin as my jenkins install is just
mine, so take my comments as you will

On Thu, Jun 30, 2022 at 10:16 PM Anil Kumar  wrote:

> Attaching the screenshots for better visibility...
>
> On Friday, July 1, 2022 at 10:43:31 AM UTC+5:30 Anil Kumar wrote:
>
>> Hello everyone,
>>
>> We recently updated our Jenkins to display a common header across Jenkins
>> that helps in communicating with the users.
>>
>> It serves in notifying users for a variety of use cases like sharing
>> updates about ongoing system outages or maintenance windows, sharing
>> product updates and announcements, and collecting user feedback as well.
>>
>> We could not find any plugin which does this and would like to create a
>> plugin and open source it.
>>
>> Let us know your thoughts.
>>
>> *Plugin brief*
>>
>>- Include a common header across Jenkins.
>>- Header content will be dynamic and easy to update for
>>administrators.
>>- Header content will have an expiry date and post expiry it would
>>not be shown.
>>- Header content will support HTML elements.
>>
>> *Sample screenshots[image: Screenshot 2022-07-01 at 10.41.47 AM.png]*
>>
>> *[image: Screenshot 2022-07-01 at 10.39.03 AM.png][image: Screenshot
>> 2022-07-01 at 10.40.31 AM.png]*
>>
>> Thanks,
>> Anil Kumar
>>
> --
> 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/1b4a6508-7a51-45df-b9d0-10daf37fc195n%40googlegroups.com
> 
> .
>

-- 
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/CAG%3D_DuvBEkCrsaQbOLRiEnEtR3tvxfwcTboa%3DnTM2QSK4AVtEg%40mail.gmail.com.

Re: New Plugin With Multiple Components Hosting Question

['Daniel Beck' via Jenkins Developers]

On Thu, Jun 30, 2022 at 8:55 PM Mark Diesburg  wrote:

> We could submit just the source for the test-management plugin portion
> with reference to the other two components on GitHub since they can be used
> independently for other purposes.
>
>  Would this be acceptable?
>
>  Or would we have to submit all three components and also host the
> rest-client and reporting-tool components separately on GitHub in case
> someone wanted to use them for other purposes?
>
If you have general purpose libraries, those artifacts are best hosted e.g.
on Maven Central. I think GH packages need authentication to download,
making their use slightly inconvenient.

General purpose libraries deployed to the Jenkins Maven repo does not
really make sense, as we do not support its use as a general purpose Maven
repository.

-- 
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/CAMo7PtJDguxSVapdjtRZcrJaPs69BmdeXBBdrAr%2BoEN54UjgwQ%40mail.gmail.com.

Re: New Plugin With Multiple Components Hosting Question

[Tim Jacomb]

Hi

All libraries used in a plugin must be published publicly, open source
approved license, and to an artifact repository that anyone can pull from
normally either maven central or Jenkins repository.

Basically we can host it or you can push it to maven central if it makes
sense outside of Jenkins

Thanks
Tim

On Thu, 30 Jun 2022 at 19:55, Mark Diesburg  wrote:

> We will be submitting a new Jenkins plugin very shortly to integrate
> Jenkins into one of our products. Before pushing the plugin source to
> GitHub and starting the process we have a question on what should be
> submitted to the jenkinsci for hosting
>
>
>
> Our Jenkins plugin is comprised of three main Java components. These are
> separate components because they are each separately useful and extensible.
> The rest-client component is the starting point for potentially building a
> complete standalone Java client that can be used to directly interact with
> our products REST API. The reporting-tool can be used to submit automation
> results to our product from anywhere without requiring customers to write
> their own JUnit/xUnit parser to do so. As a result, they are effectively
> dependencies that the actual Jenkins plugin uses to accomplish the desired
> plugin integration.
>
>
>
> The summary of the components is:
>
>- A rest-client component
>   - Capable of connecting to, sending HTTP calls to, and interpreting
>   results from our product’s REST API.
>- A reporting-tool component
>   - Responsible for taking in report files, parsing them, and
>   converting their data into objects that can be sent to the rest-client 
> to
>   submit the build data using the rest-client to handle interacting with 
> our
>   products REST API.
>- A test-management plugin component
>   - The actual “plugin” portion of the Jenkins plugin.
>   - Responsible for handling configuring the integration within
>   Jenkins.
>   - Captures output from runs in Jenkins and uses the reporting-tool
>   component parse the data and then submit build results to our product.
>
>
>
> We could submit just the source for the test-management plugin portion
> with reference to the other two components on GitHub since they can be used
> independently for other purposes.
>
>
>
> Would this be acceptable?
>
>
>
> Or would we have to submit all three components and also host the
> rest-client and reporting-tool components separately on GitHub in case
> someone wanted to use them for other purposes?
>
>
>
> Thanks for any input!
>
> --
> 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/17390df4-6af9-4c0e-a214-93d41deaf80dn%40googlegroups.com
> 
> .
>

-- 
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/CAH-3BicNybR0Ffv-CDJtbwCZVHVMNU6eJ6qG5CWBifesNwdJ6Q%40mail.gmail.com.

New Plugin With Multiple Components Hosting Question

[Mark Diesburg]

We will be submitting a new Jenkins plugin very shortly to integrate 
Jenkins into one of our products. Before pushing the plugin source to 
GitHub and starting the process we have a question on what should be 
submitted to the jenkinsci for hosting

 

Our Jenkins plugin is comprised of three main Java components. These are 
separate components because they are each separately useful and extensible. 
The rest-client component is the starting point for potentially building a 
complete standalone Java client that can be used to directly interact with 
our products REST API. The reporting-tool can be used to submit automation 
results to our product from anywhere without requiring customers to write 
their own JUnit/xUnit parser to do so. As a result, they are effectively 
dependencies that the actual Jenkins plugin uses to accomplish the desired 
plugin integration.

 

The summary of the components is:

   - A rest-client component
  - Capable of connecting to, sending HTTP calls to, and interpreting 
  results from our product’s REST API. 
   - A reporting-tool component
  - Responsible for taking in report files, parsing them, and 
  converting their data into objects that can be sent to the rest-client to 
  submit the build data using the rest-client to handle interacting with 
our 
  products REST API. 
   - A test-management plugin component
  - The actual “plugin” portion of the Jenkins plugin. 
  - Responsible for handling configuring the integration within Jenkins. 
  - Captures output from runs in Jenkins and uses the reporting-tool 
  component parse the data and then submit build results to our product. 
   
 

We could submit just the source for the test-management plugin portion with 
reference to the other two components on GitHub since they can be used 
independently for other purposes.

 

Would this be acceptable?

 

Or would we have to submit all three components and also host the 
rest-client and reporting-tool components separately on GitHub in case 
someone wanted to use them for other purposes?

 

Thanks for any input!

-- 
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/17390df4-6af9-4c0e-a214-93d41deaf80dn%40googlegroups.com.

Re: Submission process of a new plugin

[Qasim Mehmood]

The pattern I saw was that both GitHub and Bitbucket had separate plugins for 
Kubernetes Credential Provider so I assumed it has to be a separate plugin. I 
am also not aware how optional dependencies are managed and what impact it 
would have on the Gitea plugin if we add this functionality there.

Regards,
Qasim Mehmood

> On 06-Apr-2022, at 12:44 AM, 'Gavin Mogan' via Jenkins Developers 
>  wrote:
> 
> Is it worth submitting a PR to add the functionality to the gitea
> plugin? its an optional dependency on the kubernetes secrets plugin
> anyways.
> 
> On Tue, Apr 5, 2022 at 12:29 PM Qasim Mehmood  wrote:
>> 
>> Hi Alexander,
>> 
>> Thank you for pointing me to the right direction. I have create the hosting 
>> request issue.
>> 
>> Though I'm unsure if there's a guideline how to deal with forks of existing 
>> plugins on the jenkinsci organization.
>> 
>> 
>> You were right about the fork. The bot did not like the fork attachment so I 
>> had to detach it. I have also squashed the commits from the original plugin 
>> so it's a standalone plugin now. The code is definitely borrowed from the 
>> other plugin but the two are functionally non-interchangeable so they 
>> shouldn’t be a fork.
>> 
>> Thanks again,
>> Qasim
>> 
>> On 05-Apr-2022, at 6:49 PM, Alexander Brandes  wrote:
>> 
>> Heyo,
>> 
>> there is this guide that outlines how to open a hosting request alongside 
>> the general information for publishing plugins. Though I'm unsure if there's 
>> a guideline how to deal with forks of existing plugins on the jenkinsci 
>> organization.
>> 
>> ~ Alex
>> 
>> On Tuesday, 5 April 2022 at 15:00:21 UTC+2 qas...@outlook.com wrote:
>>> 
>>> Hi,
>>> 
>>> I have written a plugin for creating a Gitea Personal Access Token 
>>> Credential from a Kubernetes Secret. I am not a Java developer so I forked 
>>> a similar plugin for creating a Github App credential and basically brute 
>>> forced it with my changes till it started working.
>>> 
>>> gitea-pat-kubernetes-credentials-plugin
>>> 
>>> I want to submit this plugin to Jenkins org so that anyone looking to 
>>> integrate their Gitea deployment with Jenkins on Kubernetes can do so.
>>> 
>>> I would appreciate any guidance on the next steps.
>>> 
>>> Thanks,
>>> Qasim
>> 
>> 
>> --
>> 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/619de4db-e94b-4d78-bae8-364b5560d332n%40googlegroups.com.
>> 
>> 
>> --
>> 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/MW4PR17MB46520211DBA49693E4C632DFB8E49%40MW4PR17MB4652.namprd17.prod.outlook.com.
> 
> -- 
> 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/CAG%3D_Duu%3DGAYnM0eCMTsOHNvB3bAapxy9HxLE2kyOtDa%2B9gSZpA%40mail.gmail.com.

-- 
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/MW4PR17MB465275A29FD9794991225DB7B8E49%40MW4PR17MB4652.namprd17.prod.outlook.com.

Re: Submission process of a new plugin

['Gavin Mogan' via Jenkins Developers]

Is it worth submitting a PR to add the functionality to the gitea
plugin? its an optional dependency on the kubernetes secrets plugin
anyways.

On Tue, Apr 5, 2022 at 12:29 PM Qasim Mehmood  wrote:
>
> Hi Alexander,
>
> Thank you for pointing me to the right direction. I have create the hosting 
> request issue.
>
> Though I'm unsure if there's a guideline how to deal with forks of existing 
> plugins on the jenkinsci organization.
>
>
> You were right about the fork. The bot did not like the fork attachment so I 
> had to detach it. I have also squashed the commits from the original plugin 
> so it's a standalone plugin now. The code is definitely borrowed from the 
> other plugin but the two are functionally non-interchangeable so they 
> shouldn’t be a fork.
>
> Thanks again,
> Qasim
>
> On 05-Apr-2022, at 6:49 PM, Alexander Brandes  wrote:
>
> Heyo,
>
> there is this guide that outlines how to open a hosting request alongside the 
> general information for publishing plugins. Though I'm unsure if there's a 
> guideline how to deal with forks of existing plugins on the jenkinsci 
> organization.
>
> ~ Alex
>
> On Tuesday, 5 April 2022 at 15:00:21 UTC+2 qas...@outlook.com wrote:
>>
>> Hi,
>>
>> I have written a plugin for creating a Gitea Personal Access Token 
>> Credential from a Kubernetes Secret. I am not a Java developer so I forked a 
>> similar plugin for creating a Github App credential and basically brute 
>> forced it with my changes till it started working.
>>
>> gitea-pat-kubernetes-credentials-plugin
>>
>> I want to submit this plugin to Jenkins org so that anyone looking to 
>> integrate their Gitea deployment with Jenkins on Kubernetes can do so.
>>
>> I would appreciate any guidance on the next steps.
>>
>> Thanks,
>> Qasim
>
>
> --
> 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/619de4db-e94b-4d78-bae8-364b5560d332n%40googlegroups.com.
>
>
> --
> 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/MW4PR17MB46520211DBA49693E4C632DFB8E49%40MW4PR17MB4652.namprd17.prod.outlook.com.

-- 
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/CAG%3D_Duu%3DGAYnM0eCMTsOHNvB3bAapxy9HxLE2kyOtDa%2B9gSZpA%40mail.gmail.com.

Re: Submission process of a new plugin

[Qasim Mehmood]

Hi Alexander,

Thank you for pointing me to the right direction. I have create the hosting 
request issue 
.

> Though I'm unsure if there's a guideline how to deal with forks of existing 
> plugins on the jenkinsci organization.

You were right about the fork. The bot did not like the fork attachment so I 
had to detach it. I have also squashed the commits from the original plugin so 
it's a standalone plugin now. The code is definitely borrowed from the other 
plugin but the two are functionally non-interchangeable so they shouldn’t be a 
fork.

Thanks again,
Qasim

> On 05-Apr-2022, at 6:49 PM, Alexander Brandes  wrote:
> 
> Heyo,
> 
> there is this guide 
>  that 
> outlines how to open a hosting request alongside the general information for 
> publishing plugins . Though 
> I'm unsure if there's a guideline how to deal with forks of existing plugins 
> on the jenkinsci organization.
> 
> ~ Alex
> 
> On Tuesday, 5 April 2022 at 15:00:21 UTC+2 qas...@outlook.com 
>  wrote:
> Hi,
> 
> I have written a plugin for creating a Gitea Personal Access Token Credential 
> from a Kubernetes Secret. I am not a Java developer so I forked a similar 
> plugin 
>  for 
> creating a Github App credential and basically brute forced it with my 
> changes till it started working.
> 
> gitea-pat-kubernetes-credentials-plugin 
> 
> 
> I want to submit this plugin to Jenkins org so that anyone looking to 
> integrate their Gitea deployment with Jenkins on Kubernetes can do so.
> 
> I would appreciate any guidance on the next steps.
> 
> Thanks,
> Qasim
> 
> -- 
> 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/619de4db-e94b-4d78-bae8-364b5560d332n%40googlegroups.com
>  
> .

-- 
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/MW4PR17MB46520211DBA49693E4C632DFB8E49%40MW4PR17MB4652.namprd17.prod.outlook.com.

Re: Submission process of a new plugin

[Alexander Brandes]

Heyo,

there is this guide 
 that 
outlines how to open a hosting request alongside the general information 
for publishing plugins . 
Though I'm unsure if there's a guideline how to deal with forks of existing 
plugins on the jenkinsci organization.

~ Alex

On Tuesday, 5 April 2022 at 15:00:21 UTC+2 qas...@outlook.com wrote:

> Hi,
>
> I have written a plugin for creating a Gitea Personal Access Token 
> Credential from a Kubernetes Secret. I am not a Java developer so I forked 
> a similar plugin 
>  for 
> creating a Github App credential and basically brute forced it with my 
> changes till it started working.
>
> gitea-pat-kubernetes-credentials-plugin 
> 
>
> I want to submit this plugin to Jenkins org so that anyone looking to 
> integrate their Gitea deployment with Jenkins on Kubernetes can do so.
>
> I would appreciate any guidance on the next steps.
>
> Thanks,
> Qasim
>

-- 
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/619de4db-e94b-4d78-bae8-364b5560d332n%40googlegroups.com.

Submission process of a new plugin

[Qasim12]

Hi,

I have written a plugin for creating a Gitea Personal Access Token Credential 
from a Kubernetes Secret. I am not a Java developer so I forked a similar 
plugin  
for creating a Github App credential and basically brute forced it with my 
changes till it started working.

gitea-pat-kubernetes-credentials-plugin 


I want to submit this plugin to Jenkins org so that anyone looking to integrate 
their Gitea deployment with Jenkins on Kubernetes can do so.

I would appreciate any guidance on the next steps.

Thanks,
Qasim

-- 
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/MW4PR17MB4652CFA59CA0CD87F771F0F5B8E49%40MW4PR17MB4652.namprd17.prod.outlook.com.

Re: Not able to release new plugin changes

['Björn Pedersen' via Jenkins Developers]

You need to reset  the credentials.


See https://groups.google.com/g/jenkinsci-dev/c/1-46eS41y6I

and

Details: https://www.jenkins.io/blog/2021/09/04/wiki-attacked/


nikhil...@gmail.com schrieb am Montag, 13. September 2021 um 09:43:33 UTC+2:

> Hi ,
>
> I am from MathWorks official CI team we are trying to release of new 
> pluing changes for MATLAB however we see the Jenkins artifact repo  user 
> name and password stopped working suddenly our orgs official user name 
> registered with Jenkins is *mathworks_ci_team * Please let me know if we 
> need to do anything from our side to get the release process working.
>
> Thanks & Regards
> Nikhil 
>

-- 
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/80b7d74e-ade9-48cd-be05-f0240389177cn%40googlegroups.com.

Not able to release new plugin changes

[Nikhil Bhoski]

Hi ,

I am from MathWorks official CI team we are trying to release of new pluing 
changes for MATLAB however we see the Jenkins artifact repo  user name and 
password stopped working suddenly our orgs official user name registered 
with Jenkins is *mathworks_ci_team * Please let me know if we need to do 
anything from our side to get the release process working.

Thanks & Regards
Nikhil 

-- 
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/0d8a4e54-f684-4ba2-961a-5aef93154226n%40googlegroups.com.

Re: Issues releasing new plugin

[Ullrich Hafner]

This seems to be solved?  
https://github.com/jenkins-infra/repository-permissions-updater/pull/1679

> Am 30.09.2020 um 14:22 schrieb Pontus Rydin :
> 
> Hi fellow Jenkins coders!
> 
> I just finished up a plugin for VMware vRealize Automation and got permission 
> to push it to Artifactory. However, I'm getting a 403 error while pushing the 
> POM, but the HPI seems to go through. 
> 
> I have an approved write access request here: 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1679#issuecomment-701037609
> 
> My repo is here: https://github.com/jenkinsci/vrealize-automation-8-plugin
> 
> I have added the  section to my ~/.m2/settings.xml like this: 
> https://gist.github.com/prydin/1f02e01d0599e7b2b8a48dc9cec44a26
> 
> But when I run a "mvn release:prepare release:perform", I get the following 
> error: Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
> project vrealize-automation-8: Failed to deploy artifacts: Could not transfer 
> artifact io.jenkins.plugins:vrealize-automation-8:hpi:1.1 from/to 
> maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Access denied 
> to: 
> https://repo.jenkins-ci.org/releases/io/jenkins/plugins/vrealize-automation-8/1.1/vrealize-automation-8-1.1.hpi,
>  ReasonPhrase: Forbidden. -> [Help 1]
> 
> However, looking at the Maven output, it appears that at least some of the 
> files are successfully transfered. Output is here: 
> https://gist.github.com/prydin/b30640cabfa16c32601ca35a4c00e95c
> 
> Any ideas? 
> 
> Regards
> Pontus Rydin, VMware
> 
> -- 
> 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/c27733d1-e1f5-471f-bf23-b12565322131n%40googlegroups.com
>  
> .

-- 
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/F2A30CED-F17A-4841-9A22-EE56B0124E28%40gmail.com.

Issues releasing new plugin

[Pontus Rydin]

Hi fellow Jenkins coders!

I just finished up a plugin for VMware vRealize Automation and got 
permission to push it to Artifactory. However, I'm getting a 403 error 
while pushing the POM, but the HPI seems to go through. 

I have an approved write access request 
here: 
https://github.com/jenkins-infra/repository-permissions-updater/pull/1679#issuecomment-701037609

My repo is here: https://github.com/jenkinsci/vrealize-automation-8-plugin

I have added the  section to my ~/.m2/settings.xml like 
this: https://gist.github.com/prydin/1f02e01d0599e7b2b8a48dc9cec44a26

But when I run a "mvn release:prepare release:perform", I get the following 
error: Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) 
on project vrealize-automation-8: Failed to deploy artifacts: Could not 
transfer artifact io.jenkins.plugins:vrealize-automation-8:hpi:1.1 from/to 
maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Access denied 
to: 
https://repo.jenkins-ci.org/releases/io/jenkins/plugins/vrealize-automation-8/1.1/vrealize-automation-8-1.1.hpi,
 
ReasonPhrase: Forbidden. -> [Help 1]

However, looking at the Maven output, it appears that at least some of the 
files are successfully transfered. Output is 
here: https://gist.github.com/prydin/b30640cabfa16c32601ca35a4c00e95c

Any ideas? 

Regards
Pontus Rydin, VMware

-- 
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/c27733d1-e1f5-471f-bf23-b12565322131n%40googlegroups.com.

Re: Add New plugin request: kubesphere-token-auth-plugin

[Jesse Glick]

On Sun, Jun 14, 2020 at 11:52 PM SW C  wrote:
> In the upcoming 3.0，oauth authority authentication is realized. The 
> plugins of kubesphere-token-auth-plugin will complete the docking with oauth.

I know nothing about Kubesphere but offhand it sounds like this could be a PR to

https://github.com/jenkinsci/kubernetes-credentials-plugin

depending on size, complexity, and external deps.

-- 
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/CANfRfr0Beq41C%2BdSTpB%2BEx7EMijuX78djiLJft6-r%3DHzZhTAfA%40mail.gmail.com.

Re: Add New plugin request: kubesphere-token-auth-plugin

[SW C]

Ok , I have created an issue for this plugin. 

Thanks.

On Monday, June 15, 2020 at 12:02:48 PM UTC+8, Gavin Mogan wrote:
>
> https://www.jenkins.io/doc/developer/publishing/requesting-hosting/
>
> You need to make an HOSTING ticket to get it processed.
>
> If you don't already have an account you'll have to wait for infra issues 
> to be over.
>
> Gavin
>
> On Sun., Jun. 14, 2020, 8:52 p.m. SW C, > 
> wrote:
>
>> Hi，I need to create a new plugin repository
>>
>>
>> id: kubesphere-token-auth-plugin
>>
>> introduction:  
>>
>> https://github.com/kubesphere is a Kubernetes platform tailored to 
>> the DevOps teams. DevOps uses Jenkins as its engine. 
>>
>> In the upcoming 3.0，oauth authority authentication is realized. The 
>> plugins of kubesphere-token-auth-plugin will complete the docking with 
>> oauth.
>>
>> github id : shaowenchen
>>
>> Thanks,
>> shaowenchen
>>
>>
>> -- 
>> 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 jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/0f789899-b40c-44ef-9b98-86aa4d04ef2ao%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/0f789899-b40c-44ef-9b98-86aa4d04ef2ao%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/04ae04eb-d126-4c28-9092-ec833ed16169o%40googlegroups.com.

Re: Add New plugin request: kubesphere-token-auth-plugin

['Gavin Mogan' via Jenkins Developers]

https://www.jenkins.io/doc/developer/publishing/requesting-hosting/

You need to make an HOSTING ticket to get it processed.

If you don't already have an account you'll have to wait for infra issues
to be over.

Gavin

On Sun., Jun. 14, 2020, 8:52 p.m. SW C,  wrote:

> Hi，I need to create a new plugin repository
>
>
> id: kubesphere-token-auth-plugin
>
> introduction:
>
> https://github.com/kubesphere is a Kubernetes platform tailored to
> the DevOps teams. DevOps uses Jenkins as its engine.
>
> In the upcoming 3.0，oauth authority authentication is realized. The
> plugins of kubesphere-token-auth-plugin will complete the docking with
> oauth.
>
> github id : shaowenchen
>
> Thanks,
> shaowenchen
>
>
> --
> 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/0f789899-b40c-44ef-9b98-86aa4d04ef2ao%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/0f789899-b40c-44ef-9b98-86aa4d04ef2ao%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAG%3D_DuvROAS4BZMo2Bmg9ZyssEHtZhWwOOOgdJ%2BfA2aTnv%2Bvig%40mail.gmail.com.

Add New plugin request: kubesphere-token-auth-plugin

[SW C]

Hi，I need to create a new plugin repository


id: kubesphere-token-auth-plugin

introduction:  

https://github.com/kubesphere is a Kubernetes platform tailored to the 
DevOps teams. DevOps uses Jenkins as its engine. 

In the upcoming 3.0，oauth authority authentication is realized. The 
plugins of kubesphere-token-auth-plugin will complete the docking with 
oauth.

github id : shaowenchen

Thanks,
shaowenchen


-- 
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/0f789899-b40c-44ef-9b98-86aa4d04ef2ao%40googlegroups.com.

Re: regarding issues publishing new plugin, but publishing works when publishing a snapshot

[Daniel Beck]

io/jenkins/plugin
io/jenkins/plugins


> On 23. May 2020, at 02:26, john rowley  wrote:
> 
>  

-- 
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/D9BBE4D1-2C1E-4290-B046-E5EB37C48793%40beckweb.net.

Re: regarding issues publishing new plugin, but publishing works when publishing a snapshot

[Slide]

According to https://www.jenkins.io/doc/developer/publishing/releasing/ 403
means the permissions are not setup. It's possible you just need to wait a
little bit and try again.

On Fri, May 22, 2020, 18:15 john rowley  wrote:

> Hello,
>
>
>
> I recently went through the process of developing a Jenkins plugin,
> getting it hosted, getting permissions for publishing to artifactory, etc.
> Everything was working correctly until I attempted to release the plugin.
>
>
>
> I was able to release a snapshot of the plugin, and this worked fine. The
> artifacts appear to all have been uploaded successfully, to the following
> URL.
> https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.1-SNAPSHOT/
>  Upon
> bumping and attempting to release the plugin I encountered 403 errors from
> artifactory.
>
>
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-
> plugin:2.8.2:deploy (default-deploy) on project bitbucket-kubernetes-
> credentials: Failed to deploy artifacts: Could not transfer artifact io.
> jenkins.plugins:bitbucket-kubernetes-credentials:hpi:0.0.3 from/to maven.
> jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Authorization
> failed for
> https://repo.jenkins-ci.org/releases/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.3/bitbucket-kubernetes-credentials-0.0.3.hpi
> 403 Forbidden -> [Help 1]
>
>
>
> I did create a pull request and get permissions to release this plugin
> several hours ago, and I believe that the yaml for the
> repository-permissions-updater  is correct, firstly because it was looked
> over during the PR, secondly because I was able to upload to the snapshots
> path, but not the releases path.
> https://github.com/robbert229/repository-permissions-updater/blob/master/permissions/plugin-bitbucket-kubernetes-credentials.yml
>
>
>
> What are the steps I should take to begin debugging this, and what could I
> possibly have done wrong?
>
>
>
> Thank you
>
> --
> 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/415bea83-484c-4d77-8526-8bf278b0e646%40googlegroups.com
> 
> .
>

-- 
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/CAPiUgVfnC-SV60TTnjzEAmVYx9j%3D9h5Z9-gMyYOzD4oEORujtg%40mail.gmail.com.

regarding issues publishing new plugin, but publishing works when publishing a snapshot

[john rowley]

Hello,

 

I recently went through the process of developing a Jenkins plugin, getting 
it hosted, getting permissions for publishing to artifactory, etc. 
Everything was working correctly until I attempted to release the plugin.

 

I was able to release a snapshot of the plugin, and this worked fine. The 
artifacts appear to all have been uploaded successfully, to the following 
URL. 
https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.1-SNAPSHOT/
 Upon 
bumping and attempting to release the plugin I encountered 403 errors from 
artifactory.

 

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:
2.8.2:deploy (default-deploy) on project bitbucket-kubernetes-credentials: 
Failed to deploy artifacts: Could not transfer artifact io.jenkins.plugins:
bitbucket-kubernetes-credentials:hpi:0.0.3 from/to maven.jenkins-ci.org (
https://repo.jenkins-ci.org/releases/): Authorization failed for 
https://repo.jenkins-ci.org/releases/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.3/bitbucket-kubernetes-credentials-0.0.3.hpi
 
403 Forbidden -> [Help 1]

 

I did create a pull request and get permissions to release this plugin 
several hours ago, and I believe that the yaml for the 
repository-permissions-updater  is correct, firstly because it was looked 
over during the PR, secondly because I was able to upload to the snapshots 
path, but not the releases path. 
https://github.com/robbert229/repository-permissions-updater/blob/master/permissions/plugin-bitbucket-kubernetes-credentials.yml

 

What are the steps I should take to begin debugging this, and what could I 
possibly have done wrong?

 

Thank you

-- 
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/415bea83-484c-4d77-8526-8bf278b0e646%40googlegroups.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Mark Waite]

Adopt OpenJDK is widely used in the Jenkins project.  You're also welcome
to use other OpenJDK implementations.  Licensing restrictions on recent
Oracle JDK 8 versions have made it very rarely used in the Jenkins project.

On Mon, Feb 24, 2020 at 11:38 AM Daniel Anechitoaie 
wrote:

> Will do. Is OpenJDK ok? Or i need Oracle JDK?
>
> On Monday, February 24, 2020 at 8:35:39 PM UTC+2, Jesse Glick wrote:
>>
>> On Mon, Feb 24, 2020 at 12:05 PM Daniel Anechitoaie
>>  wrote:
>> > I'm compiling on OpenJDK 11.
>>
>> Best to use JDK 8 for all purposes related to Jenkins.
>>
> --
> 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/b925de42-af7a-4047-92bb-01b39b69d6a6%40googlegroups.com
> 
> .
>

-- 
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/CAO49JtHt-ooDrX5E0HaETr-_9pj%3Dqha%2BEbWzA%2Ba2AiMC9saD_g%40mail.gmail.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Daniel Anechitoaie]

Will do. Is OpenJDK ok? Or i need Oracle JDK?

On Monday, February 24, 2020 at 8:35:39 PM UTC+2, Jesse Glick wrote:
>
> On Mon, Feb 24, 2020 at 12:05 PM Daniel Anechitoaie 
> > wrote: 
> > I'm compiling on OpenJDK 11. 
>
> Best to use JDK 8 for all purposes related to Jenkins. 
>

-- 
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/b925de42-af7a-4047-92bb-01b39b69d6a6%40googlegroups.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Jesse Glick]

On Mon, Feb 24, 2020 at 12:05 PM Daniel Anechitoaie
 wrote:
> I'm compiling on OpenJDK 11.

Best to use JDK 8 for all purposes related to Jenkins.

-- 
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/CANfRfr2LUp1V42HZEXzjhz2o3fULmFHU%3D0A95R9PGq29%3D4u5CA%40mail.gmail.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Daniel Anechitoaie]

Yes, that was it. I'm compiling on OpenJDK 11.
Using 2.164.1 works now even with parent 
POM 3.56

Thank you.


On Monday, February 24, 2020 at 6:30:39 PM UTC+2, Mark Waite wrote:
>
>
>
> On Mon, Feb 24, 2020 at 9:19 AM Daniel Anechitoaie  > wrote:
>
>> Hmm, yeah, I had a small brainfart. For some reason I was thinking in 
>> decimal and was seeing 3.6 as 3.60 which in my mind was more recent than 
>> 3.56 (which is the latest 3.x version)/
>>
>> So now with 
>>
>> 
>> org.jenkins-ci.plugins
>> plugin
>> 3.56
>> 
>> 
>>
>>
>>
>> And 
>>
>> 
>> 1.8
>> 8
>> 2.121.1
>> 
>>
>>
>>
>> I get
>>
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
>> (default-compile) on project my-plugin: Compilation failure
>> [ERROR] java.nio.file.NoSuchFileException: 
>> /Users/daniels/Work/my-plugin/target/classes/META-INF/annotations/hudson.Extension
>>
>> Should I just go to latest Jenkins and the 4.0 beta parent pom?
>>
>>
> I receive that message when I'm compiling with Java 11 but using a Jenkins 
> version before 2.164.  The first Jenkins LTS to support Java 11 compilation 
> is Jenkins 2.164 (as far as I know)  I've learned to type:
>
> $ mvn clean -Djenkins.version=2.164.3 verify
>
> Eventually, I will update the plugins where I use that technique so that 
> they require Jenkins 2.164 or newer as their minimum version.  Jenkins 
> 2.164 is over a year old.  
>

-- 
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/723e6cd0-0774-4903-8f3f-f33d1e00567f%40googlegroups.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Mark Waite]

On Mon, Feb 24, 2020 at 9:19 AM Daniel Anechitoaie 
wrote:

> Hmm, yeah, I had a small brainfart. For some reason I was thinking in
> decimal and was seeing 3.6 as 3.60 which in my mind was more recent than
> 3.56 (which is the latest 3.x version)/
>
> So now with
>
> 
> org.jenkins-ci.plugins
> plugin
> 3.56
> 
> 
>
>
>
> And
>
> 
> 1.8
> 8
> 2.121.1
> 
>
>
>
> I get
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project my-plugin: Compilation failure
> [ERROR] java.nio.file.NoSuchFileException:
> /Users/daniels/Work/my-plugin/target/classes/META-INF/annotations/hudson.Extension
>
> Should I just go to latest Jenkins and the 4.0 beta parent pom?
>
>
I receive that message when I'm compiling with Java 11 but using a Jenkins
version before 2.164.  The first Jenkins LTS to support Java 11 compilation
is Jenkins 2.164 (as far as I know)  I've learned to type:

$ mvn clean -Djenkins.version=2.164.3 verify

Eventually, I will update the plugins where I use that technique so that
they require Jenkins 2.164 or newer as their minimum version.  Jenkins
2.164 is over a year old.

-- 
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/CAO49JtFcGD4ByCPZKQ0Zb6pWGirs5utgsHyoUZ5W8zWQOPtzWw%40mail.gmail.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Daniel Anechitoaie]

Hmm, yeah, I had a small brainfart. For some reason I was thinking in 
decimal and was seeing 3.6 as 3.60 which in my mind was more recent than 
3.56 (which is the latest 3.x version)/

So now with 


org.jenkins-ci.plugins
plugin
3.56





And 


1.8
8
2.121.1




I get

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
(default-compile) on project my-plugin: Compilation failure
[ERROR] java.nio.file.NoSuchFileException: 
/Users/daniels/Work/my-plugin/target/classes/META-INF/annotations/hudson.Extension

Should I just go to latest Jenkins and the 4.0 beta parent pom?

On Monday, February 24, 2020 at 5:58:39 PM UTC+2, Jesse Glick wrote:
>
> On Mon, Feb 24, 2020 at 10:29 AM Daniel Anechitoaie 
> > wrote: 
> >  
> > org.jenkins-ci.plugins 
> > plugin 
> > 3.6 
>
> This is very old. Try using the latest 3.x, and for the newer LTS line 
> you may need to use a 4.0 beta. 
>

-- 
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/89819385-f68d-485b-9c11-30acad69c7ca%40googlegroups.com.

Re: I'm working on a new plugin and when I try to run it I get the following error

[Jesse Glick]

On Mon, Feb 24, 2020 at 10:29 AM Daniel Anechitoaie
 wrote:
> 
> org.jenkins-ci.plugins
> plugin
> 3.6

This is very old. Try using the latest 3.x, and for the newer LTS line
you may need to use a 4.0 beta.

-- 
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/CANfRfr0VF6ebag2%2BVJKAmaYXcGvsjg%3DmLRQ4yFEExXkCkhU5Rw%40mail.gmail.com.

I'm working on a new plugin and when I try to run it I get the following error

[Daniel Anechitoaie]

Hi,

I just started working on a new plugin and when I run mvn hpi:run I get the 
following error:

Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.slf4j:jcl-over-slf4j:1.7.25 
paths to dependency are:
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.slf4j:jcl-over-slf4j:1.7.25
and
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.jenkins-ci.main:jenkins-core:2.204.2
+-org.slf4j:jcl-over-slf4j:1.7.26
,
Require upper bound dependencies error for 
org.slf4j:log4j-over-slf4j:1.7.25 paths to dependency are:
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.slf4j:log4j-over-slf4j:1.7.25
and
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.jenkins-ci.main:jenkins-core:2.204.2
+-org.slf4j:log4j-over-slf4j:1.7.26
,
Require upper bound dependencies error for org.slf4j:slf4j-jdk14:1.7.25 
paths to dependency are:
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.slf4j:slf4j-jdk14:1.7.25
and
+-io.jenkins.plugins:my-plugin:1.0.0
  +-org.jenkins-ci.main:jenkins-war:2.204.2
+-org.slf4j:slf4j-jdk14:1.7.26
]

Any idea what's going on and what I can do to fix this? 
I don't have any direct dependencies to org.slf4j

Here's my POM as well:

---


http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;>

4.0.0


org.jenkins-ci.plugins
plugin
3.6



io.jenkins.plugins
my-plugin
1.0.0
hpi

My Plugin




1.8
8
2.204.2





org.apache.maven.plugins
maven-compiler-plugin

${jdk.version}
${jdk.version}
true



org.jenkins-ci.tools
maven-hpi-plugin

true







repo.jenkins-ci.org
https://repo.jenkins-ci.org/public/





repo.jenkins-ci.org
https://repo.jenkins-ci.org/public/






org.jenkins-ci.plugins
structs
1.17




org.apache.commons
commons-lang3
3.9




org.apache.commons
commons-text
1.8




commons-io
commons-io
2.6




org.codehaus.plexus
plexus-utils
3.3.0



org.jsoup
jsoup
1.12.2




-- 
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/00ff633f-fe59-4861-a7fc-80b07ea0d8c0%40googlegroups.com.

Re: New plugin: global-pre-script-plugin

['Gavin Mogan' via Jenkins Developers]

You need to make a HOSTING jira ticket -
https://jenkins.io/doc/developer/publishing/requesting-hosting/

On Sat, Feb 1, 2020 at 1:53 PM Orekaria N  wrote:

> Hello
>
>
> I have created a plugin that may interest 
> youhttps://github.com/Orekaria/global-pre-script-plugin
>
> Please, let me know if it can be added to official repositories / list of
> missing requirements
>
> jenkins id: orekaria
>
> Regards
>
> --
> 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/739b2905-0550-4826-aba0-b131b349e093%40googlegroups.com
> 
> .
>

-- 
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/CAG%3D_DutR9NU4zh1ZNAZvaqmC%3D2sBbpjCJCE0iBXwFthE6_rXZw%40mail.gmail.com.

New plugin: global-pre-script-plugin

[Orekaria N]

Hello


I have created a plugin that may interest you
https://github.com/Orekaria/global-pre-script-plugin

Please, let me know if it can be added to official repositories / list of
missing requirements

jenkins id: orekaria

Regards

-- 
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/739b2905-0550-4826-aba0-b131b349e093%40googlegroups.com.

Do not use the new plugin-pom with the BOM profile.

[James Nord]

Hi all,

There are issues using the jenkins-bom for dependency versioning in the 
plugin pom.

Whilst it works for a single plugin, any plugins that are deployed using 
this also force any plugins that depend on them to enable the profile (as 
it can not be enabled per module).  likewise the other way around is 
probably very similar.

Adding dependecnyManagement based on a profile was probably not a great 
idea in hindsight :-(

Whilst I do not thing the change should be reverted, I don;t think people 
should use it unless they think very carefully.

possible solutions are 
1) flatten the pom
2) split the parent into bom/no bom

I'm busy with a release cycle right now, but plan to try again later this 
week.

/James

-- 
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/0598e832-e486-4058-8138-51bf08739afd%40googlegroups.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Daniel Beck]

> On 7. Sep 2019, at 03:52, Jesse Glick  wrote:
> 
> I tried this, but it does not do what I need: it just sends, say, a
> daily list of all issues matching that filter. To replace the
> notification function of default assignee, I would want something that
> only send me _changes_ in issues matching the filter.

`createdDate > -1d` (or updatedDate) might work for daily notifications from 
subscriptions, perhaps in conjunction with `watcher != currentUser()`. But 
still not a great replacement (and misses issues whose component gets changed 
to yours).

FWIW I like being default assignee for matrix-auth-plugin and being informed of 
new issues quickly. Granted, it's a very low volume of notifications, but I 
expect that to apply to most plugins in the "long tail". It's the top 10-20% of 
plugins that presumably have a very high volume of new and updated issues, 
making having a default assignee impractical.

-- 
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/FE5691A6-2F90-4311-8439-D5FB060C92AE%40beckweb.net.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Jesse Glick]

On Thu, Sep 5, 2019 at 7:01 PM Oleg Nenashev  wrote:
> create a filter (or to use a public one), go to "Details" and then to 
> subscribe to notifications there.

I tried this, but it does not do what I need: it just sends, say, a
daily list of all issues matching that filter. To replace the
notification function of default assignee, I would want something that
only send me _changes_ in issues matching the filter.

I suppose a workaround would be to create a filter matching all issues
from some component which I am not watching, and then send a digest of
that; then I would need to click on everything newly appearing and
watch it, and rely on the watches for notifications. Seems pretty
clumsy though.

-- 
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/CANfRfr2kBsSjX50OWKTX1P6EwWPj-KQ_QiufssxjBzi-%3DX3XWg%40mail.gmail.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Gavin]

Filterers can be saved and shared, and so a default search could be setup
with
https://confluence.atlassian.com/jira063/advanced-searching-functions-683542527.html#AdvancedSearchingFunctions-componentsLeadByUser()
and then any custom requirements could be forked and tweaked per user.


On Fri., Sep. 6, 2019, 1:35 a.m. Olblak,  wrote:

> I totally agree with the general opinion that an issue should only be
> assigned to someone if that person is effectively ready to work on it
> otherwise it just bring confusion about either the assignee will
> effectively works on it or not.
> And I also understand that people use default assignee to get notify when
> a new issue is created.
>
> What I propose is to set 'default assignee' to 'unassigned' by default and
> add a notification rule saying each time a ticket is (re)-open, or close,
> we notify component lead. (btw I just created that rule now :p)
>
> Regarding filters, I think it really depends how much time we spend on
> Jira, personally I heavily rely on them but I don't expect every
> contributor to configure their own filters
>
> ---
> -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
>
>
>
>
> On Fri, Sep 6, 2019, at 7:38 AM, domi wrote:
>
> My first thought was that I would like to keep the default assignee - but
> after reading all the comments, I have to agree, that my only reason for
> this is so that I get notified by new issues. Although Oleg shoed it is
> possible to create a filter and get notified about this things, It seems
> quite complicated and many maintainers will not do it and therefore not get
> any info about new issues. So I think there should be some kind of easy way
> to at least inform the official maintainer - maybe we can even create these
> filters automatically…
> /Domi
>
>
> On 6 Sep 2019, at 01:37, Ullrich Hafner  wrote:
>
> Making it an optional field in the HOSTING report seems to be a good
> compromise, so +1 from me for such a change.
>
> (I understand that developers do not want to be assignee for issues they
> are never going to fix. On the other hands, for a user that reports an
> issue it is somewhat disappointing that no one actually cares about his new
> issue. This will indicate that it is not worth to report an issue at all.)
>
>
> Am 05.09.2019 um 20:40 schrieb Slide :
>
> We should add a field in the HOSTING Jira that allows people to specify if
> they want to be set as the default assignee, then the bot can check that
> field before setting up the default assignee for the component. We would
> need someone with admin access on Jira to add the field. I can create a PR
> for the bot once the field is setup.
>
> On Thu, Sep 5, 2019, 11:35 Matt Sicker  wrote:
>
> That makes tons of sense to me. You should only assign tickets to
> yourself that you're currently working on or at least intend to work
> on in the near future.
>
> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
> >
> > I fully agree with Jesse's take. IMO for most plugins where the
> maintainer is not going to have time to jump on new reports right away,
> this sends a wrong message that issues will be analyzed and fixed by the
> assignee.
> > This sends a second bad message: that an issue being already assigned,
> this is not necessary that someone steps up to work on a fix proposal.
> >
> > AIUI, the default assignee is often used by maintainers as a nice way to
> be notified when a new issue arises, but on average not meaning that that
> given maintainer will commit to address in a timely manner anything new
> that comes in.
> >
> > IOW, my main point is that I think we should allow maintainers to be
> made default assignee, but we should default to having no default assignee.
> >
> > Le mar. 27 août 2019 à 15:14, Jesse Glick  a
> écrit :
> >>
> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev 
> wrote:
> >> > a default assignee for the component
> >>
> >> As always, I prefer there to be no default assignee for a JIRA
> >> component. It is not a helpful concept IMO. If and when I decide to
> >> tackle an issue, I will assign it to myself.
> >>
> >> --
> >> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> .
> >
> > --
> > 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
> .
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Olblak]

I totally agree with the general opinion that an issue should only be assigned 
to someone if that person is effectively ready to work on it otherwise it just 
bring confusion about either the assignee will effectively works on it or not.
And I also understand that people use default assignee to get notify when a new 
issue is created. 

What I propose is to set 'default assignee' to 'unassigned' by default and add 
a notification rule saying each time a ticket is (re)-open, or close, we notify 
component lead. (btw I just created that rule now :p)

Regarding filters, I think it really depends how much time we spend on Jira, 
personally I heavily rely on them but I don't expect every contributor to 
configure their own filters

---
-> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---




On Fri, Sep 6, 2019, at 7:38 AM, domi wrote:
> My first thought was that I would like to keep the default assignee - but 
> after reading all the comments, I have to agree, that my only reason for this 
> is so that I get notified by new issues. Although Oleg shoed it is possible 
> to create a filter and get notified about this things, It seems quite 
> complicated and many maintainers will not do it and therefore not get any 
> info about new issues. So I think there should be some kind of easy way to at 
> least inform the official maintainer - maybe we can even create these filters 
> automatically…
> /Domi
> 
> 
>> On 6 Sep 2019, at 01:37, Ullrich Hafner  wrote:
>> 
>> Making it an optional field in the HOSTING report seems to be a good 
>> compromise, so +1 from me for such a change.
>> 
>> (I understand that developers do not want to be assignee for issues they are 
>> never going to fix. On the other hands, for a user that reports an issue it 
>> is somewhat disappointing that no one actually cares about his new issue. 
>> This will indicate that it is not worth to report an issue at all.)
>> 
>> 
>>> Am 05.09.2019 um 20:40 schrieb Slide :
>>> 
>>> We should add a field in the HOSTING Jira that allows people to specify if 
>>> they want to be set as the default assignee, then the bot can check that 
>>> field before setting up the default assignee for the component. We would 
>>> need someone with admin access on Jira to add the field. I can create a PR 
>>> for the bot once the field is setup.
>>> 
>>> On Thu, Sep 5, 2019, 11:35 Matt Sicker  wrote:
 That makes tons of sense to me. You should only assign tickets to
  yourself that you're currently working on or at least intend to work
  on in the near future.
 
  On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
  >
  > I fully agree with Jesse's take. IMO for most plugins where the 
 maintainer is not going to have time to jump on new reports right away, 
 this sends a wrong message that issues will be analyzed and fixed by the 
 assignee.
  > This sends a second bad message: that an issue being already assigned, 
 this is not necessary that someone steps up to work on a fix proposal.
  >
  > AIUI, the default assignee is often used by maintainers as a nice way 
 to be notified when a new issue arises, but on average not meaning that 
 that given maintainer will commit to address in a timely manner anything 
 new that comes in.
  >
  > IOW, my main point is that I think we should allow maintainers to be 
 made default assignee, but we should default to having no default assignee.
  >
  > Le mar. 27 août 2019 à 15:14, Jesse Glick  a 
 écrit :
  >>
  >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  
 wrote:
  >> > a default assignee for the component
  >>
  >> As always, I prefer there to be no default assignee for a JIRA
  >> component. It is not a helpful concept IMO. If and when I decide to
  >> tackle an issue, I will assign it to myself.
  >>
  >> --
  >> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com.
  >
  > --
  > 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.
 
 
 
  -- 
  Matt Sicker
  Senior Software Engineer, 

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[domi]

My first thought was that I would like to keep the default assignee - but after 
reading all the comments, I have to agree, that my only reason for this is so 
that I get notified by new issues. Although Oleg shoed it is possible to create 
a filter and get notified about this things, It seems quite complicated and 
many maintainers will not do it and therefore not get any info about new 
issues. So I think there should be some kind of easy way to at least inform the 
official maintainer - maybe we can even create these filters automatically…
/Domi


> On 6 Sep 2019, at 01:37, Ullrich Hafner  wrote:
> 
> Making it an optional field in the HOSTING report seems to be a good 
> compromise, so +1 from me for such a change.
> 
> (I understand that developers do not want to be assignee for issues they are 
> never going to fix. On the other hands, for a user that reports an issue it 
> is somewhat disappointing that no one actually cares about his new issue. 
> This will indicate that it is not worth to report an issue at all.)
>  
> 
>> Am 05.09.2019 um 20:40 schrieb Slide > >:
>> 
>> We should add a field in the HOSTING Jira that allows people to specify if 
>> they want to be set as the default assignee, then the bot can check that 
>> field before setting up the default assignee for the component. We would 
>> need someone with admin access on Jira to add the field. I can create a PR 
>> for the bot once the field is setup.
>> 
>> On Thu, Sep 5, 2019, 11:35 Matt Sicker > > wrote:
>> That makes tons of sense to me. You should only assign tickets to
>> yourself that you're currently working on or at least intend to work
>> on in the near future.
>> 
>> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus > > wrote:
>> >
>> > I fully agree with Jesse's take. IMO for most plugins where the maintainer 
>> > is not going to have time to jump on new reports right away, this sends a 
>> > wrong message that issues will be analyzed and fixed by the assignee.
>> > This sends a second bad message: that an issue being already assigned, 
>> > this is not necessary that someone steps up to work on a fix proposal.
>> >
>> > AIUI, the default assignee is often used by maintainers as a nice way to 
>> > be notified when a new issue arises, but on average not meaning that that 
>> > given maintainer will commit to address in a timely manner anything new 
>> > that comes in.
>> >
>> > IOW, my main point is that I think we should allow maintainers to be made 
>> > default assignee, but we should default to having no default assignee.
>> >
>> > Le mar. 27 août 2019 à 15:14, Jesse Glick > > > a écrit :
>> >>
>> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev > >> > wrote:
>> >> > a default assignee for the component
>> >>
>> >> As always, I prefer there to be no default assignee for a JIRA
>> >> component. It is not a helpful concept IMO. If and when I decide to
>> >> tackle an issue, I will assign it to myself.
>> >>
>> >> --
>> >> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
>> >>  
>> >> .
>> >
>> > --
>> > 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
>> >  
>> > .
>> 
>> 
>> 
>> -- 
>> Matt Sicker
>> Senior Software Engineer, CloudBees
>> 
>> -- 
>> 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/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
>>  
>> 

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Ullrich Hafner]

Making it an optional field in the HOSTING report seems to be a good 
compromise, so +1 from me for such a change.

(I understand that developers do not want to be assignee for issues they are 
never going to fix. On the other hands, for a user that reports an issue it is 
somewhat disappointing that no one actually cares about his new issue. This 
will indicate that it is not worth to report an issue at all.)
 

> Am 05.09.2019 um 20:40 schrieb Slide :
> 
> We should add a field in the HOSTING Jira that allows people to specify if 
> they want to be set as the default assignee, then the bot can check that 
> field before setting up the default assignee for the component. We would need 
> someone with admin access on Jira to add the field. I can create a PR for the 
> bot once the field is setup.
> 
> On Thu, Sep 5, 2019, 11:35 Matt Sicker  > wrote:
> That makes tons of sense to me. You should only assign tickets to
> yourself that you're currently working on or at least intend to work
> on in the near future.
> 
> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  > wrote:
> >
> > I fully agree with Jesse's take. IMO for most plugins where the maintainer 
> > is not going to have time to jump on new reports right away, this sends a 
> > wrong message that issues will be analyzed and fixed by the assignee.
> > This sends a second bad message: that an issue being already assigned, this 
> > is not necessary that someone steps up to work on a fix proposal.
> >
> > AIUI, the default assignee is often used by maintainers as a nice way to be 
> > notified when a new issue arises, but on average not meaning that that 
> > given maintainer will commit to address in a timely manner anything new 
> > that comes in.
> >
> > IOW, my main point is that I think we should allow maintainers to be made 
> > default assignee, but we should default to having no default assignee.
> >
> > Le mar. 27 août 2019 à 15:14, Jesse Glick  > > a écrit :
> >>
> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  >> > wrote:
> >> > a default assignee for the component
> >>
> >> As always, I prefer there to be no default assignee for a JIRA
> >> component. It is not a helpful concept IMO. If and when I decide to
> >> tackle an issue, I will assign it to myself.
> >>
> >> --
> >> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> >>  
> >> .
> >
> > --
> > 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
> >  
> > .
> 
> 
> 
> -- 
> Matt Sicker
> Senior Software Engineer, CloudBees
> 
> -- 
> 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/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
>  
> .
> 
> -- 
> 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/CAPiUgVduNcw%3DWYb6%2BHNebzarAoQCt%2Bg6bQuFgitVP%3DuC3O2Bww%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the 

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Jesse Glick]

On Thu, Sep 5, 2019 at 2:36 PM Gavin  wrote:
> Does jira have a concept of auto watch like GitHub does? So an issue could 
> still notify people but not be claimed?

Good question. That would be very useful.

-- 
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/CANfRfr3SkUwcr4D4mDfqgF2axjWFv42J-2_zRcBgF%2BNOXsK%3DLQ%40mail.gmail.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Gavin]

Does jira have a concept of auto watch like GitHub does? So an issue could
still notify people but not be claimed?

On Thu., Sep. 5, 2019, 11:35 a.m. Matt Sicker, 
wrote:

> That makes tons of sense to me. You should only assign tickets to
> yourself that you're currently working on or at least intend to work
> on in the near future.
>
> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
> >
> > I fully agree with Jesse's take. IMO for most plugins where the
> maintainer is not going to have time to jump on new reports right away,
> this sends a wrong message that issues will be analyzed and fixed by the
> assignee.
> > This sends a second bad message: that an issue being already assigned,
> this is not necessary that someone steps up to work on a fix proposal.
> >
> > AIUI, the default assignee is often used by maintainers as a nice way to
> be notified when a new issue arises, but on average not meaning that that
> given maintainer will commit to address in a timely manner anything new
> that comes in.
> >
> > IOW, my main point is that I think we should allow maintainers to be
> made default assignee, but we should default to having no default assignee.
> >
> > Le mar. 27 août 2019 à 15:14, Jesse Glick  a
> écrit :
> >>
> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev 
> wrote:
> >> > a default assignee for the component
> >>
> >> As always, I prefer there to be no default assignee for a JIRA
> >> component. It is not a helpful concept IMO. If and when I decide to
> >> tackle an issue, I will assign it to myself.
> >>
> >> --
> >> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> .
> >
> > --
> > 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
> .
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>
> --
> 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/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
> .
>

-- 
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/CAG%3D_DuvBB0ye4y%2Bg2_F8MjwgbMPutgUbuiFTA0d0fjVnYX4xcw%40mail.gmail.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Matt Sicker]

That makes tons of sense to me. You should only assign tickets to
yourself that you're currently working on or at least intend to work
on in the near future.

On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
>
> I fully agree with Jesse's take. IMO for most plugins where the maintainer is 
> not going to have time to jump on new reports right away, this sends a wrong 
> message that issues will be analyzed and fixed by the assignee.
> This sends a second bad message: that an issue being already assigned, this 
> is not necessary that someone steps up to work on a fix proposal.
>
> AIUI, the default assignee is often used by maintainers as a nice way to be 
> notified when a new issue arises, but on average not meaning that that given 
> maintainer will commit to address in a timely manner anything new that comes 
> in.
>
> IOW, my main point is that I think we should allow maintainers to be made 
> default assignee, but we should default to having no default assignee.
>
> Le mar. 27 août 2019 à 15:14, Jesse Glick  a écrit :
>>
>> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  wrote:
>> > a default assignee for the component
>>
>> As always, I prefer there to be no default assignee for a JIRA
>> component. It is not a helpful concept IMO. If and when I decide to
>> tackle an issue, I will assign it to myself.
>>
>> --
>> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com.
>
> --
> 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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com.

[DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Baptiste Mathus]

I fully agree with Jesse's take. IMO for most plugins where the maintainer
is not going to have time to jump on new reports right away, this sends a
wrong message that issues will be analyzed and fixed by the assignee.
This sends a second bad message: that an issue being already assigned, this
is not necessary that someone steps up to work on a fix proposal.

AIUI, the default assignee is often used by maintainers as a nice way to be
notified when a new issue arises, but on average not meaning that that
given maintainer will commit to address in a timely manner anything new
that comes in.

IOW, my main point is that I think we should allow maintainers to be made
default assignee, but we should default to having no default assignee.

Le mar. 27 août 2019 à 15:14, Jesse Glick  a écrit :

> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev 
> wrote:
> > a default assignee for the component
>
> As always, I prefer there to be no default assignee for a JIRA
> component. It is not a helpful concept IMO. If and when I decide to
> tackle an issue, I will assign it to myself.
>
> --
> 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/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> .
>

-- 
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/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.

Re: new plugin/option to deploy on staging

[Rey C]

Thanks Oleg I will test those.

best regards 

Reinaldo

El jueves, 22 de agosto de 2019, 16:00:43 (UTC-5), Oleg Nenashev escribió:
>
> Hi,
>
> These page is being controlled by summary.jelly/groovy pages in Actions 
> which you can attach to the build.
>
> One of examples (maybe abit too heavy, but you can get an idea there):
>
>- 
>
> https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/java/hudson/plugins/parameterizedtrigger/BuildInfoExporterAction.java
>- 
>
> https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/resources/hudson/plugins/parameterizedtrigger/BuildInfoExporterAction/summary.groovy
>
> Hopefully it helps,
> Oleg
>
> On Friday, August 16, 2019 at 7:07:31 PM UTC+2, Rey C wrote:
>>
>> Hello guys
>>
>> I want to create my first  plugin for jenkins,  my idea is create a 
>> plugin that deploy the current build on staging environment (please check 
>> the red icon on image).
>>
>> Could  you please guide me about if you kwon an example/tutorial or base 
>> code put the button on this page and launch any action from this.
>>
>>
>> [image: deploy.png]
>>
>> thanks  and best regards.
>>
>> Reinaldo C
>>
>

-- 
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/f13d8066-74b4-4d99-a999-e794887b1f29%40googlegroups.com.

Re: new plugin/option to deploy on staging

[Oleg Nenashev]

Hi,

These page is being controlled by summary.jelly/groovy pages in Actions 
which you can attach to the build.

One of examples (maybe abit too heavy, but you can get an idea there):

   - 
   
https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/java/hudson/plugins/parameterizedtrigger/BuildInfoExporterAction.java
   - 
   
https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/resources/hudson/plugins/parameterizedtrigger/BuildInfoExporterAction/summary.groovy

Hopefully it helps,
Oleg

On Friday, August 16, 2019 at 7:07:31 PM UTC+2, Rey C wrote:
>
> Hello guys
>
> I want to create my first  plugin for jenkins,  my idea is create a plugin 
> that deploy the current build on staging environment (please check the red 
> icon on image).
>
> Could  you please guide me about if you kwon an example/tutorial or base 
> code put the button on this page and launch any action from this.
>
>
> [image: deploy.png]
>
> thanks  and best regards.
>
> Reinaldo C
>

-- 
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/ba694eb5-98f0-420f-ba1b-ec7a7cf50100%40googlegroups.com.

Re: How to introduce new plugin variable with default value without breaking compatibility

[Jesse Glick]

On Tue, Jul 30, 2019 at 10:03 AM 'Robin Jansohn' via Jenkins
Developers  wrote:
> Can this sort of problem be avoided/fixed?

You can replace uses of `path` with a getter returning `path != null ?
path : "/manager/text"`. Or you can add a

private Object readResolve() {
if (path == null) {
path = "/manager/text";
}
return this;
}

which will do the same but also ensure that if the configuration is
opened and resaved that a legal value for `path` will be written.

Besides checking for null you may need to check for `path.isEmpty()`,
in case the bad commit has already been released and some users who
resaved the form without touching this field may have `config.xml`
files with



if that is in fact not a legal value.

-- 
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/CANfRfr0M055QJsorX6K-F%2B%3DuoPcnw-Z9w97%3DzJRo8-b62y0agg%40mail.gmail.com.

How to introduce new plugin variable with default value without breaking compatibility

['Robin Jansohn' via Jenkins Developers]

I've recently taken over the deploy-plugin and bundled a new version. One 
of the commits that was included in the new version added a new variable 
called path which should later be used as an additional configuration 
option to overwrite the default context path. Here's the commit:
https://github.com/jenkinsci/deploy-plugin/commit/db254d7c8c70214c7da91308c50bedb25fbf4eb8#diff-b2a541c8af2e6626b795634cc9d7143dR48

The problem is that this caused a breaking change for users using the new 
plugin with their existing freestyle jobs:
https://issues.jenkins-ci.org/browse/JENKINS-58667

The problem is that the job config is not automatically updated and the 
following builds do not have the new variable populated with the default 
value but are instead null.

Not updated config which causes the failure:

  

  
tomcat-credentials
https://tomcat.internal.com:8120
  


target/*.war
false
  


The only way to fix this seems to be to force an update of the job config 
by simply clicking Configure->Save. This updates the job config and 
everything works smoothly (see the additional path element):

  

  
tomcat-credentials
https://tomcat.internal.com:8120
/manager/text
  

target/*.war
false
  


So my question is: Can this sort of problem be avoided/fixed? What is the 
proposed way to introduce new plugin variables with default values without 
breaking the job builds?

-- 
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/7f0e500c-5e8d-4e30-b693-332574718656%40googlegroups.com.

Planning for contributing a New Plugin for Discarding Builds

[Nisarg Shah]

Hi Everyone,
Currently there are many issues regarding old build discarder plugins such 
as discard-old-build-plugin and enhanced-old-builld-discarder and also the 
current discarder startegy "LogRotator".
And also the strategy does not work as expected. You can find other issues 
and problems here 
<https://docs.google.com/document/d/15LWsnNyZU2eDG56Zl4HW1_fgUSxuazujBypfAGVLrz8/edit#>
 suggested 
by Martin D'Anjou and where improvement is needed. 

So I am planning to make a new plugin which includes solution to some of 
the problems. I had made my GSoC Proposal 
<https://docs.google.com/document/d/1iUSc8_zY6ZVMXbF-FUHowDHkxw4KMZ1tQxu3blhCTFo/edit?usp=sharing>
 
this year for this project but was not selected due to some reasons. But I 
decided to contribute anyways.
Implementation steps are included in my GSoC Proposal, and will try to make 
it better.

I am also planning to include featutres which will solve few Jira issues, 
which are JENKINS-12165 <https://issues.jenkins-ci.org/browse/JENKINS-12615>
, JENKINS-1182 <https://issues.jenkins-ci.org/browse/JENKINS-1182>, 
JENKINS-3433 <https://issues.jenkins-ci.org/browse/JENKINS-3433>, 
JENKINS-48715 <https://issues.jenkins-ci.org/browse/JENKINS-48715>
Gitter chat room for this discarder project is : 
https://gitter.im/jenkinsci/gsoc-build-discarder-project.

Looking for suggestions and support. I would be happy and thankful if 
anyone is interested in guiding me for implementation of this plugin.

Thanks and Regards,
Nisarg Shah
Github : nisarg1499

-- 
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/06122b44-fbed-40ed-a5c0-095ca18aaf04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: filtering on io.jenkins does not find any archetype causing inability to create a new plugin

[Daniel Beck]

Weird, works for me, even on a new user account without ~/.m2 directory.

Did you previously configure Maven's settings.xml, and that might interfere 
here? If you're unsure, rename the file ~.m2/settings.xml to anything else 
(IOW, remove it but keep a backup), and try again.

> On 21. Dec 2018, at 22:29, Bassam Khouri  wrote:
> 
> Hi, 
> 
> I'm a complete newbie to Jenkins plugin development, and I'm attempting to 
> create a new plugin.  I'm following the instructions here:
> 
> https://jenkins.io/doc/developer/tutorial/prepare/
> 
> I have the following java and maven versions installed
> 
> $ java -version
> 
> java version "1.8.0_144"
> 
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> 
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> 
> $ mvn -version
> 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T14:41:47-04:00)
> 
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> 
> Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
> 
> Default locale: en_CA, platform encoding: UTF-8
> 
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> 
> 
> The next step, Creating a Plugin, indicated to run mvn -U archetype:generate 
> -Dfilter=io.jenkins.archetypes: and indicates I will be presented with an 
> option of which type of plugin I want to create.  However, I encounter the 
> following:
> 
> $ mvn -U archetype:generate -Dfilter=io.jenkins.archetypes:
> 
> ...
> 
> [INFO] --- maven-archetype-plugin:3.0.1:generate (default-cli) @ 
> standalone-pom ---
> 
> [INFO] Generating project in Interactive mode
> 
> [INFO] Your filter doesn't match any archetype, so try again with another 
> value.
> 
> [INFO] 
> 
> 
> [INFO] BUILD SUCCESS
> 
> [INFO] 
> 
> 
> [INFO] Total time:  4.705 s
> 
> [INFO] Finished at: 2018-12-21T16:05:37-05:00
> 
> [INFO] 
> 
> 
> 
> I have been searching the web for a solution, but nothing I try is 
> successful. 
> 
> What am I doing wrong?
> 
> Bassam
> 
> 
> -- 
> 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/69f46c0e-2ebd-4b5e-9166-ae4adb855efb%40googlegroups.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/537857B7-68D5-41FE-913E-4C1ADCFB3063%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

filtering on io.jenkins does not find any archetype causing inability to create a new plugin

[Bassam Khouri]

Hi, 

I'm a complete newbie to Jenkins plugin development, and I'm attempting to 
create a new plugin.  I'm following the instructions here:

https://jenkins.io/doc/developer/tutorial/prepare/

I have the following java and maven versions installed

$ java -version

java version "1.8.0_144"

Java(TM) SE Runtime Environment (build 1.8.0_144-b01)

Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

$ mvn -version

Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T14:41:47-04:00)

Maven home: /usr/local/Cellar/maven/3.6.0/libexec

Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre

Default locale: en_CA, platform encoding: UTF-8

OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"

The next step, Creating a Plugin, indicated to run mvn -U 
archetype:generate -Dfilter=io.jenkins.archetypes: and indicates I will be 
presented with an option of which type of plugin I want to create.  
However, I encounter the following:

$ mvn -U archetype:generate -Dfilter=io.jenkins.archetypes:

...

[INFO] --- maven-archetype-plugin:3.0.1:generate (default-cli) @ 
standalone-pom ---

[INFO] Generating project in Interactive mode

[INFO] Your filter doesn't match any archetype, so try again with another 
value.

[INFO] 


[INFO] BUILD SUCCESS

[INFO] 


[INFO] Total time:  4.705 s

[INFO] Finished at: 2018-12-21T16:05:37-05:00

[INFO] 


I have been searching the web for a solution, but nothing I try is 
successful. 

What am I doing wrong?

Bassam

-- 
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/69f46c0e-2ebd-4b5e-9166-ae4adb855efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: propose a new plugin

[Slide]

You can follow the process outlined here:
https://jenkins.io/doc/developer/publishing/requesting-hosting/

On Mon, Oct 29, 2018 at 6:48 AM  wrote:

> During the DW|JW in Nice, I half-heard someone talk about proposing a new
> plugin.
> Also, during the conference I got Daniel Beck to quickly hack together a
> prototype of a plugin we have the need for.
> https://github.com/daniel-beck/quiet-down-endpoint-plugin
>
> After a bit of tweaking and modification to better suit the use case, I
> know have
> https://github.com/travelaudience/anonymous-uptime-check-plugin
> Simple plugin to expose uptime status to unauthenticated users
>
> I think this would be helpful to the community, and would be more than
> happy to move it under https://github.com/jenkinsci
>
> --
> 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/59cbe1fd-3288-419c-984e-a12ccb2ff1cd%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/59cbe1fd-3288-419c-984e-a12ccb2ff1cd%40googlegroups.com?utm_medium=email_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/CAPiUgVdurbL5eD2dMPn3bMTOOWkUgkFo76DtE8UuViwz5e5_dQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

propose a new plugin

[j . knurek]

During the DW|JW in Nice, I half-heard someone talk about proposing a new 
plugin. 
Also, during the conference I got Daniel Beck to quickly hack together a 
prototype of a plugin we have the need 
for. https://github.com/daniel-beck/quiet-down-endpoint-plugin

After a bit of tweaking and modification to better suit the use case, I 
know have 
https://github.com/travelaudience/anonymous-uptime-check-plugin
Simple plugin to expose uptime status to unauthenticated users

I think this would be helpful to the community, and would be more than 
happy to move it under https://github.com/jenkinsci

-- 
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/59cbe1fd-3288-419c-984e-a12ccb2ff1cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Plugin - Dependency-Track

[Slide]

Hi Steve,

Please see https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins for
information on how to get a plugin hosted.

Regards,

Alex

On Wed, Sep 12, 2018 at 4:36 PM Steve Springett 
wrote:

> Hello,
>
> I’m the author of a few Jenkins plugins and I’m working on another.
>
> The plugin is for Dependency-Track, an open source platform that allows
> organizations to track the use of third-party and open source components,
> determine if they are out-of-date, or have publicly disclosed
> vulnerabilities.
>
> https://dependencytrack.org/
>
> I’d like to get the repo and wiki created if possible.
>
> Thanks in advance.
>
> —Steve
>
> --
> 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/CABRTs2wZ8gPd4vTiZBHSasshRJp%2BBgxvihUpi5juO%2B-ACOzjjA%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/CAPiUgVd1O813vbD4Q3hbuWCqEgGTJrCjmtUPwtqkHy3dF1Pq_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

New Plugin - Dependency-Track

[Steve Springett]

Hello,

I’m the author of a few Jenkins plugins and I’m working on another.

The plugin is for Dependency-Track, an open source platform that allows
organizations to track the use of third-party and open source components,
determine if they are out-of-date, or have publicly disclosed
vulnerabilities.

https://dependencytrack.org/

I’d like to get the repo and wiki created if possible.

Thanks in advance.

—Steve

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

Re: New plugin developer: A View Plugin

[Jesse Glick]

On Fri, Apr 20, 2018 at 2:27 PM, Sverre Moe  wrote:
> This made me suspect that I was using OpenJDK and Java 9.

Oh, well Jenkins does not run on Java 9. At all. So there is that.

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

Re: New plugin developer: A View Plugin

[Sverre Moe]

target/surefire-reports/TEST-InjectedTest.xml

WARNING: Failed to instantiate 
Key[type=org.jenkinsci.main.modules.instance_identity.PageDecoratorImpl, 
annotation=[none]]; skipping this component
com.google.inject.ProvisionException: Unable to provision, see the 
following errors:

1) Error injecting constructor, java.lang.NoClassDefFoundError: 
javax/xml/bind/DatatypeConverter
  at 
org.jenkinsci.main.modules.instance_identity.PageDecoratorImpl.(PageDecoratorImpl.java:21)

1 error
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
at 
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at 
hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
at 
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at 
com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at 
hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
at 
hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:482)
at hudson.ExtensionList.load(ExtensionList.java:366)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
at hudson.ExtensionList.iterator(ExtensionList.java:158)
at 
hudson.diagnosis.NullIdDescriptorMonitor.verify(NullIdDescriptorMonitor.java:72)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
at 
hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1062)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at 
org.jenkinsci.main.modules.instance_identity.pem.PEMHelper.writeEncoded(PEMHelper.java:188)
at 
org.jenkinsci.main.modules.instance_identity.pem.PEMHelper.encodePEM(PEMHelper.java:113)
at 
org.jenkinsci.main.modules.instance_identity.InstanceIdentity.write(InstanceIdentity.java:96)
at 
org.jenkinsci.main.modules.instance_identity.InstanceIdentity.(InstanceIdentity.java:66)
at 
org.jenkinsci.main.modules.instance_identity.InstanceIdentity.(InstanceIdentity.java:40)
at 
org.jenkinsci.main.modules.instance_identity.PageDecoratorImpl.(PageDecoratorImpl.java:22)
at 
org.jenkinsci.main.modules.instance_identity.PageDecoratorImpl$$FastClassByGuice$$68618106.newInstance()
at 
com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
at 
com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
at 
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
at 
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
at 
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
... 26 more
Caused by: java.lang.ClassNotFoundException: 
javax.xml.bind.DatatypeConverter
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
... 41 more


This made me suspect that I was using OpenJDK and Java 9.
I set JAVA_HOME to Oracle JDK 8 and I was able to run mvn install without 
any test errors.

Re: New plugin developer: A View Plugin

[Jesse Glick]

On Wed, Apr 18, 2018 at 5:18 PM, Sverre Moe  wrote:
> What kind of test is this? There is nothing in my newly created project.

The Jenkins plugin build harness generates a synthetic test to verify
basic sanity aspects of your plugin. I am not sure what specifically
the `FailingHttpStatusCodeException` is—that would be included in test
details under `target/surefire-reports/`.

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

New plugin developer: A View Plugin

[Sverre Moe]

Let me begin starting with I have never written a plugin to Jenkins before.
I have plenty of insight into the Jenkins API for Groovy scripting in 
script console and scripting Pipeline scripts.
I am a Java developer for over 10 years (API/Spring, Swing/JavaFX), and 
have been using Jenkins for most of those years. Most of our inhouse 
software is C++ though, and a few Java.

I was thinking of creating a custom view plugin to Jenkins for our company. 
Our developers are not happy with the Jenkins UI (Blue Ocean is a step 
forward, but it is still slow and doesn't support customization on 
pipelines view). They feel it is difficult to get an overview which release 
branches has failed, as all the user branches are getting in the way of 
that on Multibranch Pipeline jobs. 

It is hard to convince my peers that Jenkins is much better than our 
inhouse legacy CI system (bunch of ruby scripts, which a single developer 
now has revamped with a Vue.js frontend) for people that has never used a 
third party CI system like Jenkins. The arguments I frequent hear is why 
use resources with Jenkins when there is already a functional CI system. 
They (He) feels all the work I have put in pipelines is wasted, and that we 
should abandon Jenkins to build releases. Well, enough about that (I just 
had to went a little about my reason for creating a custom view plugin).

The plugin I was thinking of creating should list projects with branches 
status. Usually with multibranch pipelines you would have to click on the 
project to get the list of branches, but I wanted the view plugin to list 
branches along with the project on the view page.

Currently I want to start simple, by just listing all the projects and get 
it up and running on Jenkins.

I am seeking some good documentation, howto's for creating Jenkins plugins, 
specifically a View plugin.
https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial
This tutorial revolves around creating a Builder. Could not find a tutorial 
for creating a view plugin, so I will start with this one.
http://www.baeldung.com/jenkins-custom-plugin

Even a visual simple view plugin like jenkins-build-monitor-plugin 
, looks very 
complex. I am getting lost in all the source code. Most of it probably not 
relevant for my plugin.
A reckon a view plugin is half Java code, half HTML/Javascript/CSS code, 
and some jelly it seems also.
https://wiki.jenkins.io/display/JENKINS/Basic+guide+to+Jelly+usage+in+Jenkins

Having browsed this jenkins-build-monitor-plugin 
 on GitHub I am 
overwhelmed. It has almost chased me away, but not quite. I think I must 
start small, just the few bits I need to get a view plugin up to display 
some projects, get the basic feel of the building blocks.


Generating the maven project

mvn archetype:generate -Dfilter=io.jenkins.archetypes:plugin

[INFO] No archetype defined. Using maven-archetype-quickstart 
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> io.jenkins.archetypes:empty-plugin (Skeleton of a Jenkins plugin 
with a POM and an empty source tree.)
2: remote -> io.jenkins.archetypes:global-configuration-plugin (Skeleton of a 
Jenkins plugin with a POM and an example piece of global configuration.)
3: remote -> io.jenkins.archetypes:hello-world-plugin (Skeleton of a Jenkins 
plugin with a POM and an example build step.)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive 
contains): : 1
Choose io.jenkins.archetypes:empty-plugin version:  

1: 1.0
2: 1.1
3: 1.2
4: 1.3
5: 1.4
Choose a number: 5: 5
I Went through the pom.xml and updated some values

 2.117
 8

Currently no source files yet in my plugin, nor tests. Running mvn install 
fails:
[ERROR] Errors:  
[ERROR] 
org.junit.runner.manipulation.Filter.initializationError(org.junit.runner.manipulation.Filter)
 
[ERROR]   Run 1: Filter.initializationError »  No tests found matching 
Method org.jvnet.hudson 
[ERROR]   Run 2: Filter.initializationError »  No runnable methods 
[ERROR]   Run 3: Filter.initializationError »  No runnable methods 
[ERROR]   Run 4: Filter.initializationError »  No runnable methods 
[INFO]  
[ERROR]   FailedTest.org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite 
» FailingHttpStatusCode 
[INFO]  
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0

What kind of test is this? There is nothing in my newly created project.

-- 
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/b0320f5b-97fc-4c22-985a-607e9dc7bb5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Start in creating a new plugin

[Amr Osama]

Thanks alot now i want to debugs the hello world plugin to jenkins using 
eclipse
i run this command as in documentation mvnDebug hpi:run this error message 
appear in the command line
Listening for transport dt_socket at address: 8000
Debugger failed to attach: handshake failed - received >GET / HTTP/1.1< - 
expect
ed >JDWP-Handshake<
i read that i must set debugger option in eclipse to port 8000 but i do not 
know how to do that , so please help.
thank you again.
On Sunday, September 17, 2017 at 5:17:12 PM UTC+2, slide wrote:
>
> If you haven't executed maven before, then the .m2 directory probably 
> won't exist. You can create the .m2 directory in the %USERPROFILE% 
> directory, %USERPROFILE% is a variable, you can put it into Windows 
> Explorer or the command line and it will resolve to the correct location 
> (e.g., in the command line you can run dir %USERPROFILE% and it will list 
> the contents of the actual directory where the user profile is located). 
>
> For the second item, it looks like you aren't inside the directory where 
> your plugin resides. You need to cd to that directory and then run the 
> command.
>
> On Sun, Sep 17, 2017 at 8:10 AM Amr Osama  > wrote:
>
>> First of all i want to create a jenkins plugin using eclipse having mvn 
>> 3.5 installed and jenkins 1.651.3 , and i just went throw you documentation 
>> , i cant find the first step which says 
>> to put some code in this path (Windows users will find them in 
>> %USERPROFILE%\.m2\settings.xml), 
>> i cant find this path , secondly the step after is to write this command $ 
>> mvn -DdownloadSources=true -DdownloadJavadocs=true 
>> -DoutputDirectory=target/eclipse-classes 
>> -Declipse.workspace=/path/to/workspace eclipse:eclipse 
>> eclipse:configure-workspace it gives me error which i will copy now
>>
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-eclipse-plugin:2.1
>> 0:eclipse (default-cli): Goal requires a project to execute but there is 
>> no POM
>> in this directory (C:\Users\aelmetwa). Please verify you invoked Maven 
>> from the
>> correct directory. -> [Help 1]
>> so please if any body know the solution for this issue please answer.
>> P.S i am new to windows OS.
>> Thank you.
>>
>> -- 
>> 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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/63164a7d-b4f6-4150-a683-8c1b6afa7c51%40googlegroups.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/45dbcf85-b5be-475b-9c37-046e14d53e12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Start in creating a new plugin

[Slide]

If you haven't executed maven before, then the .m2 directory probably won't
exist. You can create the .m2 directory in the %USERPROFILE% directory,
%USERPROFILE% is a variable, you can put it into Windows Explorer or the
command line and it will resolve to the correct location (e.g., in the
command line you can run dir %USERPROFILE% and it will list the contents of
the actual directory where the user profile is located).

For the second item, it looks like you aren't inside the directory where
your plugin resides. You need to cd to that directory and then run the
command.

On Sun, Sep 17, 2017 at 8:10 AM Amr Osama  wrote:

> First of all i want to create a jenkins plugin using eclipse having mvn
> 3.5 installed and jenkins 1.651.3 , and i just went throw you documentation
> , i cant find the first step which says
> to put some code in this path (Windows users will find them in 
> %USERPROFILE%\.m2\settings.xml),
> i cant find this path , secondly the step after is to write this command $
> mvn -DdownloadSources=true -DdownloadJavadocs=true
> -DoutputDirectory=target/eclipse-classes
> -Declipse.workspace=/path/to/workspace eclipse:eclipse
> eclipse:configure-workspace it gives me error which i will copy now
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-eclipse-plugin:2.1
> 0:eclipse (default-cli): Goal requires a project to execute but there is
> no POM
> in this directory (C:\Users\aelmetwa). Please verify you invoked Maven
> from the
> correct directory. -> [Help 1]
> so please if any body know the solution for this issue please answer.
> P.S i am new to windows OS.
> Thank you.
>
> --
> 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/63164a7d-b4f6-4150-a683-8c1b6afa7c51%40googlegroups.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/CAPiUgVdPCUkHTmZO%3DBtJp4i30D9N7DYi%2BYf%2BSwN2vTdiWbqmyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.