Re: Proposal: New twitter contributors

[Oleg Nenashev]

+1 of course.
I promise to be more careful with spelling in tweets than with spelling in 
my commit messages :P

On Wednesday, December 11, 2019 at 6:59:53 PM UTC+1, Adrien Lecharpentier 
wrote:
>
> of course +1!
>
> Le mer. 11 déc. 2019 à 18:31, Arnaud Héritier  > a écrit :
>
>> +1
>>
>> Le mer. 11 déc. 2019 à 17:44, Baptiste Mathus > > a écrit :
>>
>>> +2, I mean. So very yey ;)
>>>
>>> Le mer. 11 déc. 2019 à 17:38, Kohsuke Kawaguchi >> > a écrit :
>>>
 Yay, +1

 On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda >>> > wrote:

> Hi all,
>
> As per the process outlined in JEP 10 
> , I would like 
> to propose two new Twitter Contributors for the @jenkinsci account. 
>
> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets 
> via the Advocacy gitter channel as well as tweeting community highlights 
> around hacktoberfest, gsoc, SIGs, elections etc. For example
> https://twitter.com/oleg_nenashev/status/1202631389277032449
> https://twitter.com/oleg_nenashev/status/1194982086521872384
> https://twitter.com/oleg_nenashev/status/1176981880786313217
>
> 2. Mark Waite - Mark regularly tweets around Platform SIG & 
> Documentation SIG, Jenkins git plugin, Jenkins online meetups and other 
> community highlights. For example:
> https://twitter.com/MarkEWaite/status/1190616140868808705  
> https://twitter.com/MarkEWaite/status/1180093593073045504
> https://twitter.com/MarkEWaite/status/1192437176446812160
>
> By giving Oleg & Mark access to schedule tweets, etc it will help the 
> community with more timely and regular communication around the many 
> community activities and technical developments.
>
> Please go ahead and vote/comment on this proposal. I will also add to 
> an upcoming board meeting for approval there. 
>
> Regards,
> Tracy 
>
>
>
>
>
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to jenkin...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
>  
> 
> .
>


 -- 
 Kohsuke Kawaguchi

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jenkin...@googlegroups.com .
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%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 jenkin...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5MLLKKWcyxc0LmKdsBe4y%2BBFKdbnnEKLGaxs66P-J2Ng%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_o9XdRj_TXALA_WbtJUBOP__Wh2AMpGjLWLQHf-dhhSA%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adrien Lecharpentier
>

-- 
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/61e4d720-a78e-4ac5--e38938f0180e%40googlegroups.com.

Re: Proposal: Detaching Git Server from Pipeline: Shared Groovy Libraries to a separate plugin

[Oleg Nenashev]

Thanks! I should have checked the bugtracker before the mailing list.
The suggestions are different, basically it boils down to the level of 
compatibility we want to retain

On Wednesday, December 11, 2019 at 7:21:32 PM UTC+1, Jesse Glick wrote:
>
> On Wed, Dec 11, 2019 at 7:09 AM Oleg Nenashev  > wrote: 
> > What do I propose to do? 
>
> Please use JENKINS-57023 for discussion. 
>

-- 
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/32b58ea2-7811-4307-ab33-f5254fd2bfa8%40googlegroups.com.

Re: Q: rename a variable without breaking compatibility in the declarative pipeline

[Victor Martinez]

Thanks for the details, I managed to test the CustomDescribableModel within 
the pipeline-model-definition plugin and it seems the customInstantiate 
happens after the transformToRuntimeAST 
,
 
