date:20190226

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread Mykola Nikishov

nicolas de loof 
writes:

> but docker images seems to me a way better solution to cover the same
> need, and this "tool installer" feature is just a hack-ish legacy we
> should deprecate.

Are you proposing to remove tool installer completely or is it about JDK
tool installer only?

If the former, to me this looks like maven vs freestyle project type
issue (when you have Maven project, of course) but moving in opposite
direction, from generic to concrete one. Tool installer is a generic
installer that supports installation of different tools. Docker images
support only a subset of these use-cases.

> Le mar. 26 févr. 2019 à 15:44, Slide
> a écrit :
>
>> How many people use the automatic installation, is there a way to track
>> that? Would it kill someone's usage model to remove this feature? It seems
>> to me to be fairly unsustainable.
>>
>> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus  wrote:
>>
>>> Hey Martijn,
>>>
>>> Thanks for chiming in. I already have commented there in the JIRA, but
>>> asking here since it seems at this stage better suited in a discussion
>>> place: do you have an opinion/idea about whether, and how long, it will be
>>> tolerated that certain IPs download the same JDK binaries from
>>> adoptopenjdk.net  like dozens or hundreds
>>> of time a day? I mean: how is the bandwidth consumption handled on
>>> adoptopenjdk.net? Isn"t there a risk that some users be banned from
>>> downloading from there if they suck for instance +100GB, or much more, of
>>> bandwidth a day?
>>>
>>> I'm asking because I've been arguing there and some other places that
>>> anyway this feature has always been problematic. And I tend to think it's
>>> cool for demos, but that normal usages shouldn't rely on downloading
>>> binaries from an external source forever, for a variety of reasons I've
>>> listed in the JIRA issue linked previously.

-- 
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/87h8cqff9u.fsf%40think.
For more options, visit https://groups.google.com/d/optout.

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread nicolas de loof

I assume this would require a JEP ?

Le mar. 26 févr. 2019 à 17:32, Slide  a écrit :

> +1 on deprecation
>
> On Tue, Feb 26, 2019 at 9:08 AM nicolas de loof 
> wrote:
>
>> I don't know if we have any metric for this purpose, but docker images
>> seems to me a way better solution to cover the same need, and this "tool
>> installer" feature is just a hack-ish legacy we should deprecate.
>>
>> Le mar. 26 févr. 2019 à 15:44, Slide  a écrit :
>>
>>> How many people use the automatic installation, is there a way to track
>>> that? Would it kill someone's usage model to remove this feature? It seems
>>> to me to be fairly unsustainable.
>>>
>>> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus  wrote:
>>>
 Hey Martijn,

 Thanks for chiming in. I already have commented there in the JIRA, but
 asking here since it seems at this stage better suited in a discussion
 place: do you have an opinion/idea about whether, and how long, it will be
 tolerated that certain IPs download the same JDK binaries from
 adoptopenjdk.net  like dozens or
 hundreds of time a day? I mean: how is the bandwidth consumption handled on
 adoptopenjdk.net? Isn"t there a risk that some users be banned from
 downloading from there if they suck for instance +100GB, or much more, of
 bandwidth a day?

 I'm asking because I've been arguing there and some other places that
 anyway this feature has always been problematic. And I tend to think it's
 cool for demos, but that normal usages shouldn't rely on downloading
 binaries from an external source forever, for a variety of reasons I've
 listed in the JIRA issue linked previously.

 Thanks! :)

 Le dim. 24 févr. 2019 à 21:17, Martijn Verburg <
 martijnverb...@gmail.com> a écrit :

