[GSoC 2018] Jenkins Remoting over Message Bus/Queue Introduction

[Pham Vu Tuan]

Hi all,

My name is Vu Tuan, and I am participating in Jenkins Google Summer of Code 
this year as a student. My project is Jenkins Remoting over Message 
Bus/Queue 
.
Some background about this project:

   - Current versions of Jenkins Remoting are based on the TCP protocol. If 
   it fails, the agent connection and the build fails as well. There are also 
   issues with traffic prioritization and multi-agent communications, which 
   impact Jenkins stability and scalability.
   - This project aims an update of Remoting and Jenkins in order to add 
   support of a popular message queue/bus technology (RabbitMQ or Kafka) as a 
   fault-tolerant communication layer in Jenkins.
   

Currently we are in the first phase of the project and I am going to 
implement a PoC in this first phase. The messaging technology used is 
Apache Kafka, and the deliverable for the first phase will be in Docker 
compose with multiple services and components involved. 
If you are interested, we have a gitter 
 chat for this project. The weekly 
meeting schedule is:

   - 
   
   Every Tuesday, 02:00-03:00 PM UTC
   - 
   
   Every Friday, 02:00-03:00 PM UTC
   
I am looking forward to contributing to Jenkins community this summer.

Best regards,
Pham Vu Tuan

-- 
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/22237593-3392-4a88-9267-634c8827b50b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[Stephen Connolly]

But I still think you should include the (let’s invent a different name to
show the purpose) meta-schema version

Most likely the meta-schema version will always be 1, but if you ever need
to revise then you will thank Jesse and I for suggesting it.

CaaC has a schema for generating the schema at runtime... this is the
meta-schema... it says things like: Java Maps are represented by , use
the @Symbol as a , etc

That is what the meta-schema version represents. If it changes then you are
saying the way of binding between yaml and runtime (in the general sense)
has changed.

On Tue 15 May 2018 at 19:30, nicolas de loof 
wrote:

> I've added a section on this topic in JEP-201:
> https://github.com/jenkinsci/jep/tree/master/jep/201#versioning
>
> We can already generate a json-schema you can use to validate your yaml
> file(s) before applying configuration.
> What you miss is a tool to convert jenkins-core + plugins.spec -> json
> schema.
> This is something we could package as well (something comparable to
> jenkinsfile-runner) or even provide "as a service".
>
> We could also get such a tool both generate a schema and validate your
> config, as it seems there's not  (yet) so much text editors to support
> json schema validation in yaml
>
> Would this help ?
>
> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy :
>
>> (replies inline)
>>
>> On Tue, 15 May 2018, nicolas de loof wrote:
>>
>> > 2018-05-15 0:20 GMT+02:00 Liam Newman :
>> >
>> > >
>> > > Putting all that aside (as that is not the original point of this
>> thread),
>> > > the original suggestion was to include a version field in the CasC
>> YAML.
>> > > You said it would not work because the version would have to take into
>> > > account the core version and versions of all plugins, otherwise it
>> might
>> > > break. Does that mean the CasC YAML could break _any time_  I upgrade
>> any
>> > > component? Doesn't that rather defeats the purpose of CasC?
>> > >
>> >
>> > Yes indeed. CasC doesn't have it's own model, everything is based on
>> actual
>> > java code discovery at runtime. So upgrading core or any plugin is
>> changing
>> > this model. CasC targets reproducibility and immutability use-cases. If
>> you
>> > want to upgrade anything you need to test it before.
>>
>>
>> Testing of changes between plugin versions was something I had great
>> difficulty
>> with for Groovy-scripting-based configuration, which was much more common
>> prior
>> to Configuration as Code. Do you have suggestions for administrators such
>> as
>> myself on how I might validate that my configuration YAML is
>> correct/applies
>> between any core or plugin upgrades?
>>
>> This gets to the underlying concern I had in mind when starting this
>> thread, as
>> an administrator, how will I know that my configuration applies correctly
>> between any core or plugin upgrades? My initial thought was
>> schema-versioning,
>> but I'm certainly open to other suggestions.
>>
>>
>>
>> Cheers
>>
>>
>> --
>> 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/20180515181926.GB3395%40grape.lasagna.io
>> .
>> 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/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR128o41%3D3cU056g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzTWPTBy7QJ5jJkf6r3Jqd0Wc1vocoY_uP-kB6eUCnwPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a link next to Activity in Blue Ocean

[Eric Bartusch]

Keith,

For the link itself, I only need the organization/pipeline name.  All the 
run information I process I get through the rest API.

-Eric