in other words, I'm able to manipulate the content of the parameters but I 
cannot manipulate and infer the deprecated parameter as the new parameter 
since there is a MultipleCompilationErrorsException :_(

*As an example:*

 "value" is deprecated and 'pattern' is the new parameter for the 
hypothetical case of changing the `environment when` condition in  the 
declarative pipeline definition.

Then the below implementation of the customInstantiate doesn't work when 
using environment name: 'FOO', pattern: 'BAR'

 private final String name;
 @Deprecated
 private transient String value;
private String pattern;

 @DataBoundConstructor
 public EnvironmentConditional(String name, String pattern) {
   this.name= name;
   this.pattern = pattern;
 }

  ...

  protected Object readResolve() throws IOException {
   if (this.value != null) {
 this.pattern = this.value;
   }
   return this;
 }

 @Extension
 @Symbol("environment")
 public static class DescriptorImpl extends 
DeclarativeStageConditionalDescriptor {
   
   ...

   @Override
   public Expression transformToRuntimeAST(@CheckForNull ModelASTWhenContent 
original) {
 return ASTParserUtils.transformWhenContentToRuntimeAST(original);
   }

   @Override
   public Map customInstantiate(Map 
arguments) {
 Map r = new HashMap<>(arguments);
 Object value = r.get("value");
 if (value instanceof String) {
r.put("pattern", ((String) value));
 }
 return r;
   }
 }




org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
failed:
WorkflowScript: 90: Invalid parameter "value", did you mean "name"? @ line 
90, column 42.
environment name: "FOO", value: "BA
 ^
1 error

at 
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at 
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
at 
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
at 
org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:133)
at 
org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:126)
at 
org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:561)
at 
org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:522)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:320)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE


Most likelly It's something else that I'm missing though. Although the few 
examples I've just found for the customInstantiate where about to 
manipulate the content or remove some of the parameters. 

Any clues what I'm missing?

Thanks again


-- 
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/727fa10e-189f-4430-a9da-57c4009bb651%40googlegroups.com.

Re: findsecbugs in spotbugs

[Jeff Thompson]

James,

You make valid points. Many of them, though, represent the nature of 
spotbugs, how it works, and particularly the difficulties of adding 
anything like it to legacy code. The problem just becomes perpetual -- 
the only good time to ever add these kinds of checks is in the past, 
there is a hurdle to adding them and dealing with them at any current or 
future point, which tends to result in overly broad suppressions, and so 
it's easy to just keep putting it off. Once added, these checks provide 
value: they make it harder to introduce new problems (of the types 
checked) and they point out areas of technical debt that can be improved.


In rough terms, I see the following approaches:

1) Make no changes. Continuing as we are just keeps us ignorant of the 
potential issues. With regular issues this may just mean there is a 
defect that needs to be fixed. With findsecbugs, it may be an 
exploitable security bug. Our ignorance doesn't protect us.


2) Something along the lines of my proposals: Enable it at the current 
spotbugs level, examine the individual findings, and suppress or act 
individually. As you note, this does lead to a lot of individual 
@SuppressFBWarning lines.


3) Enable it but don't suppress (nearly) anything. This requires 
(almost) all findings to be "corrected" before it's enabled for new 
development. Since we would be making sure not to suppress unless 
absolutely necessary we would need to first fix bad coding practice that 
doesn't result in usage issues. With legacy code, particularly on the 
scale of Jenkins, this practically becomes approach #1 because the 
barrier to ever doing it becomes too high.


4) Enable it but suppress via the exclude file rather than embedded 
@SuppressFBWarning lines. This tends to lead people to suppress by bug 
or category rather than examining the individual findings. If used more 
precisely, it disconnects the finding from the code, making it more 
difficult to eventually correct the technical debt.



My experiments with findsecbugs have found some areas of real concern. 
There's one I can readily share publicly at this time to illustrate. As 
I was analyzing one findsecbugs finding, I immediately recognized it as 
SECURITY-1322 / CVE-2019-10320, which was fixed in the 2019-05-21 
advisory. The scanner found it in the master branch, because we left 
part of the code in to facilitate migration. (It's essentially 
impossible to create new configurations with the problem.) The 
combination of the @Deprecated and @SuppressFBWarning annotations 
highlight that it should be fully removed some day. If someone had run 
findsecbugs a year ago it would have caught that as a real vulnerability.