> Hi all,
>
> I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro
> now (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et
> al are collaborating there).  Let me know if you need any help connecting
> to our API:
>
> https://api.adoptopenjdk.net
>
> Cheers,
> Martijn
>
>
> On Sat, 23 Feb 2019 at 18:14, Sverre Moe  wrote:
>
>> Thanks for the link. Good to see that they are looking into it. Hope
>> it doesn't take to long.
>>
>> fredag 22. februar 2019 15.38.57 UTC+1 skrev Devin Nusbaum følgende:
>>>
>>> There is some relevant discussion in
>>> https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be
>>> interesting to you.
>>>
>>> On Feb 22, 2019, at 09:20, Sverre Moe  wrote:
>>>
>>> Now that Oracle has shut down any commercial use of their JDK,
>>> Jenkins should add option to download JDK from AdoptOpenJDK
>>>
>>> Install automatically
>>> Extract *.zip/*.tar.gz
>>> Install from java.sun.com
>>> Run Batch Command
>>> Run Shell Command
>>>
>>> Now that the JDK from Oracle cannot be used in production we need
>>> another source.
>>>
>>> Install from AdoptOpenJDK
>>> https://adoptopenjdk.net/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%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 Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%40mail.gmail.com
>

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread Slide

+1 on deprecation

On Tue, Feb 26, 2019 at 9:08 AM nicolas de loof 
wrote:

> I don't know if we have any metric for this purpose, but docker images
> seems to me a way better solution to cover the same need, and this "tool
> installer" feature is just a hack-ish legacy we should deprecate.
>
> Le mar. 26 févr. 2019 à 15:44, Slide  a écrit :
>
>> How many people use the automatic installation, is there a way to track
>> that? Would it kill someone's usage model to remove this feature? It seems
>> to me to be fairly unsustainable.
>>
>> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus  wrote:
>>
>>> Hey Martijn,
>>>
>>> Thanks for chiming in. I already have commented there in the JIRA, but
>>> asking here since it seems at this stage better suited in a discussion
>>> place: do you have an opinion/idea about whether, and how long, it will be
>>> tolerated that certain IPs download the same JDK binaries from
>>> adoptopenjdk.net  like dozens or
>>> hundreds of time a day? I mean: how is the bandwidth consumption handled on
>>> adoptopenjdk.net? Isn"t there a risk that some users be banned from
>>> downloading from there if they suck for instance +100GB, or much more, of
>>> bandwidth a day?
>>>
>>> I'm asking because I've been arguing there and some other places that
>>> anyway this feature has always been problematic. And I tend to think it's
>>> cool for demos, but that normal usages shouldn't rely on downloading
>>> binaries from an external source forever, for a variety of reasons I've
>>> listed in the JIRA issue linked previously.
>>>
>>> Thanks! :)
>>>
>>> Le dim. 24 févr. 2019 à 21:17, Martijn Verburg 
>>> a écrit :
>>>
 Hi all,

 I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro
 now (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et
 al are collaborating there).  Let me know if you need any help connecting
 to our API:

 https://api.adoptopenjdk.net

 Cheers,
 Martijn


 On Sat, 23 Feb 2019 at 18:14, Sverre Moe  wrote:

> Thanks for the link. Good to see that they are looking into it. Hope
> it doesn't take to long.
>
> fredag 22. februar 2019 15.38.57 UTC+1 skrev Devin Nusbaum følgende:
>>
>> There is some relevant discussion in
>> https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be
>> interesting to you.
>>
>> On Feb 22, 2019, at 09:20, Sverre Moe  wrote:
>>
>> Now that Oracle has shut down any commercial use of their JDK,
>> Jenkins should add option to download JDK from AdoptOpenJDK
>>
>> Install automatically
>> Extract *.zip/*.tar.gz
>> Install from java.sun.com
>> Run Batch Command
>> Run Shell Command
>>
>> Now that the JDK from Oracle cannot be used in production we need
>> another source.
>>
>> Install from AdoptOpenJDK
>> https://adoptopenjdk.net/
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to jenkinsci-use...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%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 Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%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 Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%40mail.gmail.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

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

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread nicolas de loof

I don't know if we have any metric for this purpose, but docker images
seems to me a way better solution to cover the same need, and this "tool
installer" feature is just a hack-ish legacy we should deprecate.

Le mar. 26 févr. 2019 à 15:44, Slide  a écrit :

> How many people use the automatic installation, is there a way to track
> that? Would it kill someone's usage model to remove this feature? It seems
> to me to be fairly unsustainable.
>
> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus  wrote:
>
>> Hey Martijn,
>>
>> Thanks for chiming in. I already have commented there in the JIRA, but
>> asking here since it seems at this stage better suited in a discussion
>> place: do you have an opinion/idea about whether, and how long, it will be
>> tolerated that certain IPs download the same JDK binaries from
>> adoptopenjdk.net  like dozens or hundreds
>> of time a day? I mean: how is the bandwidth consumption handled on
>> adoptopenjdk.net? Isn"t there a risk that some users be banned from
>> downloading from there if they suck for instance +100GB, or much more, of
>> bandwidth a day?
>>
>> I'm asking because I've been arguing there and some other places that
>> anyway this feature has always been problematic. And I tend to think it's
>> cool for demos, but that normal usages shouldn't rely on downloading
>> binaries from an external source forever, for a variety of reasons I've
>> listed in the JIRA issue linked previously.
>>
>> Thanks! :)
>>
>> Le dim. 24 févr. 2019 à 21:17, Martijn Verburg 
>> a écrit :
>>
>>> Hi all,
>>>
>>> I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro
>>> now (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et
>>> al are collaborating there).  Let me know if you need any help connecting
>>> to our API:
>>>
>>> https://api.adoptopenjdk.net
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>> On Sat, 23 Feb 2019 at 18:14, Sverre Moe  wrote:
>>>
 Thanks for the link. Good to see that they are looking into it. Hope it
 doesn't take to long.

 fredag 22. februar 2019 15.38.57 UTC+1 skrev Devin Nusbaum følgende:
>
> There is some relevant discussion in
> https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be
> interesting to you.
>
> On Feb 22, 2019, at 09:20, Sverre Moe  wrote:
>
> Now that Oracle has shut down any commercial use of their JDK, Jenkins
> should add option to download JDK from AdoptOpenJDK
>
> Install automatically
> Extract *.zip/*.tar.gz
> Install from java.sun.com
> Run Batch Command
> Run Shell Command
>
> Now that the JDK from Oracle cannot be used in production we need
> another source.
>
> Install from AdoptOpenJDK
> https://adoptopenjdk.net/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-use...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%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 Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%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 Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread Slide

How many people use the automatic installation, is there a way to track
that? Would it kill someone's usage model to remove this feature? It seems
to me to be fairly unsustainable.

On Tue, Feb 26, 2019, 06:22 Baptiste Mathus  wrote:

> Hey Martijn,
>
> Thanks for chiming in. I already have commented there in the JIRA, but
> asking here since it seems at this stage better suited in a discussion
> place: do you have an opinion/idea about whether, and how long, it will be
> tolerated that certain IPs download the same JDK binaries from
> adoptopenjdk.net  like dozens or hundreds
> of time a day? I mean: how is the bandwidth consumption handled on
> adoptopenjdk.net? Isn"t there a risk that some users be banned from
> downloading from there if they suck for instance +100GB, or much more, of
> bandwidth a day?
>
> I'm asking because I've been arguing there and some other places that
> anyway this feature has always been problematic. And I tend to think it's
> cool for demos, but that normal usages shouldn't rely on downloading
> binaries from an external source forever, for a variety of reasons I've
> listed in the JIRA issue linked previously.
>
> Thanks! :)
>
> Le dim. 24 févr. 2019 à 21:17, Martijn Verburg 
> a écrit :
>
>> Hi all,
>>
>> I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro now
>> (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et al
>> are collaborating there).  Let me know if you need any help connecting to
>> our API:
>>
>> https://api.adoptopenjdk.net
>>
>> Cheers,
>> Martijn
>>
>>
>> On Sat, 23 Feb 2019 at 18:14, Sverre Moe  wrote:
>>
>>> Thanks for the link. Good to see that they are looking into it. Hope it
>>> doesn't take to long.
>>>
>>> fredag 22. februar 2019 15.38.57 UTC+1 skrev Devin Nusbaum følgende:

 There is some relevant discussion in
 https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be
 interesting to you.

 On Feb 22, 2019, at 09:20, Sverre Moe  wrote:

 Now that Oracle has shut down any commercial use of their JDK, Jenkins
 should add option to download JDK from AdoptOpenJDK

 Install automatically
 Extract *.zip/*.tar.gz
 Install from java.sun.com
 Run Batch Command
 Run Shell Command

 Now that the JDK from Oracle cannot be used in production we need
 another source.

 Install from AdoptOpenJDK
 https://adoptopenjdk.net/

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%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 Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%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 Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS5NhKXyvHaJinOkz4P9BpxPVC7eRi%2BzYaDbR_TFcVOfEQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.

Re: Use AdoptOpenJDK as JDK Tool download source

2019-02-26 Thread Baptiste Mathus

Hey Martijn,

Thanks for chiming in. I already have commented there in the JIRA, but
asking here since it seems at this stage better suited in a discussion
place: do you have an opinion/idea about whether, and how long, it will be
tolerated that certain IPs download the same JDK binaries from
adoptopenjdk.net  like dozens or hundreds of
time a day? I mean: how is the bandwidth consumption handled on
adoptopenjdk.net? Isn"t there a risk that some users be banned from
downloading from there if they suck for instance +100GB, or much more, of
bandwidth a day?

I'm asking because I've been arguing there and some other places that
anyway this feature has always been problematic. And I tend to think it's
cool for demos, but that normal usages shouldn't rely on downloading
binaries from an external source forever, for a variety of reasons I've
listed in the JIRA issue linked previously.

Thanks! :)

Le dim. 24 févr. 2019 à 21:17, Martijn Verburg  a
écrit :

> Hi all,
>
> I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro now
> (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et al
> are collaborating there).  Let me know if you need any help connecting to
> our API:
>
> https://api.adoptopenjdk.net
>
> Cheers,
> Martijn
>
>
> On Sat, 23 Feb 2019 at 18:14, Sverre Moe  wrote:
>
>> Thanks for the link. Good to see that they are looking into it. Hope it
>> doesn't take to long.
>>
>> fredag 22. februar 2019 15.38.57 UTC+1 skrev Devin Nusbaum følgende:
>>>
>>> There is some relevant discussion in
>>> https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be
>>> interesting to you.
>>>
>>> On Feb 22, 2019, at 09:20, Sverre Moe  wrote:
>>>
>>> Now that Oracle has shut down any commercial use of their JDK, Jenkins
>>> should add option to download JDK from AdoptOpenJDK
>>>
>>> Install automatically
>>> Extract *.zip/*.tar.gz
>>> Install from java.sun.com
>>> Run Batch Command
>>> Run Shell Command
>>>
>>> Now that the JDK from Oracle cannot be used in production we need
>>> another source.
>>>
>>> Install from AdoptOpenJDK
>>> https://adoptopenjdk.net/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%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 Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS5NhKXyvHaJinOkz4P9BpxPVC7eRi%2BzYaDbR_TFcVOfEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

role-Based strategy showing FullName next to userid ?

2019-02-26 Thread 'monger_39' via Jenkins Users

Hi,

we have a Jenkins setup with RoleBased Strategy, using the CollabNet realm 
for Authorization. We have userid's (iso names) for login. These userid's are 
all very similar; 3 letters followed by 5 digits.
After a while, having 50 or more userid's in the 'Assign Roles'table, it 
becomes 
very difficult to see who can do what.

question: is there any easy way to add a column showing the 'Full Name' ?

As an enhancement, it would also help if the userid would be a link to the
user configuration page.

I've searched for this, but could not find anything except the 'External 
add-ons'. 
Unfortunately I am not able (allowed) to install Greasemonkey.

My relevant setup:
   Jenkins-war:2.141
   CollabNet 2.0.4
   Role-Based Strategy 2.9.0

thx, Monger

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

Re: Jenkins Plugin cannot get called from the pipeline with new syntax

2019-02-26 Thread prasad.pofali via Jenkins Users

Thanks Richard,

I have defined the Symbol using  @Symbol("TestUploader") annotation but it 
was not working. Now that I have changed the parameter of annotation to 
@Symbol("testUploader"), it is working with the following syntax.

pipeline {
agent any
 stages {
 stage('Build and Run Tests') {
  steps {
   testUploader name:'admin', lastname: 'admin', endPoint: '
http://localhost:8080/', file:'path/to/myfile.txt'
  }
  }
 }
}

Thanks for the help :)


On Monday, February 25, 2019 at 11:29:25 PM UTC+5:30, Richard Bywater wrote:
>
> You'll need to provide some idea of what error/behaviour you are seeing as 
> otherwise it's hard to help point you in the right direction.
>
> Richard
>
> On Tue, 26 Feb 2019, 1:17 AM prasad.pofali via Jenkins Users, <
> jenkins...@googlegroups.com > wrote:
>
>> Hello,
>>
>> I have created a Symbol in TestRunPublisher for descriptor. The code now 
>> looks like following:
>>
>>
>> public class TestUploader extends Publisher implements SimpleBuildStep {
>> private final String name;
>> private final String password;
>> //getters are there for above variables.
>> @DataBoundConstructor
>> public TestUploader (String name, String password){
>> //set the data to class members.
>> }
>> @Symbol("TestUploader")
>> @Extension
>> ublic static final class DescriptorImpl extends 
>> BuildStepDescriptor {
>> public DescriptorImpl () {
>> load();
>> }
>> }
>>   public boolean isApplicable (Class 
>> aClass) {return true;}
>>
>> public String getDisplayName () {return "TestUploader";}
>>
>> @Override
>> public boolean configure (StaplerRequest req, JSONObject formData) throws 
>> FormException {
>> save();
>> return super.configure(req, formData);
>> }
>> }
>>
>> I think I am missing out on something.
>>
>>
>> On Sunday, February 24, 2019 at 12:19:56 PM UTC+5:30, Richard Bywater 
>> wrote:
>>>
>>> You need to define a Symbol in your plugin.  See Defining Symbols 
>>> section at 
>>> https://jenkins.io/doc/developer/plugin-development/pipeline-integration/
>>>
>>> Richard
>>>
>>> On Sat, 23 Feb 2019, 11:25 AM prasad.pofali via Jenkins Users, <
>>> jenkins...@googlegroups.com> wrote:
>>>
 I have developed a custom Jenkins plugin which extends *Recorder *and 
 implements *SimpleBuildStep*. I was calling this plugin using the 
 syntax:

 pipeline {
 agent any
 stages {
 stage('Build and Run Tests') {
 steps {
 step([$class : 'TestClass', name: 'admin', lastname: 
 'admin', endPoint:'http://localhost:8080/', file:'path/to/myfile.txt'])
 }
 }
 }
 }


 With this the plugin is executed, but now my requirement is to call 
 this plugin with the different pipeline syntax which is our primary 
 requirement. The required syntax is as follows:

 pipeline {
 agent any
  stages {
  stage('Build and Run Tests') {
   steps {
TestClass name:'admin' lastname: 'admin' endPoint: '
 http://localhost:8080/', file:'path/to/myfile.txt'
   }
   }
  }
 }


 But I am not able to call the same plugin with the above syntax. Can 
 anyone please help me?

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/db5c1523-75e2-4969-ba26-54dede193291%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 Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/a882d3ba-768b-43f0-8c63-4dcc7f82ba3e%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit

Re: Resume my Multibranch Pipeline when a code review is submitted

2019-02-26 Thread László Boros

Hi,

I'm not sure if you've received any response, but I see two possible solutions:

* create a separate job in Jenkins for these merges, subscribe to the "code
review approved" events from Github and work from that
* in the pipeline, create an "infinite loop" with some sensible upper limit
(like 3 days) to wait for the code review to happen, check the PR state in a
loop and then sleep some minutes to save computational power and when the PR is
approved, do the merge. Or if the time limit is up, exit the job with failure.

Both of them have advantages and disadvantages: the second one is more aligned
with the "1 job for 1 PR" idea, but the waiting in loop wastes computational
power and also keeps agents reserved. In this regard the first one is much
better, but then the testing and merging actions are done by separate jobs.

I don't know technical details about how to implement these since I don't use
the Github plugin, but I hope these ideas help.
BR,
Laszlo

On 20 Feb 2019, at 19:35, Sameera Priyatham Tadikonda
mailto:priyathamj...@gmail.com>> wrote:

I integrated Jenkins with Github using web hooks and I created a multi-branch
pipeline and I am using JenkinsFile.

Jobs are created automatically and I am able to run the tests when a PR is
created.Once the tests are passed my pipeline waits for the code review to be
completed before merging.

I would like to merge the PR when the code review is done.

I am pushing all the Web hook events from Github to Jenkins.

How can I resume my pipeline when a code-review event is pushed to my Jenkins.

Please help me if anyone worked on this.

--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/e1f72226-99c6-4221-acfb-8047c76805c4%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/9BDCD0C4-6E23-4F07-8804-7A05B06432D0%40skyscanner.net.
For more options, visit https://groups.google.com/d/optout.

Re: Unknown Workflow CPS Exceptions in Jenkins log

2019-02-26 Thread Mark Waite

The warning message is misleading.  That class intentionally does not have
a data bound constructor.  Refer to
https://issues.jenkins-ci.org/browse/JENKINS-54186 for more details.

On Tue, Feb 26, 2019 at 4:28 AM Sverre Moe  wrote:

> Any idea what the following Exceptions are caused by?
> I have found these in the Jenkins log.
>
> Feb 26, 2019 11:43:58 AM WARNING org.jenkinsci.plugins.workflow.cps.DSL 
> invokeStep
>
> Error storing the arguments for step: checkout
> org.kohsuke.stapler.NoStaplerConstructorException: There's no 
> @DataBoundConstructor on any constructor of class 
> jenkins.plugins.git.AbstractGitSCMSource$SpecificRevisionBuildChooser
>   at 
> org.kohsuke.stapler.ClassDescriptor.loadConstructorParamNames(ClassDescriptor.java:265)
>   at 
> org.jenkinsci.plugins.structs.describable.DescribableModel.(DescribableModel.java:144)
>   at 
> org.jenkinsci.plugins.structs.describable.DescribableModel.of(DescribableModel.java:114)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:294)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:311)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeListAndRecordMutation(ArgumentsActionImpl.java:242)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:313)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:311)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
>   at 
> org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.(ArgumentsActionImpl.java:74)
>   at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:243)
>   at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176)
>   at 
> org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
>   at 
> groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:810)
>   at 
> groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
>   at 
> groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
>   at 
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
>   at 
> com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
>   at 
> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
>   at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
>   at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
>   at sun.reflect.GeneratedMethodAccessor466.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>   at 
> com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:76)
>   at 
> com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
>   at 
> com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
>   at sun.reflect.GeneratedMethodAccessor471.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>   at 
> com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
>   at com.cloudbees.groovy.cps.Next.step(Next.java:83)
>   at

Unknown Workflow CPS Exceptions in Jenkins log

2019-02-26 Thread Sverre Moe

Any idea what the following Exceptions are caused by?
I have found these in the Jenkins log.

Feb 26, 2019 11:43:58 AM WARNING org.jenkinsci.plugins.workflow.cps.DSL 
invokeStep

Error storing the arguments for step: checkout
org.kohsuke.stapler.NoStaplerConstructorException: There's no 
@DataBoundConstructor on any constructor of class 
jenkins.plugins.git.AbstractGitSCMSource$SpecificRevisionBuildChooser
at 
org.kohsuke.stapler.ClassDescriptor.loadConstructorParamNames(ClassDescriptor.java:265)
at 
org.jenkinsci.plugins.structs.describable.DescribableModel.(DescribableModel.java:144)
at 
org.jenkinsci.plugins.structs.describable.DescribableModel.of(DescribableModel.java:114)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:294)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:311)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeListAndRecordMutation(ArgumentsActionImpl.java:242)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:313)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeObjectAndRecordMutation(ArgumentsActionImpl.java:311)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.sanitizeMapAndRecordMutation(ArgumentsActionImpl.java:386)
at 
org.jenkinsci.plugins.workflow.cps.actions.ArgumentsActionImpl.(ArgumentsActionImpl.java:74)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:243)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176)
at 
org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
at 
groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:810)
at 
groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
at 
groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1278)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1172)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
at 
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at 
com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:20)
at 
com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor466.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:76)
at 
com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
at 
com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
at sun.reflect.GeneratedMethodAccessor471.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at 
org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at 
org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)

Re: Use AdoptOpenJDK as JDK Tool download source

Re: Use AdoptOpenJDK as JDK Tool download source

Re: Use AdoptOpenJDK as JDK Tool download source

Re: Use AdoptOpenJDK as JDK Tool download source

Re: Use AdoptOpenJDK as JDK Tool download source

Re: Use AdoptOpenJDK as JDK Tool download source

role-Based strategy showing FullName next to userid ?

Re: Jenkins Plugin cannot get called from the pipeline with new syntax

Re: Resume my Multibranch Pipeline when a code review is submitted

Re: Unknown Workflow CPS Exceptions in Jenkins log

Unknown Workflow CPS Exceptions in Jenkins log

11 matches

Site Navigation

Mail list logo

Footer information