On Thursday, May 17, 2018 at 1:16:05 PM UTC-5, Keith Zantow wrote:
>
> Yes, you could definitely do that for a top-level page but be aware you 
> wouldn't have a pipeline run context, which I gathered that you need for 
> the functionality you're looking to provide.
>
> -Keith
>
> On Thu, May 17, 2018 at 12:08 PM, Thorsten Scherler  > wrote:
>
>> You are trying to extend the tabs that currently do not have 
>> extensionpoints. However you could use 
>> https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-dashboard/src/main/js/components/PipelinePage.jsx#L111
>>  
>> and simply provide the component for that.
>>
>> then in your *jenkins-js-extension.yaml* you implement 
>> jenkins.pipeline.detail.header.action 
>> and point to your component. 
>>  
>> If you are bound to the location then you would need to create a new 
>> Extension-point in the tabs and then implement your component.
>>
>> HTH
>>
>> salu2
>>
>> On Wednesday, May 16, 2018 at 7:28:01 PM UTC+2, Eric Bartusch wrote:
>>>
>>> Thanks for the quick reply Keith.  I'll take a look, but I doubt I have 
>>> the expertise to get it done the right way.  Regardless, at least I have a 
>>> PR I can keep an eye on!
>>>
>>> -Eric 
>>>
>>> On Wednesday, May 16, 2018 at 12:16:59 PM UTC-5, Keith Zantow wrote:

 There's a longstanding PR for doing this. I'm sorry I don't have time 
 at the moment to wrap it up, if you wanted to take it over that might 
 expedite this?

 https://github.com/jenkinsci/blueocean-plugin/pull/1541

 Cheers,
 -Keith

 On Wed, May 16, 2018 at 1:11 PM, Eric Bartusch  
 wrote:

> Hi,
>
>  
>
> I’m developing a plugin that adds a page providing additional 
> information about pipeline runs.  I’ve gotten everything working well 
> enough so far and the page is accessible, but I’d like to create a link 
> to 
> the page that users can click on.  Since it’s related to pipelines and 
> each 
> pipeline has their own version of the page, it’d make sense to put it 
> right 
> next to the Activity/Branches/Pull Requests links.  Is there an easy way 
> for me to achieve that completely within the plugin I’m writing?  I tried 
> looking at how the existing links work, but it all seems to be contained 
> in 
> the blueocean-dashboard plugin with no way to change it outside of that.
>
>  
>
> I watched the Extending Blue Ocean talk at Jenkins World 2017, and it 
> sounds like using extension points is the way to go.  I have a basic 
> understanding of extension points, but I can’t find one that is 
> appropriate 
> for what I’m trying to do.  Any tips?
>
>
>  
>
> Thanks,
>
> Eric
>
> -- 
> 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/4e8fff3d-235e-45fc-82a6-32e2ab10b7d7%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



 -- 

 Keith Zantow
 Senior Software Engineer
 CloudBees, Inc.

 [image: CloudBees-Logo.png]


 E: kza...@cloudbees.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/723965bd-0294-4a6d-85f6-8b92810304a7%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Keith Zantow
> Senior Software Engineer
> CloudBees, Inc.
>
> [image: CloudBees-Logo.png]
>
>
> E: kza...@cloudbees.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/18fbd86c-9e17-42ca-94ef-5930fff506bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a link next to Activity in Blue Ocean

[Eric Bartusch]

Hey Thorsten,

Thanks for the tip, it's a really nice workaround for the time being!  I'm 
not beholden to the right side, but would prefer it.  This gets me most of 
the way there.

-Eric

On Thursday, May 17, 2018 at 11:08:04 AM UTC-5, Thorsten Scherler wrote:
>
> You are trying to extend the tabs that currently do not have 
> extensionpoints. However you could use 
> https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-dashboard/src/main/js/components/PipelinePage.jsx#L111
>  
> and simply provide the component for that.
>
> then in your *jenkins-js-extension.yaml* you implement 
> jenkins.pipeline.detail.header.action 
> and point to your component. 
>  
> If you are bound to the location then you would need to create a new 
> Extension-point in the tabs and then implement your component.
>
> HTH
>
> salu2
>
> On Wednesday, May 16, 2018 at 7:28:01 PM UTC+2, Eric Bartusch wrote:
>>
>> Thanks for the quick reply Keith.  I'll take a look, but I doubt I have 
>> the expertise to get it done the right way.  Regardless, at least I have a 
>> PR I can keep an eye on!
>>
>> -Eric 
>>
>> On Wednesday, May 16, 2018 at 12:16:59 PM UTC-5, Keith Zantow wrote:
>>>
>>> There's a longstanding PR for doing this. I'm sorry I don't have time at 
>>> the moment to wrap it up, if you wanted to take it over that might expedite 
>>> this?
>>>
>>> https://github.com/jenkinsci/blueocean-plugin/pull/1541
>>>
>>> Cheers,
>>> -Keith
>>>
>>> On Wed, May 16, 2018 at 1:11 PM, Eric Bartusch  
>>> wrote:
>>>
 Hi,

  

 I’m developing a plugin that adds a page providing additional 
 information about pipeline runs.  I’ve gotten everything working well 
 enough so far and the page is accessible, but I’d like to create a link to 
 the page that users can click on.  Since it’s related to pipelines and 
 each 
 pipeline has their own version of the page, it’d make sense to put it 
 right 
 next to the Activity/Branches/Pull Requests links.  Is there an easy way 
 for me to achieve that completely within the plugin I’m writing?  I tried 
 looking at how the existing links work, but it all seems to be contained 
 in 
 the blueocean-dashboard plugin with no way to change it outside of that.

  

 I watched the Extending Blue Ocean talk at Jenkins World 2017, and it 
 sounds like using extension points is the way to go.  I have a basic 
 understanding of extension points, but I can’t find one that is 
 appropriate 
 for what I’m trying to do.  Any tips?


  

 Thanks,

 Eric

 -- 
 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/4e8fff3d-235e-45fc-82a6-32e2ab10b7d7%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>>