My experience with spotbugs is that it can be a hassle at times, but it 
tends to encourage cleaner code and sometimes it finds real concerns.


I don't know how we could ever get around to enabling new rules except 
with something along the lines of my proposal, #2. I hope we can proceed 
with it, even if imperfectly.


Jeff

On 12/11/19 5:28 AM, James Nord wrote:
I had a quick peek at the 2 PRs and my main concern is that this found 
no security issues and forced annotations on a lot of places, that is 
it found no issues according to the PRs.


Whilst it could prevent issues being introduced in the future I am 
concerned it will cause 99% `@SuppressFBWarning` annoyance and not 
find the security issue.
The suppressions are also overly broad - for example 
https://github.com/jenkinsci/jenkins/pull/4381/files#diff-6b2c22336dd63b20019b8558c7e9a13fR599-R601 
is completely incorrect.  This code can not make assumptions about the 
callers - only the caller of that method can make it and as such the 
Annotation needs to be on those methods not the utility method.


in other words I think if this just causes pain by having to add 
suppress warnings then I think it would be a bad thing.  I would be 
happy to see it catch the first real issue - but if that does not 
happen in a long time I think we should be prepared to back this out.


my 2c.

On Wednesday, December 11, 2019 at 12:44:36 AM UTC, Raihaan Shouhell 
wrote:


Hey Jeff,

I think it is ok to introduce it. Sounds like it would add value.
There should be a switch to at least disable failing the build
because of findsecbugs.

Despite the potential problems with introducing it, I am +1 on it
since it will definitely help the development of new plugins.

Like you said spotbugs has actually helped find a ton of bugs, I
even find myself getting annoyed when the relevant annotation was
missing that could potentially avoid a bug.
If this tool can help us avoid security issues the same way
spotbugs helps with bugs that would be awesome.

Cheers,
Raihaan

On Wednesday, 11 December 2019 04:27:16 UTC+8, Jeff Thompson wrote:

Jenkins developers,

I've been working on introducing findsecbugs into the Jenkins
developer
ecosystem. fi

Re: Q: rename a variable without breaking compatibility in the declarative pipeline

[Jesse Glick]

On Wed, Dec 11, 2019 at 10:09 AM Robert Sandell  wrote:
> Maybe there is something in the descriptor that can be overridden to manually 
> handle the various scenarios, like overriding configure or newInstance

https://javadoc.jenkins.io/plugin/structs/org/jenkinsci/plugins/structs/describable/CustomDescribableModel.html

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

Re: Proposal: Detaching Git Server from Pipeline: Shared Groovy Libraries to a separate plugin

[Jesse Glick]

On Wed, Dec 11, 2019 at 7:09 AM Oleg Nenashev  wrote:
> What do I propose to do?

Please use JENKINS-57023 for discussion.

-- 
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/CANfRfr0UDTSCZ8s7SpbuP%3DRwoZJT1P1RPbO5x_LQX7t3msnD6A%40mail.gmail.com.

Re: Proposal: New twitter contributors

[Adrien Lecharpentier]

of course +1!

Le mer. 11 déc. 2019 à 18:31, Arnaud Héritier  a
écrit :

