Re: [DISCUSS] Dependabot for Jenkins core (was:Re: Proposal: Automating dependency management for repositories inside the jenkinsci org)

2020-12-10 Thread Tim Jacomb
I’m fine with adding more,

We could also try a deny list too and see how it goes

On Fri, 11 Dec 2020 at 00:01, Oleg Nenashev  wrote:

> I am +1. We should finally move forward with Dependabot for dependencies
> we considers safe and important to be kept up to date. Allow list is a good
> way to go, we have a sizeable number if deps.
>
> On Thu, Dec 10, 2020, 23:58 Baptiste Mathus  wrote:
>
>> Hi all,
>>
>> I wanted to raise a discussion on this and thought I'd fork off this
>> answer from Jesse on Oleg's thread.
>>
>> I see Jesse already configured Dependabot for Xstream:
>> https://github.com/jenkinsci/jenkins/commit/2440a34d8f2ba5626d734c735cb4fc63040c11de
>>
>> Should we start adding all core components, like the parent pom, internal
>> or test tools like JTH,  and some dependencies we think are safe
>> (build-time things like Maven plugins, I assume)?
>>
>> AIUI, we would be able to agree on an allowList approach? I.e. adding
>> specific dependencies we want auto-updated (excluding any that's unlisted).
>>
>> Side note on this: I think if we agree to go this path, it would be great
>> to find a way modify the Core Pipeline so the essentials.yaml values are
>> sourced from some pom.xml (for ATH version) so Dependabot can understand
>> and update this too.
>> This way, we'd be getting automated updates for
>> https://github.com/jenkinsci/jenkins/blob/53f300d5ec07eb5efa3774d3f12455615d2f3450/essentials.yml#L4-L5
>> too, which bit us in the arse recently on the latest LTS prep IIRC.
>>
>> WDYT?
>>
>>
>> IIUC, we could kinda take an allowList approach on specific components.
>>
>> Le jeu. 21 févr. 2019 à 15:40, Jesse Glick  a
>> écrit :
>>
>>> On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev 
>>> wrote:
>>> > I propose to focus on development tools
>>>
>>> Since the primary use case is offering updates to plugin repositories,
>>> I would suggest including at least one example of `*-plugin`.
>>>
>>> The question is which dependencies ought to be eligible for upgrade. I
>>> do not think we want to update Jenkins core or plugin dependencies
>>> gratuitously, since this would limit availability of new releases with
>>> only modest productivity gain: more realistic functional tests, less
>>> distance from `master` to whatever `plugin-compat-tester` would use.
>>>
>>> Definitely we can freely upgrade the parent POM. I would be happy for
>>> such updates to be auto-merged in fact, so long as the build passes
>>> obviously.
>>>
>>> > pre-1.0 projects only
>>>
>>> Or just plugins that (a) have fairly low installation count, (b) are
>>> maintained by people actively participating in the trial.
>>>
>>> > More repositories can be added if somebody is interested to
>>> participate in the Dependabot evaluation.
>>>
>>> Sign me up!
>>>
>>> I _do_ need to make sure I get notifications of these PRs in
>>> Octobox.io, if they are not simply automerged. Merely watching a
>>> repository is not enough—GH has autosubscribed me to hundreds of
>>> repos, and the resulting thousands of notifications go to /dev/null.
>>> Maybe Dependabot can be configured to request me as a reviewer?
>>>
>>> --
>>> 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/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%40mail.gmail.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/XMllKuWLO_8/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/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%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/CAPfivLDNgdKA2A-85n-ePFMOe7UdRE9%3DCRp%3DvXrP717Jrf4QTA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe 

Re: [DISCUSS] Dependabot for Jenkins core (was:Re: Proposal: Automating dependency management for repositories inside the jenkinsci org)

2020-12-10 Thread Oleg Nenashev
I am +1. We should finally move forward with Dependabot for dependencies we
considers safe and important to be kept up to date. Allow list is a good
way to go, we have a sizeable number if deps.

On Thu, Dec 10, 2020, 23:58 Baptiste Mathus  wrote:

> Hi all,
>
> I wanted to raise a discussion on this and thought I'd fork off this
> answer from Jesse on Oleg's thread.
>
> I see Jesse already configured Dependabot for Xstream:
> https://github.com/jenkinsci/jenkins/commit/2440a34d8f2ba5626d734c735cb4fc63040c11de
>
> Should we start adding all core components, like the parent pom, internal
> or test tools like JTH,  and some dependencies we think are safe
> (build-time things like Maven plugins, I assume)?
>
> AIUI, we would be able to agree on an allowList approach? I.e. adding
> specific dependencies we want auto-updated (excluding any that's unlisted).
>
> Side note on this: I think if we agree to go this path, it would be great
> to find a way modify the Core Pipeline so the essentials.yaml values are
> sourced from some pom.xml (for ATH version) so Dependabot can understand
> and update this too.
> This way, we'd be getting automated updates for
> https://github.com/jenkinsci/jenkins/blob/53f300d5ec07eb5efa3774d3f12455615d2f3450/essentials.yml#L4-L5
> too, which bit us in the arse recently on the latest LTS prep IIRC.
>
> WDYT?
>
>
> IIUC, we could kinda take an allowList approach on specific components.
>
> Le jeu. 21 févr. 2019 à 15:40, Jesse Glick  a
> écrit :
>
>> On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev 
>> wrote:
>> > I propose to focus on development tools
>>
>> Since the primary use case is offering updates to plugin repositories,
>> I would suggest including at least one example of `*-plugin`.
>>
>> The question is which dependencies ought to be eligible for upgrade. I
>> do not think we want to update Jenkins core or plugin dependencies
>> gratuitously, since this would limit availability of new releases with
>> only modest productivity gain: more realistic functional tests, less
>> distance from `master` to whatever `plugin-compat-tester` would use.
>>
>> Definitely we can freely upgrade the parent POM. I would be happy for
>> such updates to be auto-merged in fact, so long as the build passes
>> obviously.
>>
>> > pre-1.0 projects only
>>
>> Or just plugins that (a) have fairly low installation count, (b) are
>> maintained by people actively participating in the trial.
>>
>> > More repositories can be added if somebody is interested to participate
>> in the Dependabot evaluation.
>>
>> Sign me up!
>>
>> I _do_ need to make sure I get notifications of these PRs in
>> Octobox.io, if they are not simply automerged. Merely watching a
>> repository is not enough—GH has autosubscribed me to hundreds of
>> repos, and the resulting thousands of notifications go to /dev/null.
>> Maybe Dependabot can be configured to request me as a reviewer?
>>
>> --
>> 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/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%40mail.gmail.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/XMllKuWLO_8/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/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%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/CAPfivLDNgdKA2A-85n-ePFMOe7UdRE9%3DCRp%3DvXrP717Jrf4QTA%40mail.gmail.com.


[DISCUSS] Dependabot for Jenkins core (was:Re: Proposal: Automating dependency management for repositories inside the jenkinsci org)

2020-12-10 Thread Baptiste Mathus
Hi all,

I wanted to raise a discussion on this and thought I'd fork off this answer
from Jesse on Oleg's thread.

I see Jesse already configured Dependabot for Xstream:
https://github.com/jenkinsci/jenkins/commit/2440a34d8f2ba5626d734c735cb4fc63040c11de

Should we start adding all core components, like the parent pom, internal
or test tools like JTH,  and some dependencies we think are safe
(build-time things like Maven plugins, I assume)?

AIUI, we would be able to agree on an allowList approach? I.e. adding
specific dependencies we want auto-updated (excluding any that's unlisted).

Side note on this: I think if we agree to go this path, it would be great
to find a way modify the Core Pipeline so the essentials.yaml values are
sourced from some pom.xml (for ATH version) so Dependabot can understand
and update this too.
This way, we'd be getting automated updates for
https://github.com/jenkinsci/jenkins/blob/53f300d5ec07eb5efa3774d3f12455615d2f3450/essentials.yml#L4-L5
too, which bit us in the arse recently on the latest LTS prep IIRC.

WDYT?


IIUC, we could kinda take an allowList approach on specific components.

Le jeu. 21 févr. 2019 à 15:40, Jesse Glick  a écrit :

> On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev 
> wrote:
> > I propose to focus on development tools
>
> Since the primary use case is offering updates to plugin repositories,
> I would suggest including at least one example of `*-plugin`.
>
> The question is which dependencies ought to be eligible for upgrade. I
> do not think we want to update Jenkins core or plugin dependencies
> gratuitously, since this would limit availability of new releases with
> only modest productivity gain: more realistic functional tests, less
> distance from `master` to whatever `plugin-compat-tester` would use.
>
> Definitely we can freely upgrade the parent POM. I would be happy for
> such updates to be auto-merged in fact, so long as the build passes
> obviously.
>
> > pre-1.0 projects only
>
> Or just plugins that (a) have fairly low installation count, (b) are
> maintained by people actively participating in the trial.
>
> > More repositories can be added if somebody is interested to participate
> in the Dependabot evaluation.
>
> Sign me up!
>
> I _do_ need to make sure I get notifications of these PRs in
> Octobox.io, if they are not simply automerged. Merely watching a
> repository is not enough—GH has autosubscribed me to hundreds of
> repos, and the resulting thousands of notifications go to /dev/null.
> Maybe Dependabot can be configured to request me as a reviewer?
>
> --
> 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/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%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/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%40mail.gmail.com.


Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Baptiste Mathus
Thanks!

(And I realize I didn't post the link I was meaning to...
https://www.jenkins.io/events/#event-calendar for anyone wondering)

Le jeu. 10 déc. 2020 à 22:57, Tim Jacomb  a écrit :

> Added all to the calendar
>
> On Thu, 10 Dec 2020 at 21:52, Tim Jacomb  wrote:
>
>> Daniel has granted
>>
>> On Thu, 10 Dec 2020 at 21:29, Mark Waite 
>> wrote:
>>
>>> +1 for Tim to be granted permission on the Jenkins calendar.
>>>
>>> On Thu, Dec 10, 2020 at 1:43 PM Tim Jacomb  wrote:
>>>
 Sounds good to me

 I don't have any permissions on the calendar as far as I can see.

 Could someone add the dates please, and also grant me calendar
 permissions?

 Thanks
 Tim

 On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:

> Hi all,
>
> (Possibly a question to Tim)
>
> Can we please consider updating the Jenkins events calendar with the
> next .1 (and possibly .2, and .3)?
> Or do we have any short term plan to change the LTS schedule?
> If so, and given we know this next LTS is going to be "big",
> 
> I guess we'd rather want to know earlier than later :-).
>
> Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose
> these dates will look like:
>
>- NEW.1 RC: 24th of February.
>- *NEW.1 release: 10th of March *
>- NEW.2 RC: 24th of March
>- etc.
>
>
> Thanks!
>
> -- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%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/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%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/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%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/CAH-3BidynCBu5053wBUVdWBqtDu8R-Hsj4xc0QpDb1xMF19-Mw%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/CANWgJS4njaGhMCFJF4CGpiFGiumv5T8Vym2CMw8%3Dg25FOyA6Fw%40mail.gmail.com.


Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Tim Jacomb
Added all to the calendar

On Thu, 10 Dec 2020 at 21:52, Tim Jacomb  wrote:

> Daniel has granted
>
> On Thu, 10 Dec 2020 at 21:29, Mark Waite 
> wrote:
>
>> +1 for Tim to be granted permission on the Jenkins calendar.
>>
>> On Thu, Dec 10, 2020 at 1:43 PM Tim Jacomb  wrote:
>>
>>> Sounds good to me
>>>
>>> I don't have any permissions on the calendar as far as I can see.
>>>
>>> Could someone add the dates please, and also grant me calendar
>>> permissions?
>>>
>>> Thanks
>>> Tim
>>>
>>> On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:
>>>
 Hi all,

 (Possibly a question to Tim)

 Can we please consider updating the Jenkins events calendar with the
 next .1 (and possibly .2, and .3)?
 Or do we have any short term plan to change the LTS schedule?
 If so, and given we know this next LTS is going to be "big",
 
 I guess we'd rather want to know earlier than later :-).

 Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose
 these dates will look like:

- NEW.1 RC: 24th of February.
- *NEW.1 release: 10th of March *
- NEW.2 RC: 24th of March
- etc.


 Thanks!

 -- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%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/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%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/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%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/CAH-3BidynCBu5053wBUVdWBqtDu8R-Hsj4xc0QpDb1xMF19-Mw%40mail.gmail.com.


Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Tim Jacomb
Daniel has granted

On Thu, 10 Dec 2020 at 21:29, Mark Waite  wrote:

> +1 for Tim to be granted permission on the Jenkins calendar.
>
> On Thu, Dec 10, 2020 at 1:43 PM Tim Jacomb  wrote:
>
>> Sounds good to me
>>
>> I don't have any permissions on the calendar as far as I can see.
>>
>> Could someone add the dates please, and also grant me calendar
>> permissions?
>>
>> Thanks
>> Tim
>>
>> On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:
>>
>>> Hi all,
>>>
>>> (Possibly a question to Tim)
>>>
>>> Can we please consider updating the Jenkins events calendar with the
>>> next .1 (and possibly .2, and .3)?
>>> Or do we have any short term plan to change the LTS schedule?
>>> If so, and given we know this next LTS is going to be "big",
>>> 
>>> I guess we'd rather want to know earlier than later :-).
>>>
>>> Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose these
>>> dates will look like:
>>>
>>>- NEW.1 RC: 24th of February.
>>>- *NEW.1 release: 10th of March *
>>>- NEW.2 RC: 24th of March
>>>- etc.
>>>
>>>
>>> Thanks!
>>>
>>> -- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%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/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%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/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%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/CAH-3Bidtb%2BVm1fZSFq-C8qrtRKMfgDpZrG%2BfuwcMRs0k3-qnpA%40mail.gmail.com.


Backporting for LTS 2.263.2 started

2020-12-10 Thread Tim Jacomb
Backporting has started and the RC is scheduled for approximately
2020-12-17.

Candidates: https://issues.jenkins.io/issues/?filter=12146
Fixed: https://issues.jenkins.io/issues/?jql=labels%20%3D%202.263.2-fixed
Rejected:
https://issues.jenkins.io/issues/?jql=labels%20%3D%202.263.2-rejected

Thanks
Tim

-- 
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-3BicbWkQS_dK%3DzeMx1c%2BCaDtrSoXYMWsgVfSBggq9kSwMsw%40mail.gmail.com.


Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Mark Waite
+1 for Tim to be granted permission on the Jenkins calendar.

On Thu, Dec 10, 2020 at 1:43 PM Tim Jacomb  wrote:

> Sounds good to me
>
> I don't have any permissions on the calendar as far as I can see.
>
> Could someone add the dates please, and also grant me calendar permissions?
>
> Thanks
> Tim
>
> On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:
>
>> Hi all,
>>
>> (Possibly a question to Tim)
>>
>> Can we please consider updating the Jenkins events calendar with the next
>> .1 (and possibly .2, and .3)?
>> Or do we have any short term plan to change the LTS schedule?
>> If so, and given we know this next LTS is going to be "big",
>> 
>> I guess we'd rather want to know earlier than later :-).
>>
>> Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose these
>> dates will look like:
>>
>>- NEW.1 RC: 24th of February.
>>- *NEW.1 release: 10th of March *
>>- NEW.2 RC: 24th of March
>>- etc.
>>
>>
>> Thanks!
>>
>> -- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%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/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%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/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%40mail.gmail.com.


Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Tim Jacomb
Sounds good to me

I don't have any permissions on the calendar as far as I can see.

Could someone add the dates please, and also grant me calendar permissions?

Thanks
Tim

On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:

> Hi all,
>
> (Possibly a question to Tim)
>
> Can we please consider updating the Jenkins events calendar with the next
> .1 (and possibly .2, and .3)?
> Or do we have any short term plan to change the LTS schedule?
> If so, and given we know this next LTS is going to be "big",
> 
> I guess we'd rather want to know earlier than later :-).
>
> Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose these
> dates will look like:
>
>- NEW.1 RC: 24th of February.
>- *NEW.1 release: 10th of March *
>- NEW.2 RC: 24th of March
>- etc.
>
>
> Thanks!
>
> -- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%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/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%40mail.gmail.com.


Re: Return a map/value from a step in a pipeline build

2020-12-10 Thread Matt Sicker
Indeed, if you're modifying run actions inside a pipeline thing like
in credentials-binding, you need to ensure to merge existing actions
into the new one however it makes sense for that usage. If it doesn't
make sense to do so, then attaching actions is likely too coarse for
your use case.

On Thu, Dec 10, 2020 at 10:51 AM Jesse Glick  wrote:
>
> On Thu, Dec 10, 2020 at 4:26 AM Lakshmi Narasimhan
>  wrote:
> > I am trying to understand  how I can leverage SimpleBuildWrapper to be able 
> > to work in different job types.
>
> `SimpleBuildWrapper` is specifically designed (in fact restricted) to
> be compatible with traditional job types as well as Pipeline. Please
> read
>
> https://www.jenkins.io/doc/developer/plugin-development/pipeline-integration/
>
> > step ([$class: "MyStepClass"...]  // This performs some action and has the 
> > return values (name-value pairs)
>
> No, you just define a `@Symbol` and that becomes a Pipeline step name.
>
> > I am tending towards  doing this through an intermediate action
>
> `Run.addAction` affects the build globally, which will lead to
> incorrect or confused results if a Pipeline build uses the wrapper
> multiple times, or does work after the block ends, or (especially) if
> the wrapper is run in parallel. So avoid that.
>
> From a `SimpleBuildWrapper` you can communicate information to nested
> steps using simple (textual) environment variables. If you need to
> communicate richer substructure contextually, you will need to use
> `Step` and check the documentation on `BodyInvoker`.
>
> --
> 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/CANfRfr0o1KLdpNpWVarYoycm5v_hKBofXeVyyoYcTiN8JeRQDQ%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/CAEot4owXfGvTC27mjSxC7e_SOL%3DgkYnjevzKB%3DUjeg9Afvef-g%40mail.gmail.com.


Re: Return a map/value from a step in a pipeline build

2020-12-10 Thread Jesse Glick
On Thu, Dec 10, 2020 at 4:26 AM Lakshmi Narasimhan
 wrote:
> I am trying to understand  how I can leverage SimpleBuildWrapper to be able 
> to work in different job types.

`SimpleBuildWrapper` is specifically designed (in fact restricted) to
be compatible with traditional job types as well as Pipeline. Please
read

https://www.jenkins.io/doc/developer/plugin-development/pipeline-integration/

> step ([$class: "MyStepClass"...]  // This performs some action and has the 
> return values (name-value pairs)

No, you just define a `@Symbol` and that becomes a Pipeline step name.

> I am tending towards  doing this through an intermediate action

`Run.addAction` affects the build globally, which will lead to
incorrect or confused results if a Pipeline build uses the wrapper
multiple times, or does work after the block ends, or (especially) if
the wrapper is run in parallel. So avoid that.

>From a `SimpleBuildWrapper` you can communicate information to nested
steps using simple (textual) environment variables. If you need to
communicate richer substructure contextually, you will need to use
`Step` and check the documentation on `BodyInvoker`.

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


RE: Request to be the maintainer for Amazon ECS Plugin

2020-12-10 Thread Isaac Chou
I believe people are busy at this moment.  I am new to this but let me share 
with you the information based on my recent exchange on the same request. ☺ I 
believe for the next step that you need to create a PR to add your 
jenkins.io username to  
https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-amazon-ecs.yml

Isaac

From: jenkinsci-dev@googlegroups.com  On Behalf 
Of Gokhan Oner
Sent: Thursday, December 10, 2020 12:09 AM
To: Jenkins Developers 
Subject: Re: Request to be the maintainer for Amazon ECS Plugin


Any update on this request?
On Tuesday, December 8, 2020 at 1:20:22 AM UTC-8 Gokhan Oner wrote:
Hi,

I want to be the maintainer for below Jenkins Plugin:

Plugin repo: https://github.com/jenkinsci/amazon-ecs-plugin
My github user: https://github.com/gokhanoner
My Jenkins userid: gokhanoner

Thanks
Gokhan

--
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/29708564-7df0-4ca9-91e1-d5571ca3dd1fn%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/MN2PR18MB27980783566E9381F3781147E5CB0%40MN2PR18MB2798.namprd18.prod.outlook.com.


Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

2020-12-10 Thread Baptiste Mathus
Hi all,

(Possibly a question to Tim)

Can we please consider updating the Jenkins events calendar with the next
.1 (and possibly .2, and .3)?
Or do we have any short term plan to change the LTS schedule?
If so, and given we know this next LTS is going to be "big",

I guess we'd rather want to know earlier than later :-).

Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose these
dates will look like:

   - NEW.1 RC: 24th of February.
   - *NEW.1 release: 10th of March *
   - NEW.2 RC: 24th of March
   - etc.


Thanks!

-- 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%40mail.gmail.com.


Re: Request to be the maintainer for Amazon ECS Plugin

2020-12-10 Thread Gokhan Oner

Any update on this request?
On Tuesday, December 8, 2020 at 1:20:22 AM UTC-8 Gokhan Oner wrote:

> Hi,
>
> I want to be the maintainer for below Jenkins Plugin:
>
> *Plugin repo:* https://github.com/jenkinsci/amazon-ecs-plugin
> *My github user:* https://github.com/gokhanoner
> *My Jenkins userid:* gokhanoner
>
> Thanks
> Gokhan
>
>

-- 
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/29708564-7df0-4ca9-91e1-d5571ca3dd1fn%40googlegroups.com.


Re: Return a map/value from a step in a pipeline build

2020-12-10 Thread Lakshmi Narasimhan
Hi Jesse, 

Thanks for the suggestion. I went through the docs and implementing Step 
would certainly work well for my use case.

I am trying to understand  how I can leverage SimpleBuildWrapper to be able 
to work in different job types. I assume that I need another class to 
implement the BuildWrapper extension point. In that case, I would end up 
having something like this
step ([$class: "MyStepClass"...]  // This performs some action and has the 
return values (name-value pairs)

withMyWrapperClass() { // I need this wrapper to inject those return values 
from the previous step into the block.

// I can call my step here and have another wrapper block too.
}

I need to send some data from MyStepClass instance to following 
MyWrapperClass  instance so that it can inject that data into the block's 
environment. I am tending towards  doing this through an intermediate 
action created by MyStepClass instance. But if I keep adding actions from 
my step class to the build, then it is possible that an outer wrapper picks 
up an action from an inner step.  Same issue will persist if I update just 
a single action or replace it. 

Please let me know if I understood your suggestion properly regarding 
SimpleBuildWrapper and whether the approach is correct.

On Thursday, November 12, 2020 at 11:49:07 PM UTC+5:30 Jesse Glick wrote:

> On Thu, Nov 12, 2020 at 6:08 AM Lakshmi Narasimhan
>  wrote:
> > My issue is that the step does not return a map or any value. I am 
> referring to the "step" metastep.
>
> No, you cannot return values if you use `SimpleBuildStep`. You can
> extend `Step` directly (Pipeline-specific). But it may be better to
> extend `SimpleBuildWrapper` and define environment variables within
> its block; this will work in freestyle, Scripted Pipeline, _and_
> Declarative Pipeline (without `script` blocks).
>

-- 
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/4874d62e-e6c5-4c40-a00e-e53dbc7cfb50n%40googlegroups.com.