>>> Keith Zantow
>>> Senior Software Engineer
>>> CloudBees, Inc.
>>>
>>> [image: CloudBees-Logo.png]
>>>
>>>
>>> E: kza...@cloudbees.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/8d18d4af-5a80-437d-83a1-8b2c95e65625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a link next to Activity in Blue Ocean

[Keith Zantow]

Yes, you could definitely do that for a top-level page but be aware you
wouldn't have a pipeline run context, which I gathered that you need for
the functionality you're looking to provide.

-Keith

On Thu, May 17, 2018 at 12:08 PM, Thorsten Scherler  wrote:

> You are trying to extend the tabs that currently do not have
> extensionpoints. However you could use https://github.com/jenkinsci/
> blueocean-plugin/blob/master/blueocean-dashboard/src/main/
> js/components/PipelinePage.jsx#L111 and simply provide the component for
> that.
>
> then in your *jenkins-js-extension.yaml* you implement
> jenkins.pipeline.detail.header.action and point to your component.
>
> If you are bound to the location then you would need to create a new
> Extension-point in the tabs and then implement your component.
>
> HTH
>
> salu2
>
> On Wednesday, May 16, 2018 at 7:28:01 PM UTC+2, Eric Bartusch wrote:
>>
>> Thanks for the quick reply Keith.  I'll take a look, but I doubt I have
>> the expertise to get it done the right way.  Regardless, at least I have a
>> PR I can keep an eye on!
>>
>> -Eric
>>
>> On Wednesday, May 16, 2018 at 12:16:59 PM UTC-5, Keith Zantow wrote:
>>>
>>> There's a longstanding PR for doing this. I'm sorry I don't have time at
>>> the moment to wrap it up, if you wanted to take it over that might expedite
>>> this?
>>>
>>> https://github.com/jenkinsci/blueocean-plugin/pull/1541
>>>
>>> Cheers,
>>> -Keith
>>>
>>> On Wed, May 16, 2018 at 1:11 PM, Eric Bartusch 
>>> wrote:
>>>
 Hi,



 I’m developing a plugin that adds a page providing additional
 information about pipeline runs.  I’ve gotten everything working well
 enough so far and the page is accessible, but I’d like to create a link to
 the page that users can click on.  Since it’s related to pipelines and each
 pipeline has their own version of the page, it’d make sense to put it right
 next to the Activity/Branches/Pull Requests links.  Is there an easy way
 for me to achieve that completely within the plugin I’m writing?  I tried
 looking at how the existing links work, but it all seems to be contained in
 the blueocean-dashboard plugin with no way to change it outside of that.



 I watched the Extending Blue Ocean talk at Jenkins World 2017, and it
 sounds like using extension points is the way to go.  I have a basic
 understanding of extension points, but I can’t find one that is appropriate
 for what I’m trying to do.  Any tips?




 Thanks,

 Eric

 --
 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/ms
 gid/jenkinsci-dev/4e8fff3d-235e-45fc-82a6-32e2ab10b7d7%40goo
 glegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>>
>>> Keith Zantow
>>> Senior Software Engineer
>>> CloudBees, Inc.
>>>
>>> [image: CloudBees-Logo.png]
>>>
>>>
>>> E: kza...@cloudbees.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/723965bd-0294-4a6d-85f6-8b92810304a7%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Keith Zantow
Senior Software Engineer
CloudBees, Inc.

[image: CloudBees-Logo.png]


E: kzan...@cloudbees.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/CAJTHQaGdYnrQRo94X0cU%3DWahvbD6pH%2BF1CAFsGTjgMtnPwrKig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upcoming JEP for usage of Incrementals repository