> +1
>
> Le mer. 11 déc. 2019 à 17:44, Baptiste Mathus  a écrit :
>
>> +2, I mean. So very yey ;)
>>
>> Le mer. 11 déc. 2019 à 17:38, Kohsuke Kawaguchi  a
>> écrit :
>>
>>> Yay, +1
>>>
>>> On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda 
>>> wrote:
>>>
 Hi all,

 As per the process outlined in JEP 10
 , I would like to
 propose two new Twitter Contributors for the @jenkinsci account.

 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets
 via the Advocacy gitter channel as well as tweeting community highlights
 around hacktoberfest, gsoc, SIGs, elections etc. For example
 https://twitter.com/oleg_nenashev/status/1202631389277032449
 https://twitter.com/oleg_nenashev/status/1194982086521872384
 https://twitter.com/oleg_nenashev/status/1176981880786313217

 2. Mark Waite - Mark regularly tweets around Platform SIG &
 Documentation SIG, Jenkins git plugin, Jenkins online meetups and other
 community highlights. For example:
 https://twitter.com/MarkEWaite/status/1190616140868808705
 https://twitter.com/MarkEWaite/status/1180093593073045504
 https://twitter.com/MarkEWaite/status/1192437176446812160

 By giving Oleg & Mark access to schedule tweets, etc it will help the
 community with more timely and regular communication around the many
 community activities and technical developments.

 Please go ahead and vote/comment on this proposal. I will also add to
 an upcoming board meeting for approval there.

 Regards,
 Tracy






 --
 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/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
 
 .

>>>
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>>> --
>>> 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/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%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/CANWgJS5MLLKKWcyxc0LmKdsBe4y%2BBFKdbnnEKLGaxs66P-J2Ng%40mail.gmail.com
>> 
>> .
>>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
> --
> 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/CAFNCU-_o9XdRj_TXALA_WbtJUBOP__Wh2AMpGjLWLQHf-dhhSA%40mail.gmail.com
> 
> .
>


-- 
Adrien Lecharpentier

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

Re: Proposal: New twitter contributors

[Arnaud Héritier]

+1

Le mer. 11 déc. 2019 à 17:44, Baptiste Mathus  a écrit :

> +2, I mean. So very yey ;)
>
> Le mer. 11 déc. 2019 à 17:38, Kohsuke Kawaguchi  a écrit :
>
>> Yay, +1
>>
>> On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda 
>> wrote:
>>
>>> Hi all,
>>>
>>> As per the process outlined in JEP 10
>>> , I would like to
>>> propose two new Twitter Contributors for the @jenkinsci account.
>>>
>>> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via
>>> the Advocacy gitter channel as well as tweeting community highlights around
>>> hacktoberfest, gsoc, SIGs, elections etc. For example
>>> https://twitter.com/oleg_nenashev/status/1202631389277032449
>>> https://twitter.com/oleg_nenashev/status/1194982086521872384
>>> https://twitter.com/oleg_nenashev/status/1176981880786313217
>>>
>>> 2. Mark Waite - Mark regularly tweets around Platform SIG &
>>> Documentation SIG, Jenkins git plugin, Jenkins online meetups and other
>>> community highlights. For example:
>>> https://twitter.com/MarkEWaite/status/1190616140868808705
>>> https://twitter.com/MarkEWaite/status/1180093593073045504
>>> https://twitter.com/MarkEWaite/status/1192437176446812160
>>>
>>> By giving Oleg & Mark access to schedule tweets, etc it will help the
>>> community with more timely and regular communication around the many
>>> community activities and technical developments.
>>>
>>> Please go ahead and vote/comment on this proposal. I will also add to an
>>> upcoming board meeting for approval there.
>>>
>>> Regards,
>>> Tracy
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Kohsuke Kawaguchi
>>
>> --
>> 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/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%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/CANWgJS5MLLKKWcyxc0LmKdsBe4y%2BBFKdbnnEKLGaxs66P-J2Ng%40mail.gmail.com
> 
> .
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

-- 
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/CAFNCU-_o9XdRj_TXALA_WbtJUBOP__Wh2AMpGjLWLQHf-dhhSA%40mail.gmail.com.

Re: Proposal: New twitter contributors

[Baptiste Mathus]

+2, I mean. So very yey ;)

Le mer. 11 déc. 2019 à 17:38, Kohsuke Kawaguchi  a écrit :

> Yay, +1
>
> On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda 
> wrote:
>
>> Hi all,
>>
>> As per the process outlined in JEP 10
>> , I would like to
>> propose two new Twitter Contributors for the @jenkinsci account.
>>
>> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via
>> the Advocacy gitter channel as well as tweeting community highlights around
>> hacktoberfest, gsoc, SIGs, elections etc. For example
>> https://twitter.com/oleg_nenashev/status/1202631389277032449
>> https://twitter.com/oleg_nenashev/status/1194982086521872384
>> https://twitter.com/oleg_nenashev/status/1176981880786313217
>>
>> 2. Mark Waite - Mark regularly tweets around Platform SIG & Documentation
>> SIG, Jenkins git plugin, Jenkins online meetups and other community
>> highlights. For example:
>> https://twitter.com/MarkEWaite/status/1190616140868808705
>> https://twitter.com/MarkEWaite/status/1180093593073045504
>> https://twitter.com/MarkEWaite/status/1192437176446812160
>>
>> By giving Oleg & Mark access to schedule tweets, etc it will help the
>> community with more timely and regular communication around the many
>> community activities and technical developments.
>>
>> Please go ahead and vote/comment on this proposal. I will also add to an
>> upcoming board meeting for approval there.
>>
>> Regards,
>> Tracy
>>
>>
>>
>>
>>
>>
>> --
>> 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/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Kohsuke Kawaguchi
>
> --
> 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/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%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/CANWgJS5MLLKKWcyxc0LmKdsBe4y%2BBFKdbnnEKLGaxs66P-J2Ng%40mail.gmail.com.

Re: Proposal: New twitter contributors

[Kohsuke Kawaguchi]

Yay, +1

On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda 
wrote:

> Hi all,
>
> As per the process outlined in JEP 10
> , I would like to
> propose two new Twitter Contributors for the @jenkinsci account.
>
> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via
> the Advocacy gitter channel as well as tweeting community highlights around
> hacktoberfest, gsoc, SIGs, elections etc. For example
> https://twitter.com/oleg_nenashev/status/1202631389277032449
> https://twitter.com/oleg_nenashev/status/1194982086521872384
> https://twitter.com/oleg_nenashev/status/1176981880786313217
>
> 2. Mark Waite - Mark regularly tweets around Platform SIG & Documentation
> SIG, Jenkins git plugin, Jenkins online meetups and other community
> highlights. For example:
> https://twitter.com/MarkEWaite/status/1190616140868808705
> https://twitter.com/MarkEWaite/status/1180093593073045504
> https://twitter.com/MarkEWaite/status/1192437176446812160
>
> By giving Oleg & Mark access to schedule tweets, etc it will help the
> community with more timely and regular communication around the many
> community activities and technical developments.
>
> Please go ahead and vote/comment on this proposal. I will also add to an
> upcoming board meeting for approval there.
>
> Regards,
> Tracy
>
>
>
>
>
>
> --
> 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/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
> 
> .
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%40mail.gmail.com.

Proposal: New twitter contributors

[Tracy Miranda]

Hi all,

As per the process outlined in JEP 10
, I would like to
propose two new Twitter Contributors for the @jenkinsci account.

1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via
the Advocacy gitter channel as well as tweeting community highlights around
hacktoberfest, gsoc, SIGs, elections etc. For example
https://twitter.com/oleg_nenashev/status/1202631389277032449
https://twitter.com/oleg_nenashev/status/1194982086521872384
https://twitter.com/oleg_nenashev/status/1176981880786313217

2. Mark Waite - Mark regularly tweets around Platform SIG & Documentation
SIG, Jenkins git plugin, Jenkins online meetups and other community
highlights. For example:
https://twitter.com/MarkEWaite/status/1190616140868808705
https://twitter.com/MarkEWaite/status/1180093593073045504
https://twitter.com/MarkEWaite/status/1192437176446812160

By giving Oleg & Mark access to schedule tweets, etc it will help the
community with more timely and regular communication around the many
community activities and technical developments.

Please go ahead and vote/comment on this proposal. I will also add to an
upcoming board meeting for approval there.

Regards,
Tracy

-- 
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/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com.

Re: Q: rename a variable without breaking compatibility in the declarative pipeline