[Jesse Glick]

On Thu, May 17, 2018 at 5:45 AM, James Nord  wrote:
> say I depended on BlueOcean.
> If I tried to check that out and build it I am left with something that is
> conmpletely dead on arival as it produces garbage on windows.

Not sure what that is about, but I guess someone should be fixing it?

> Is the CI the only place that can deploy them?

Daniel would know the actual authorization settings for the
repository, but CI (or, technically, an Azure function triggered by
CI) is the only thing that is _expected_ to deploy these artifacts.

> If building an incremental from a PR then the hash is likely not enough (as
> that may/will not be pushed back upstream)

You can check out a commit hash from a fork. GitHub does not really care.

> many people (maven repo admins) when
> asked to add a mirror of a upstream release will just add it in to the main
> mirror

Well, tell them not to?

> I can create a release can call it whatever I want and deploy it (subject to
> access control on the repo server).

Of course that is physically _possible_, just as deleting release
artifacts is physically possible. :-/ Maven does not enforce these
things.

> so if you are making these release canditates pass the full suite, you
> are then using them in production via promotion, but the version in them is
> still a release candidate?  the above is just confusing?

There needs to be a consistent version number the whole way through
the Pipeline, so “RC” is as good as any. It would be more confusing
(and far harder) to retroactively relabel the same artifact with
another version.

-- 
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/CANfRfr3sGE1w7eL%3DTCV5TMF3A%2BV6RxhFqGRi-cwzeojZ3Z1mNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Plugin development : extension to add custom options in declarative pipeline

[Bill Dennis]

I am developing a Jenkins pipeline plugin that provides some custom block 
scoped steps something like this:

withFoo( fooParams ) {
   // Some code block that uses the declared "Foo" thing
}


My *withFoo* step creates some object "Foo" that is made available in the 
code block to my other custom steps.

I have all this sort of thing working with custom block-scoped steps and 
simple steps and it is going well in my declarative pipelines and providing 
the functionality I need.

However the "foo" is only available in a pipeline code block in a single 
declarative stage and it won't be available in a post handler unless I 
re-declare it ( think).

I am envisioning some scenarios where I want my "Foo" object to be 
available to the whole job in the pipeline context using something like 
"options" (or possibly at the stage options level).

So I am looking at the possibility of some custom option like this:

pipeline {

 agent none

 options {
 // Declare the Foo
 foo(fooParams)
 }


 // Rest of pipeline uses the Foo in stages or post sections
}


To give some context, the "Foo" is some sort of connection to a remote system 
so it could be expensive to keep tearing it down and re-establishing it.


Is there a way to provide custom options like this to have an object is created 
and put in the pipeline context for the whole pipeline and can be consumed by 
my other custom steps?


I had a look at the existing Jenkins extension point documents and around some 
plugins in GitHub but I cannot tell whether these options are generally 
extendable in this way.


Thanks for any suggestions or pointers anyone here may have!


--Bill

-- 
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/92d6270f-7da0-4aea-b7ba-5f41eb1be190%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a link next to Activity in Blue Ocean

[Thorsten Scherler]

You are trying to extend the tabs that currently do not have 
extensionpoints. However you could use 
https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-dashboard/src/main/js/components/PipelinePage.jsx#L111
 
and simply provide the component for that.

then in your *jenkins-js-extension.yaml* you implement 
jenkins.pipeline.detail.header.action 
and point to your component. 
 
If you are bound to the location then you would need to create a new 
Extension-point in the tabs and then implement your component.

HTH

salu2

On Wednesday, May 16, 2018 at 7:28:01 PM UTC+2, Eric Bartusch wrote:
>
> Thanks for the quick reply Keith.  I'll take a look, but I doubt I have 
> the expertise to get it done the right way.  Regardless, at least I have a 
> PR I can keep an eye on!
>
> -Eric 
>
> On Wednesday, May 16, 2018 at 12:16:59 PM UTC-5, Keith Zantow wrote:
>>
>> There's a longstanding PR for doing this. I'm sorry I don't have time at 
>> the moment to wrap it up, if you wanted to take it over that might expedite 
>> this?
>>
>> https://github.com/jenkinsci/blueocean-plugin/pull/1541
>>
>> Cheers,
>> -Keith
>>
>> On Wed, May 16, 2018 at 1:11 PM, Eric Bartusch  
>> wrote:
>>
>>> Hi,
>>>
>>>  
>>>
>>> I’m developing a plugin that adds a page providing additional 
>>> information about pipeline runs.  I’ve gotten everything working well 
>>> enough so far and the page is accessible, but I’d like to create a link to 
>>> the page that users can click on.  Since it’s related to pipelines and each 
>>> pipeline has their own version of the page, it’d make sense to put it right 
>>> next to the Activity/Branches/Pull Requests links.  Is there an easy way 
>>> for me to achieve that completely within the plugin I’m writing?  I tried 
>>> looking at how the existing links work, but it all seems to be contained in 
>>> the blueocean-dashboard plugin with no way to change it outside of that.
>>>
>>>  
>>>
>>> I watched the Extending Blue Ocean talk at Jenkins World 2017, and it 
>>> sounds like using extension points is the way to go.  I have a basic 
>>> understanding of extension points, but I can’t find one that is appropriate 
>>> for what I’m trying to do.  Any tips?
>>>
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> -- 
>>> 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/4e8fff3d-235e-45fc-82a6-32e2ab10b7d7%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>>
>> Keith Zantow
>> Senior Software Engineer
>> CloudBees, Inc.
>>
>> [image: CloudBees-Logo.png]
>>
>>
>> E: kza...@cloudbees.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/723965bd-0294-4a6d-85f6-8b92810304a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upcoming JEP for usage of Incrementals repository