[Robert Sandell]

Ah yes, that's gonna be a tricky one.

The problem is that the databound constructor no longer has a parameter
named "glob". changeset "something*" should still work fine I guess, but
since there is no databound constructor with that parameter or a databound
setter with the name setGlob it fails. But just adding a @DataboundSetter
setGlob(String glob) {pattern = glob;} won't solve it either since there is
now another mandatory parameter named "pattern" that must be passed. And
removing the databound constructor will break the changeset "something*"
calls.

Maybe there is something in the descriptor that can be overridden to
manually handle the various scenarios, like overriding configure or
newInstance but I don't remember if that is possible on the top of my head.

Den tis 10 dec. 2019 kl 20:45 skrev Victor Martinez <
victormartinezru...@gmail.com>:

> Hi there,
>
> I thought the readResolve
> 
> might be the way to go but apparently I missed something and then there are
> no backward compatible for the when changeset
>  and
> likely the same for the
> when
> branch
>  in
> the declarative pipeline syntax. See the comment in
> https://issues.jenkins-ci.org/browse/JENKINS-60217?focusedCommentId=381168&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-381168
>  as
> it did report a breaking change.
>
> I'd like to ask you what are the bits and pieces I missed and some
> suggestions to validate this somehow automatically with some testing.
>
> 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/6cd3a4d5-8b36-4fd3-91e2-b0629d0f6856%40googlegroups.com
> 
> .
>


-- 
*Robert Sandell*
Software Engineer
CloudBees, Inc.
[image: CloudBees-Logo.png] 
E: rsand...@cloudbees.com
Twitter: robert_sandell

-- 
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/CALzHZS2AG04vvYOqo49a9T%2B3-UwCqXOSyjuCCOayfuVA3pmuAw%40mail.gmail.com.

Re: findsecbugs in spotbugs

[James Nord]

I had a quick peek at the 2 PRs and my main concern is that this found no 
security issues and forced annotations on a lot of places, that is it found 
no issues according to the PRs.

Whilst it could prevent issues being introduced in the future I am 
concerned it will cause 99% `@SuppressFBWarning` annoyance and not find the 
security issue.
The suppressions are also overly broad - for example 
https://github.com/jenkinsci/jenkins/pull/4381/files#diff-6b2c22336dd63b20019b8558c7e9a13fR599-R601
  
is completely incorrect.  This code can not make assumptions about the 
callers - only the caller of that method can make it and as such the 
Annotation needs to be on those methods not the utility method.

in other words I think if this just causes pain by having to add suppress 
warnings then I think it would be a bad thing.  I would be happy to see it 
catch the first real issue - but if that does not happen in a long time I 
think we should be prepared to back this out.  

my 2c.