[R. Tyler Croy]

(replies inline)

On Thu, 17 May 2018, Baptiste Mathus wrote:

> Le mer. 16 mai 2018 à 13:14, James Nord  a écrit :
> 
> > So the objection I have is that as it stands in JEP-305 the versions are
> > releases and these are expected to be garbage collected.
> >
> > Anyone also wanting to consume incrementals via a proxy would need to
> > write tooling to garbage collect releases and there is also the Maven
> > principal that you never garbage collect releases, let alone the impact
> > this will have on other pipelines that do canary builds by picking up the
> > latest **release** of a artifacts/plugins in order to do bleeding edge
> > testing in our pipelines. And that is also discounting the ability once it
> > is in our mirror for things to accidentally depend on these releases.
> >
> I must confess I had missed reading related IEP-9 when reading JEP-305. I
> do agree releases should normally be kept basically forever.
> Now nowadays Nexus, for one, had added a dedicated Scheduled Task
> 
> to
> clean up also releases "Remove Releases From Repository" IIUC (I never used
> it myself, but did use a lot the other "Remove Snapshots From Repository").
> 
> So yes, this shows IMO a pretty usage of Maven, but it shows at least
> people using Nexus (and I suspect Artifactory can do the same) would
> normally *not* have to handle that themselves.
> 
> Now, about the whole artifact collection idea that I had missed:
> 
> * I think this part in IEP-9 could be just ditched overall, for now at
> least. As Jesse nicely phrases it below: "until storage costs start to
> raise eyebrows". IIUC what Daniel told me once, as it stands currently:
> anyway we never ever remove *any* artifacts from Artifactory, SNAPSHOTs are
> already kept forever. So I guess the eyebrow would have raised long ago if
> this was an issue. OK, this could grow possibly faster once Incrementals
> starts to get used more and more, we /might/ want to revisit then.
> ** (A possible way to revisit could for instance to better differentiate
> PRs from merged commits, and maybe more aggressively actually clean up
> artifacts coming from PRs).


There is no garbage collection currently implemneted with IEP-9.

There is simply no comparable usage today of our Artifactory environment in
terms of capacity planning. While we may not remove SNAPSHOTs today,
ci.jenkins.io isn't publishing those. And in fact, nothing compares to
publishing artifacts for every single pull request of every plugin (400+),
libraries (a few dozen), and core in ci.jenkins.io.

We're looking at many hundreds of megabytes of data per day uploading into
Artifactory, a hosted solution with somewhat unclear limtis (we basically will
fill it up until JFrog says "hey wtf m8"").


So basically, I'm not concerned with what "Maven best practices" prescribe, I
do not want the expectation to be that incremental built releases are going to
be kept indefinitely. Only so much disk space on the planet :)


Cheers

-- 
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/20180517141801.GH3395%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Request to be made a maintainer of audit-trail-plugin

[Oleg Nenashev]

Hi Tomasz,

I granted you permissions. You should receive an invitation to the GitHub
organization soon. In order to release the plugin, you will also need to
update permissions via
https://github.com/jenkins-infra/repository-permissions-updater (please
reference this thread in the pull request).

Welcome aboard and thanks for your patience!

Best regards,
Oleg Nenashev


On Thu, May 17, 2018 at 2:46 PM, Tomasz Sęk  wrote:

> Hi Oleg,
>
> My jenkins id is "tsek".
>
> Regards,
> Tomasz
>
> czw., 17 maj 2018, 14:25 użytkownik Oleg Nenashev 
> napisał:
>
>> Hi Tomasz,
>>
>> Also, what is your Jenkins JIRA id?
>>
>> Thanks in advance,
>> Oleg
>>
>> On Thursday, May 17, 2018 at 5:18:56 AM UTC+2, Tomasz Sęk wrote:
>>>
>>> Hi Oleg,
>>>
>>> Yes I'm still interesting, my github username is "tomaszsek".
>>>
>>> Regards,
>>> Tomasz
>>>
>>>
>>> śr., 16 maj 2018, 23:30 użytkownik Oleg Nenashev 
>>> napisał:
>>>
 Hi Tomasz,

 We have got an approval from the maintainer, so we can transfer the
 permissions if you are still interested.

 Best regards,
 Oleg

 On Wednesday, May 16, 2018 at 12:54:31 PM UTC+2, ogondza wrote:
>
> My apology for the delay. I do not object if someone takes over the
> maintenance of this unmaintained plugin. Thanks!
>
> --
> oliver
>
 --
 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/16049fbb-ecff-416a-96e4-4e9432ab1558%
 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/0bd55770-d6d0-4777-a3fa-ed3990beacff%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/7zGtQYa56Pk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAOGMO0uimoJuxa5PBPUhRgDrT3vPe
> qnQLCGy5OOZQ8T-Ve8W_A%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/CAPfivLCt6XzAxDZYVHZsM5nyRmLt-gp-KS%3D1wJadvTf-k%3Dzyhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to be made a maintainer of audit-trail-plugin

[Tomasz Sęk]

Hi Oleg,

My jenkins id is "tsek".

Regards,
Tomasz

czw., 17 maj 2018, 14:25 użytkownik Oleg Nenashev 
napisał:

> Hi Tomasz,
>
> Also, what is your Jenkins JIRA id?
>
> Thanks in advance,
> Oleg
>
> On Thursday, May 17, 2018 at 5:18:56 AM UTC+2, Tomasz Sęk wrote:
>>
>> Hi Oleg,
>>
>> Yes I'm still interesting, my github username is "tomaszsek".
>>
>> Regards,
>> Tomasz
>>
>>
>> śr., 16 maj 2018, 23:30 użytkownik Oleg Nenashev 
>> napisał:
>>
>>> Hi Tomasz,
>>>
>>> We have got an approval from the maintainer, so we can transfer the
>>> permissions if you are still interested.
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Wednesday, May 16, 2018 at 12:54:31 PM UTC+2, ogondza wrote:

 My apology for the delay. I do not object if someone takes over the
 maintenance of this unmaintained plugin. Thanks!

 --
 oliver

>>> --
>>> 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/16049fbb-ecff-416a-96e4-4e9432ab1558%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/0bd55770-d6d0-4777-a3fa-ed3990beacff%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/CAOGMO0uimoJuxa5PBPUhRgDrT3vPeqnQLCGy5OOZQ8T-Ve8W_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to be made a maintainer of audit-trail-plugin

[Oleg Nenashev]

Hi Tomasz,

Also, what is your Jenkins JIRA id?

Thanks in advance,
Oleg

On Thursday, May 17, 2018 at 5:18:56 AM UTC+2, Tomasz Sęk wrote:
>
> Hi Oleg,
>
> Yes I'm still interesting, my github username is "tomaszsek".
>
> Regards,
> Tomasz
>
>
> śr., 16 maj 2018, 23:30 użytkownik Oleg Nenashev  > napisał:
>
>> Hi Tomasz,
>>
>> We have got an approval from the maintainer, so we can transfer the 
>> permissions if you are still interested.
>>
>> Best regards,
>> Oleg
>>
>> On Wednesday, May 16, 2018 at 12:54:31 PM UTC+2, ogondza wrote:
>>>
>>> My apology for the delay. I do not object if someone takes over the 
>>> maintenance of this unmaintained plugin. Thanks!
>>>
>>> --
>>> oliver
>>>
>> -- 
>> 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/16049fbb-ecff-416a-96e4-4e9432ab1558%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/0bd55770-d6d0-4777-a3fa-ed3990beacff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upcoming JEP for usage of Incrementals repository

[James Nord]

On Wednesday, May 16, 2018 at 5:16:56 PM UTC+1, Jesse Glick wrote:
>
> My response would mostly follow Daniel’s but I will add more 
> background—something I can write up into a subsection of 
>
>
> https://github.com/jenkinsci/jep/blob/master/jep/305/README.adoc#other-version-schemes
>  
>
> once the dust settles. 
>
> James Nord & Stephen Connolly wrote: 
> > as it stands in JEP-305 the versions are 
> > releases and these are expected to be garbage collected. 
>
> Technically this is from IEP-9, but as that attracted little notice 
> (indeed I only stumbled across it after it was finalized and 
> implemented), it makes sense to discuss in the context of JEP-305. 
>
>
So this is the big sticking point and what Stephen and I are mostly 
concerned about.
If that little "gem" was to be removed then I think all other issues 
(except for disk usage!) would just fall by the wayside (and you can skip 
the rest of this message and get some time back to )

 

> > Anyone also wanting to consume incrementals via a proxy would need to 
> write 
> > tooling to garbage collect releases 
>
> I think GC is the crux of the question. 


Yes it is.

 

> For the record, I would have 
> recommended a rather more conservative collection schedule in IEP-9 
> (basically keep everything until storage costs start to raise 
> eyebrows); I am not actually sure whether the collection scheme was 
> even implemented, or if so, whether this is custom tooling or some 
> stock feature of Artifactory. Daniel could speak to that. 
>
> There are several things to consider about GC, and none have anything 
> to do with whether the version number happens to end in `-SNAPSHOT` or 
> not, so adding that suffix solves no practical problem. 
>

Actually it does, as SNAPSHOTs are expected be be garbage collected, 
releases are not, and that is fundamental to the Maven philosophy.
 

First, how likely is it that a newly run build of a downstream 
> component will refer to an incremental version that has been expired 
> from Artifactory? This is hard to know until JEP-305 gets broader 
> usage, but my expectation would be that new builds will usually refer 
> to pretty recent dependencies, especially if something like 
> JENKINS-47498 is adopted so that merely picking the latest parent POM 
> for a component will switch `` to recent 
> `master` commits (or MRP-tagged releases). There will always be some 
> cases when an old line of development is suddenly resurrected and the 
> developer declines to start by refreshing dependencies: 
>
> mvn incrementals:update 
>
> Second, what is the impact of expiration? For builds on ci.jenkins.io, 
> possibly none: even though local repositories will typically start 
> empty, the build will download incremental releases from 
>
> https://repo.azure.jenkins.io/incrementals/ 
>
> which (Olivier correct me if I am mistaken) uses an LRU cache. 
> Therefore even an old dependency will remain in the cache indefinitely 
> if it continues to be used actively in builds. You could still get a 
> broken build in cases like that mentioned above, where the old 
> dependency is used by a hitherto-dormant branch of some downstream 
> component that has not gotten a refresh. 
>

Ahh so now you have the debuging environments when things behave a little 
differently.  Ie a unit test fails on CI, and you can not even build the 
thing locally anymore.  This is not a good thing for a CI server, and you 
have now replaced "it works on my machine" with "well it works on CI"


Third, can the release be reconstructed? For use from local developer 
> builds, pretty easily: just check out the specified commit of the 
> upstream component and 
>
> mvn -DskipTests -Dset.changelist clean install 
>