On Wednesday, December 11, 2019 at 12:44:36 AM UTC, Raihaan Shouhell wrote:
>
> Hey Jeff,
>
> I think it is ok to introduce it. Sounds like it would add value. 
> There should be a switch to at least disable failing the build because of 
> findsecbugs.
>
> Despite the potential problems with introducing it, I am +1 on it since it 
> will definitely help the development of new plugins.
>
> Like you said spotbugs has actually helped find a ton of bugs, I even find 
> myself getting annoyed when the relevant annotation was missing that could 
> potentially avoid a bug.
> If this tool can help us avoid security issues the same way spotbugs helps 
> with bugs that would be awesome.
>
> Cheers,
> Raihaan
>
> On Wednesday, 11 December 2019 04:27:16 UTC+8, Jeff Thompson wrote:
>>
>> Jenkins developers, 
>>
>> I've been working on introducing findsecbugs into the Jenkins developer 
>> ecosystem. findsecbugs is a plugin for spotbugs (formerly findbugs) that 
>> adds analysis for a significant collection of bug rules that could 
>> potentially impact security. More information is at 
>> https://find-sec-bugs.github.io/ 
>>
>> I've got PRs about ready for merge to introduce findsecbugs into Jenkins 
>> ( https://github.com/jenkinsci/jenkins/pull/4381 ) and Remoting ( 
>> https://github.com/jenkinsci/remoting/pull/361 ). 
>>
>> The problem with introducing a tool like this in any legacy software is 
>> that it finds things that could have been better implemented or are 
>> outdated but are not real issues. Turning it on means going through the 
>> all the findings, analyzing them, and then suppressing them (hopefully 
>> individually) or fixing them. I've done that in my two PRs. 
>>
>> I've also gone through this with a sampling of 7 plugins. Only one of 
>> them didn't detect any findings, but they didn't necessarily have any 
>> real security issues. I intend to push PRs for these plugins I've tried 
>> in the coming days. 
>>
>> I believe there is a lot of value in having this tool detect new, 
>> potential issues as we move forward with changes and new code. I've been 
>> glad in the past at how spotbugs and other tools help catch things 
>> before PRs are merged. 
>>
>> I want to get findsecbugs turned on in the parent plugin pom. 
>> @StefanSpieker also has a PR to turn it on in the parent Jenkins pom. 
>>
>> I'm not sure whether we need to be more cautious about turning 
>> findsecbugs on in the parent poms. Do we need to make it opt-in? How do 
>> we encourage people to opt-in? Or, does that just become something 
>> everyone has to do to move forward to latest poms? At a minimum I think 
>> we should use @StefanSpieker's PR to turn it on in the Jenkins parent 
>> pom. 
>>
>> Jeff Thompson 
>>
>>

-- 
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/b1fde6e8-38df-4c4c-9da5-fbf616c2c099%40googlegroups.com.

Re: Proposal: Detaching Git Server from Pipeline: Shared Groovy Libraries to a separate plugin

[Mark Waite]

That seems like a very good compromise to me. Reduce footprint for those
that do not need it, and retain capabilities thru an extra plugin for those
that need it

On Wed, Dec 11, 2019, 1:09 PM Oleg Nenashev  wrote:

> Hi all,
>
> I am an active user of Pipeline Shared Libraries which are currently
> defined in the Pipeline: Shared Groovy Libraries
>  plugin.
> Historically the plugin was exposing a Git Server, and the code is still
> there and enabled by default (WorkflowLibRepository
> ,
> WorkflowLibSshRepository
> ,
> etc.). This mode makes the Git Server Plugin a hard requirement for Jenkins
> Pipeline, and it also causes startup overhead on Jenkins and Jenkinsfile
> Runner instances.
>
> I doubt that the Git Server mode is popular at the moment, because now
> there is embedded SCM Source support and a LibraryResolver
> 
>  extension
> point which allows defining library sources as extensions. I would suggest
> to detach the Git Server mode to a separate plugin so that the majority of
> users do not depend on it.
>
> What do I propose to do?
>
>- Git Server functionality is detached into a separate "Pipeline:
>Shared Library Git Server" plugin. It includes all the current codebase and
>retains the package names to retain the configuration/binary compatibility
>- New major version of "Pipeline: Shared Groovy Libraries" is
>released, the version is marked as incompatible
>
> There are potential ways to do the change without formally breaking
> changes, e.g. via detaching the API side into uostream plugin instead of
> creating a separate plugin. But it causes a lot more overhead for plugin
> maintainers and instance maintainers who would have to cleanup the plugin
> sets on their own. IMHO in this case such effort is not justified.
>
> Would appreciate any feedback.
>
> Thanks in advance,
> Oleg
>
> --
> 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/CAPfivLC6purejJc7s_Cv5-1XNjEqbYboJr0QrSMriMhuZ6DUOw%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/CAO49JtG%2Bu_VN1ZZr7JuTvx_sYT87iSPXPSaPKpcsKWu9qAo3kg%40mail.gmail.com.

Proposal: Detaching Git Server from Pipeline: Shared Groovy Libraries to a separate plugin

[Oleg Nenashev]

Hi all,

I am an active user of Pipeline Shared Libraries which are currently
defined in the Pipeline: Shared Groovy Libraries
 plugin.
Historically the plugin was exposing a Git Server, and the code is still
there and enabled by default (WorkflowLibRepository
,
WorkflowLibSshRepository
,
etc.). This mode makes the Git Server Plugin a hard requirement for Jenkins
Pipeline, and it also causes startup overhead on Jenkins and Jenkinsfile
Runner instances.

I doubt that the Git Server mode is popular at the moment, because now
there is embedded SCM Source support and a LibraryResolver

extension
point which allows defining library sources as extensions. I would suggest
to detach the Git Server mode to a separate plugin so that the majority of
users do not depend on it.

What do I propose to do?

   - Git Server functionality is detached into a separate "Pipeline: Shared
   Library Git Server" plugin. It includes all the current codebase and
   retains the package names to retain the configuration/binary compatibility
   - New major version of "Pipeline: Shared Groovy Libraries" is released,
   the version is marked as incompatible

There are potential ways to do the change without formally breaking
changes, e.g. via detaching the API side into uostream plugin instead of
creating a separate plugin. But it causes a lot more overhead for plugin
maintainers and instance maintainers who would have to cleanup the plugin
sets on their own. IMHO in this case such effort is not justified.

Would appreciate any feedback.

Thanks in advance,
Oleg

-- 
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/CAPfivLC6purejJc7s_Cv5-1XNjEqbYboJr0QrSMriMhuZ6DUOw%40mail.gmail.com.

Re: 2019 Election: voting has closed

[Oleg Nenashev]

I suggest to have a retrospective discussion at the Advocacy&Outreach SIG 
meeting next week (Dec 19). It would be a great venue to discuss the 
feedback and to define the next action items. We will also have a Jenkins 
Governance Board meeting today at 6PM UTC, I will add the Board Election 
results & Feedback to the agenda.

W.r.t other action items:

   - I have created an EPIC for updating the website and other resources: 
   WEBSITE-692 . If you 
   see something missing, please create tickets there
   - https://jenkins.io/project/board/ should be updated once the 
   jenkins.io CD Pipeline recovers (update center slowness causes the build 
   failure IIUC)
   - There is a pending pull request draft with the election results 
   blogpost: https://github.com/jenkins-infra/jenkins.io/pull/2706 . I 
   invite other contributors to participate as co-authors there




On Wednesday, December 11, 2019 at 2:54:58 AM UTC+1, martinda wrote:
>
> Thank you KK, I added my feedback.
>
> On Tuesday, December 3, 2019 at 9:58:02 AM UTC-5, Kohsuke Kawaguchi wrote:
>>
>> I believe you can edit the document directly. The documen is WiP at the 
>> moment, so feel free to add text, comment, provide edit suggestions, etc. 
>> If you prefer, prefix the text with your name.
>>
>> Looking forward to seeing your feedback.
>>
>>

-- 
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/5ac589f4-73ab-4a8c-8442-abec9391ec2f%40googlegroups.com.

Jenkins UX SIG Meeting Today

[Jeremy Hartley]

Hi,

*Note: *This will be the last time I spam the Jenkins Developer group. If 
you are interested in the future of Jenkins UX please head over to the Jenkins 
User Experience mailing list 
. 

A quick reminder that the 2nd meeting of the Jenkins User Experience SIG 
will take place today (Wednesday 11th of December) at 1600 UTC (1700 CET, 
1100 EST). You can join the meeting via Zoom 
https://cloudbees.zoom.us/j/680011261. 


Anybody is free to join. If you would like to be added to the invite please 
provide me your email address and I will send you an invite.

You can find the proposed meeting agenda 

 
here. This is also where the minutes will be posted after the meeting.

Thanks

Jeremy Hartley

-- 
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/1d3bf31f-3c28-4c1e-a373-0d1b261a9349%40googlegroups.com.