Alas I am Skeptical about this.  For exapmple say I depended on BlueOcean.
If I tried to check that out and build it I am left with something that is 
conmpletely dead on arival as it produces garbage on windows.And the 
argument that the CI also does a build on windows doesn't mean that that 
build is any good, BO builds on windows, and the unit tests pass, but the 
result is garbage, so unless you run the ATH on windows and Linux (which 
you don't)

I actually hit a bug on a closed source plugin yesterday that the build 
failed on windows (that dreaded npm..)

You may also at points be able to replace Windows with Mac or some Linux 
(or even a specific version of the JDK - which has also caused builds to 
break in the past, or even maven).  incrementals does not fix the 
environment so reproducability on a different environment is never 
guaranteed (and hence why you should not mess with releases because whilst 
you hope the build is reproducable you are probably not recording 
everything you need to know about the env in order to guarantee it)

 

> For use from CI builds, currently there is no mechanism in place to 
> re`deploy` old incremental releases on demand, such as jitpack.io 
> provides. One idea however is that we could copy 

Re: Upcoming JEP for usage of Incrementals repository

[Baptiste Mathus]

Le mer. 16 mai 2018 à 13:14, James Nord  a écrit :

> So the objection I have is that as it stands in JEP-305 the versions are
> releases and these are expected to be garbage collected.
>
> Anyone also wanting to consume incrementals via a proxy would need to
> write tooling to garbage collect releases and there is also the Maven
> principal that you never garbage collect releases, let alone the impact
> this will have on other pipelines that do canary builds by picking up the
> latest **release** of a artifacts/plugins in order to do bleeding edge
> testing in our pipelines. And that is also discounting the ability once it
> is in our mirror for things to accidentally depend on these releases.
>
I must confess I had missed reading related IEP-9 when reading JEP-305. I
do agree releases should normally be kept basically forever.
Now nowadays Nexus, for one, had added a dedicated Scheduled Task

to
clean up also releases "Remove Releases From Repository" IIUC (I never used
it myself, but did use a lot the other "Remove Snapshots From Repository").

So yes, this shows IMO a pretty usage of Maven, but it shows at least
people using Nexus (and I suspect Artifactory can do the same) would
normally *not* have to handle that themselves.

Now, about the whole artifact collection idea that I had missed:

* I think this part in IEP-9 could be just ditched overall, for now at
least. As Jesse nicely phrases it below: "until storage costs start to
raise eyebrows". IIUC what Daniel told me once, as it stands currently:
anyway we never ever remove *any* artifacts from Artifactory, SNAPSHOTs are
already kept forever. So I guess the eyebrow would have raised long ago if
this was an issue. OK, this could grow possibly faster once Incrementals
starts to get used more and more, we /might/ want to revisit then.
** (A possible way to revisit could for instance to better differentiate
PRs from merged commits, and maybe more aggressively actually clean up
artifacts coming from PRs).
* Anyway, people using artifacts for in-house purposes would (should) have
put an MRM in place. So they wouldn't even see any issue if an artifact is
ever deleted upstream.
* We must indeed clearly document that people using Incrementals releases
and repository must understand they're adopting a special pattern, and I
guess as this is indeed not exposed automatically behing /public or
/releases, this is an explicit action that one must not do lightly.
  So BTW I think
https://github.com/jenkins-infra/iep/blob/master/iep-009/README.adoc#existing-maven-repository
ought to be completed with a precision saying we *really* must not ever
expose http://repo.jenkins-ci.org/incrementals behind
http://repo.jenkins-ci.org/public or some other virtual group repository.
Keep it separated so that it requires an explicit thinking/action to get
used.

-- Baptiste

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

Re: Error

[Baptiste Mathus]

Hello,
Answered there, let's keep the discussion where the issue happens generally.

Cheers

Le jeu. 17 mai 2018 à 09:13, Rahul Pure  a écrit :

> Hi
>
> getting this error while apply for pull request to publish the plugin
>
>
> [-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ]
> Running shell script
>
> + /home/jenkins/tools/hudson.model.JDK/jdk8/bin/java -DdryRun=true
> -DdefinitionsDir=/home/jenkins/workspace/-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ/permissions
> -DartifactoryApiTempDir=/home/jenkins/workspace/-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ/json
> -DartifactoryUserNamesJsonListUrl=
> http://reports.jenkins.io/reports/artifactory-ldap-users-report.json
> -Djava.util.logging.SimpleFormatter.format=%1-%1-%1 %1:%1:%1 %4: %5%6%n
> -jar
> target/repository-permissions-updater-1.0-SNAPSHOT-bin/repository-permissions-updater-1.0-SNAPSHOT.jar
>
> Running in dry run mode
>
> Exception in thread "main" java.lang.IllegalStateException: User name not
> known to Artifactory: toranainc
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
> my yml file is like that
> ---
> name: "icedq"
> github: "jenkinsci/icedq-plugin"
> paths:
> - "com/icedq/ci/plugin/icedq"
> developers:
> - "devlopertoranainc"
> - "toranainc"
> - "DevloperToranaInc"
>
> file name plugin-icedq.yml
>
> 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/cb8bd23a-5d67-46a6-bc3d-03b997eb1c74%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/CANWgJS5FxZjVpAa%3Da4_GELUW%3DwGd4JsNDy1GtMX1uMK70AemiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Error

[Rahul Pure]

Hi 

getting this error while apply for pull request to publish the plugin 


[-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ]
 
Running shell script

+ /home/jenkins/tools/hudson.model.JDK/jdk8/bin/java -DdryRun=true 
-DdefinitionsDir=/home/jenkins/workspace/-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ/permissions
 
-DartifactoryApiTempDir=/home/jenkins/workspace/-permissions-updater_PR-700-LYD3MWGHXRV7JB35ISKXIBYKVCKRHAVJ2HUMAAWJKR3IAK6UPXWQ/json
 
-DartifactoryUserNamesJsonListUrl=http://reports.jenkins.io/reports/artifactory-ldap-users-report.json
 
-Djava.util.logging.SimpleFormatter.format=%1-%1-%1 %1:%1:%1 %4: %5%6%n 
-jar 
target/repository-permissions-updater-1.0-SNAPSHOT-bin/repository-permissions-updater-1.0-SNAPSHOT.jar

Running in dry run mode

Exception in thread "main" java.lang.IllegalStateException: User name not 
known to Artifactory: toranainc

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

my yml file is like that 
---
name: "icedq"
github: "jenkinsci/icedq-plugin"
paths:
- "com/icedq/ci/plugin/icedq"
developers:
- "devlopertoranainc"
- "toranainc"
- "DevloperToranaInc"

file name plugin-icedq.yml

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/cb8bd23a-5d67-46a6-bc3d-03b997eb1c74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.