from:"Jeff"

Re: How to integrate git plugin in my plugin?

2023-11-15 Thread Jeff Pearce

It’s probably doable, but it founds like a file secret could serve your purpose. It would be readable from any job in Jenkins as well as your plugin Sent from my iPhoneOn Nov 15, 2023, at 8:31 AM, tzach@gmail.com wrote:My scenario is that i have a JSON file located in a remote repo.In that file there is a configuration I need for the plugin.I want to be able to pull that file and read it in my plugin.The reason for it being in the remote repo as it serves also other applications and not just my plugin.Is it doable?Thanks,TzachOn Wednesday, 15 November 2023 at 18:01:39 UTC+2 jef...@gmail.com wrote:Have you looked at the source for the Github Branch Source plugin? I imagine it has examples of how to do many things.From your description though, it sounds like you might be able to store your configuration in Jenkins itself? Maybe as a secret? That said, I have to admit I don't 100% understand your scenario.BestJeffOn Wed, Nov 15, 2023 at 7:14 AM tzach@gmail.com wrote:Hi,I have a private that needs configuration.That configuration is stored in a remote git repository.I would like to harness git plugin and use it in my plugin.Is there an example of how to do it?Thanks,Tzach

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/33209811-581c-434c-836f-6461e509d636n%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/6d1595d3-8c54-45b5-a3c2-910b5edd61aan%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/B3CE9BF6-4B36-4880-A78D-E172B748E8F0%40gmail.com.

Re: How to integrate git plugin in my plugin?

2023-11-15 Thread Jeff Pearce

Have you looked at the source for the Github Branch Source plugin? I
imagine it has examples of how to do many things.

>From your description though, it sounds like you might be able to store
your configuration in Jenkins itself? Maybe as a secret? That said, I have
to admit I don't 100% understand your scenario.

Best
Jeff

On Wed, Nov 15, 2023 at 7:14 AM tzach@gmail.com 
wrote:

> Hi,
>
> I have a private that needs configuration.
> That configuration is stored in a remote git repository.
> I would like to harness git plugin and use it in my plugin.
> Is there an example of how to do it?
>
> Thanks,
> Tzach
>
> --
> 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/33209811-581c-434c-836f-6461e509d636n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/33209811-581c-434c-836f-6461e509d636n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

Re: ERROR: No test report files were found. Configuration error?

2022-05-20 Thread 'Jeff Pearce' via Jenkins Developers

I believe I’ve seen that when the build failed and tests weren’t even ran

From:  on behalf of priya jagyasi 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Friday, May 20, 2022 at 6:17 AM
To: Jenkins Developers 
Subject: ERROR: No test report files were found. Configuration error?

You don't often get email from jagyasi.priy...@gmail.com. Learn why this is 
important
Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.

Hi,

I am getting this error on jenkins build for my plugin. What does this error 
mean?

Regards,
Priya
--
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/384cd5db-b27d-4290-981c-8cabad9dcf3bn%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/54810C58-F5E0-43C2-AD40-363CBA88AE24%40godaddy.com.

Re: Jenkins Core pull-requests management

2022-03-22 Thread Jeff

This seems reasonable to me. After some period of time (months? years?) the
PR is unlikely to be merged, so why keep it open if it's truly stale?


On Tue, Mar 22, 2022 at 9:07 AM Adrien Lecharpentier <
adrien.lecharpent...@gmail.com> wrote:

> Hello everyone,
>
> I've spent some time lately on looking at the pull-requests on
> jenkinsci/jenkins repository. For some old, inactive pull-requests I've
> pinged the authors and for some, added the proposed-for-close label.
>
> However, the label description nor any prior discussion on the
> mailing-list are mentioning our policy about this (proposed-for-close)
> label. And I'd like to offer one: I'd like, as for the ready-for-merge
> label, to introduce a period of time, after which with no response from the
> author, we close the pull-request. I was thinking about 72 or 96hr.
>
> This might seem a bit harsh, but my idea is to try to keep the
> pull-requests list healthy. And when we have no consensus on the PR or no
> response from the authors, it's healthier to close the pull-request. The
> work done is not lost, the PR can be reopen later when the author is more
> available to attend to it.
>
> Also, in case the authors respond, we can simply put the label stalled
> (for others to take over the PR). We could also put the PR back into draft,
> but all members have enough permission to do that on others pull-requests,
> but we could use the work-in-progress. Of course, after another period of
> time, with no more activities, we should close the PR anyway.
>
> Also, there is no mention of those labels, what they means and how we use
> it on our contribution guide [1]. Should we add a mention of those label on
> it?
>
> -- Adrien
>
> [1]: https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md
>
> --
> 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/CAKwJSvwTnxuwe1WZzs3eSJBgq783fMm8hkQ_-%3DFHS1u0%2B7GUAw%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/CADVhPTr%3DtRKmzoVfktCwGkUrLPKYPRV254wzWJEKMU0v0u-xwg%40mail.gmail.com.

Re: ANN - Jenkins Governance update (Marky Jackson)

2021-03-04 Thread Jeff Pearce

Thanks for all you’ve contributed over the past several years, Marky. Your 
contributions have made a notable difference. 

Sent from my iPhone

> On Mar 4, 2021, at 6:34 AM, Oleg Nenashev  wrote:
> 
> 
> Notice: This email is from an external sender.
>  
> 
> Dear all,
> 
> Effective today, Marky Jackson is stepping down from the Jenkins Governance 
> Board and Event Officer positions. On behalf of the Jenkins community, we 
> would like to thank Marky for all contributions and for the continued 
> participation in the Jenkins community. As an active Jenkins contributor and 
> community leader, Marky helped a lot of initiatives to happen: Jenkins and 
> Kubernetes ecosystem, terminology changes, GSoC and GSoD, pipeline authoring 
> SIG and many more activities. Thank you Marky!
> 
> Based on the Interim procedures, the Jenkins Governance board will appoint an 
> interim board member and a new event officer, subject to approval in a 
> regular governance meeting (Mar 10). Nominations:
> Jenkins Governance Board member - the board would like to respect the 2020 
> Election Results and to appoint Ewelina Wilkosz as an interim board member. 
> Ewelina got the most of the votes among board member candidates.
> Event Officer - nominations are open! If you are interested to become the new 
> even officer, please reach out to the Jenkins Governance Board.
> Best regards,
> Oleg Nenashev
> 
> 
> -- 
> 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/CAPfivLAtsyGErEEspBRESgknamtfAO1C9V3TjnWW5y8zSLXz1A%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/EE3EA218-466C-48D8-9AEB-04C743307256%40gmail.com.

Re: [Plugin Development] API to listen to the end of the execution of a step and to collect its result?

2021-01-13 Thread Jeff

Happy to have a chat. What time zone are you in? I'm on the US West Coast
(PST). I'm not sure whether anyone else in the community is interested, but
replying to the group just in case.

On Wed, Jan 13, 2021 at 1:26 AM 'Cyrille Le Clerc' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hello Jeff,
>
> It's a great idea to include the tracing and the OpenTelemetry
> capabilities in the "Job and Stage monitoring plugin".
>
> Would you have a moment to have a video conversation to align on the
> vision and to discuss the way to move forward?
>
> Cyrille
>
> On Tuesday, January 12, 2021 at 5:13:11 PM UTC+1 jef...@gmail.com wrote:
>
>> I'm the author of the "Job and Stage monitoring plugin"
>>
>> Have you considered extending that plugin? I don't entirely understand
>> what you're trying to accomplish, but to the extent it overlaps with your
>> proposed plugin, it's probably better for the community not to have two
>> similar plugins. Most users aren't going to understand the differences
>> between two similar plugins, which is confusing and frustrating.
>>
>> The "Job and Stage monitoring plugin" watches jobs, and allows code to
>> take arbitrary actions at the end of each step in a job, and also at the
>> end of the job. Said code can either be hosted in the JSM plugin, or an
>> entirely separate plugin.
>>
>> On Tue, Jan 12, 2021 at 4:14 AM Andrey Babushkin 
>> wrote:
>>
>>>
>>> You can take a look at Job and Stage monitoring plugin (
>>> https://github.com/jenkinsci/github-autostatus-plugin). I think it does
>>> the thing you're looking for.
>>> On Tuesday, January 12, 2021 at 4:50:23 AM UTC+3 Mark Waite wrote:
>>>
>>>> On Mon, Jan 11, 2021 at 6:24 PM 'Cyrille Le Clerc' via Jenkins
>>>> Developers  wrote:
>>>>
>>>>> Dear community,
>>>>>
>>>>> *Context: *
>>>>> I'm trying to implement an OpenTelemetry instrumentation of Jenkins,
>>>>> starting injecting distributed traces in job executions. See
>>>>> https://github.com/cyrille-leclerc/opentelemetry-plugin
>>>>>
>>>>> *Question: *
>>>>> *What is the recommended way to listen to the end of the execution of
>>>>> a step and to collect its result?*
>>>>> I would like to listen the end of execution of `stage`and `git` steps
>>>>> to end a trace span reporting the result of the step.
>>>>>
>>>>> I found the `GraphListener#onNewHead(FlowNode)` API and I identify the
>>>>> end of stage steps with `StepEndNode` containing a   whose descriptor is a
>>>>> `StageStep.DescriptorImpl` but
>>>>>
>>>>>- I am not clear on if I should track the `StepEndNode` containing
>>>>>a `LabelAction` or an `ArgumentsAction`
>>>>>- On none of the StepEndNode give me access to the error thrown
>>>>>during the execution to indicate a failure,  `StepEndNode#getError()` 
>>>>> and
>>>>>`StepEndNode.getExecution.getCauseOfFailure()` return null
>>>>>during  `GraphListener#onNewHead(FlowNode)`
>>>>>
>>>>> I'm wondering if I have to add a `BodyExecutionCallback` to the `
>>>>> CpsBodyInvoker` but I didn't find an API to do this implementing a
>>>>> listener of the pipeline executions.
>>>>>
>>>>> I have a similar request for `git` steps that don't even have a
>>>>> `StepEndNode`, how can I intercept the end of execution and the
>>>>> result/error of the execution of a `git` step.
>>>>>
>>>>>
>>>>
>>>> I don't know the answer to your listener question.  This is probably
>>>> not what you want to hear, but I think that you should focus on the
>>>> checkout step rather than the git step.  Per the git step documentation:
>>>>
>>>> More advanced checkout operations require the checkout step rather
>>>> than the git step.
>>>>
>>>> The git step is a simplified shorthand for a subset of the more
>>>> powerful checkout step:
>>>>
>>>> checkout([$class: 'GitSCM', branches: [[name: '*/master']],
>>>> userRemoteConfigs: [[url: 'http://git-server/user/repository.git']]])
>>>>
>>>>
>>>>
>>>>
>>>>> I hope my question is detailed enough.
>>>>>
>>>>> Cyrille
>&

Re: Unforking Commons FileUpload

2021-01-13 Thread Jeff Thompson



On 1/13/21 6:27 AM, Jesse Glick wrote:
On Wed, Jan 13, 2021 at 12:09 AM Basil Crow > wrote:


Can you see a flaw in my reasoning?


Sounds right from a five-second read. Just asking that anyone 
proposing an unfork do the work of checking that 
`FileParameterDefinition` is not affected (I am not sure that 
automated tests cover the form upload mode realistically) and search 
proactively for mentions of `FileItem` in plugins that ought to be tested.


+1


--
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/e1f0a16b-3d91-0ea3-ab26-a0b21059feb1%40cloudbees.com.

Re: Unforking Commons FileUpload

2021-01-12 Thread Jeff Thompson

I'm in favor of unforking, wherever we can. A while back I unforked 
dom4j. It turned out the forked additions were essentially unused, but 
it took a long time to validate everything. Since JEP-200, the extra 
precaution to make DiskFileItem unserializable probably isn't needed, 
though that needs to be checked with the whitelist.


I haven't investigated the changes and the usage, but it looks like it 
could be unforked. That would definitely be a nice improvement.


Jeff Thompson


On 1/11/21 5:58 PM, Basil Crow wrote:

Jenkins core uses a fork of Commons FileUpload 1.3.1. Changes to
org.apache.commons.fileupload.FileItem and
org.apache.commons.fileupload.disk.DiskFileItem were made in
1.3.1-jenkins-1, and a change to
org.apache.commons.fileupload.MultipartStream was made in
1.3.1-jenkins-2. The change made in 1.3.1-jenkins-2 is just a backport
of the upstream fix for CVE-2016-3092 (released upstream as 1.3.2) for
SECURITY-490. The primary reason for the fork is the change made in
1.3.1-jenkins-1. The commit message for this change states: "[FIXED
SECURITY-159] Bumping up dependencies to 1.3.1, with extra precaution
to make DiskFileItem non-serializable." The security advisory for
SECURITY-159 states: "Security vulnerability in commons fileupload
allows unauthenticated attacker to upload arbitrary files to the
Jenkins controller." Is this "extra precaution" necessary? Do we want
to consider unforking Commons FileUpload?

diff --git a/pom.xml b/pom.xml
index 5228423..b046e78 100644
--- a/pom.xml
+++ b/pom.xml
@@ -26,7 +26,7 @@

commons-fileupload
commons-fileupload
-  1.3.1
+  1.3.1-jenkins-2

Apache Commons FileUpload

@@ -166,11 +166,6 @@
  


-  
-
scm:svn:http://svn.apache.org/repos/asf/commons/proper/fileupload/trunk
-
scm:svn:https://svn.apache.org/repos/asf/commons/proper/fileupload/trunk
-http://svn.apache.org/viewvc/commons/proper/fileupload/trunk
-  

  jira
  http://issues.apache.org/jira/browse/FILEUPLOAD
@@ -216,6 +211,7 @@
  


+  


  
@@ -295,4 +292,17 @@
  


+  
+
+  maven.jenkins-ci.org
+  https://repo.jenkins-ci.org/releases/
+
+  
+
+  
+
scm:git:git://github.com/jenkinsci/commons-fileupload.git
+
scm:git:g...@github.com:jenkinsci/commons-fileupload.git
+http://github.com/jenkinsci/commons-fileupload
+commons-fileupload-1.3.1-jenkins-2
+  
  
diff --git a/src/main/java/org/apache/commons/fileupload/FileItem.java
b/src/main/java/org/apache/commons/fileupload/FileItem.java
index d1b5c18..3a7f8b0 100644
--- a/src/main/java/org/apache/commons/fileupload/FileItem.java
+++ b/src/main/java/org/apache/commons/fileupload/FileItem.java
@@ -46,7 +46,7 @@ import java.io.UnsupportedEncodingException;
   * @version $Id: FileItem.java 1454690 2013-03-09 12:08:48Z simonetripodi $
   * @since 1.3 additionally implements FileItemHeadersSupport
   */
-public interface FileItem extends Serializable, FileItemHeadersSupport {
+public interface FileItem extends FileItemHeadersSupport {

  // --- Methods from 
javax.activation.DataSource

diff --git a/src/main/java/org/apache/commons/fileupload/MultipartStream.java
b/src/main/java/org/apache/commons/fileupload/MultipartStream.java
index a27e1ae..452192a 100644
--- a/src/main/java/org/apache/commons/fileupload/MultipartStream.java
+++ b/src/main/java/org/apache/commons/fileupload/MultipartStream.java
@@ -326,11 +326,6 @@ public class MultipartStream {
  throw new IllegalArgumentException("boundary may not be null");
  }

-this.input = input;
-this.bufSize = bufSize;
-this.buffer = new byte[bufSize];
-this.notifier = pNotifier;
-
  // We prepend CR/LF to the boundary to chop trailing CR/LF from
  // body-data tokens.
  this.boundaryLength = boundary.length + BOUNDARY_PREFIX.length;
@@ -338,6 +333,12 @@ public class MultipartStream {
  throw new IllegalArgumentException(
  "The buffer size specified for the
MultipartStream is too small");
  }
+
+this.input = input;
+this.bufSize = Math.max(bufSize, boundaryLength*2);
+this.buffer = new byte[this.bufSize];
+this.notifier = pNotifier;
+
  this.boundary = new byte[this.boundaryLength];
  this.keepRegion = this.boundary.length;

diff --git a/src/main/java/org/apache/commons/fileupload/disk/DiskFileItem.java
b/src/main/java/org/apache/commons/fileupload/disk/DiskFileItem.java
index 550a7ed..3d258b1 100644
--- a/src/main/java/org/apache/commons/fileupload/disk/DiskFileItem.java
+++ b/src/main/java/org/apache/commons/fileupload/disk/DiskFileItem.java
@@ -644,53 +644,6 @@ public class DiskFileItem
  out.defaultWriteObject();
  }

-/**
- * Reads the state of this object during deserialization.
- *
- * @param in The stream from which the state s

Re: [Plugin Development] API to listen to the end of the execution of a step and to collect its result?

2021-01-12 Thread Jeff

I'm the author of the "Job and Stage monitoring plugin"

Have you considered extending that plugin? I don't entirely understand what
you're trying to accomplish, but to the extent it overlaps with your
proposed plugin, it's probably better for the community not to have two
similar plugins. Most users aren't going to understand the differences
between two similar plugins, which is confusing and frustrating.

The "Job and Stage monitoring plugin" watches jobs, and allows code to take
arbitrary actions at the end of each step in a job, and also at the end of
the job. Said code can either be hosted in the JSM plugin, or an entirely
separate plugin.

On Tue, Jan 12, 2021 at 4:14 AM Andrey Babushkin  wrote:

>
> You can take a look at Job and Stage monitoring plugin (
> https://github.com/jenkinsci/github-autostatus-plugin). I think it does
> the thing you're looking for.
> On Tuesday, January 12, 2021 at 4:50:23 AM UTC+3 Mark Waite wrote:
>
>> On Mon, Jan 11, 2021 at 6:24 PM 'Cyrille Le Clerc' via Jenkins Developers
>>  wrote:
>>
>>> Dear community,
>>>
>>> *Context: *
>>> I'm trying to implement an OpenTelemetry instrumentation of Jenkins,
>>> starting injecting distributed traces in job executions. See
>>> https://github.com/cyrille-leclerc/opentelemetry-plugin
>>>
>>> *Question: *
>>> *What is the recommended way to listen to the end of the execution of a
>>> step and to collect its result?*
>>> I would like to listen the end of execution of `stage`and `git` steps to
>>> end a trace span reporting the result of the step.
>>>
>>> I found the `GraphListener#onNewHead(FlowNode)` API and I identify the
>>> end of stage steps with `StepEndNode` containing a   whose descriptor is a
>>> `StageStep.DescriptorImpl` but
>>>
>>>- I am not clear on if I should track the `StepEndNode` containing a
>>>`LabelAction` or an `ArgumentsAction`
>>>- On none of the StepEndNode give me access to the error thrown
>>>during the execution to indicate a failure,  `StepEndNode#getError()` and
>>>`StepEndNode.getExecution.getCauseOfFailure()` return null
>>>during  `GraphListener#onNewHead(FlowNode)`
>>>
>>> I'm wondering if I have to add a `BodyExecutionCallback` to the `
>>> CpsBodyInvoker` but I didn't find an API to do this implementing a
>>> listener of the pipeline executions.
>>>
>>> I have a similar request for `git` steps that don't even have a
>>> `StepEndNode`, how can I intercept the end of execution and the
>>> result/error of the execution of a `git` step.
>>>
>>>
>>
>> I don't know the answer to your listener question.  This is probably not
>> what you want to hear, but I think that you should focus on the checkout
>> step rather than the git step.  Per the git step documentation:
>>
>> More advanced checkout operations require the checkout step rather than
>> the git step.
>>
>> The git step is a simplified shorthand for a subset of the more powerful
>> checkout step:
>>
>> checkout([$class: 'GitSCM', branches: [[name: '*/master']],
>> userRemoteConfigs: [[url: 'http://git-server/user/repository.git']]])
>>
>>
>>
>>
>>> I hope my question is detailed enough.
>>>
>>> Cyrille
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/db5376b1-3888-46f0-9429-9b34e3940ed9n%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/a1012b64-1979-47a5-9646-832e21376146n%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/CADVhPTqzStaAww54%3DqXJL4XNfzyW0E2z3o-d7XXcYL7yu7dGXQ%40mail.gmail.com.

Re: Hacktoberfest is coming

2020-09-18 Thread Jeff

I'm happy to help with reviewing PRs

Jeff

On Wed, Aug 26, 2020 at 7:41 PM Mark Waite 
wrote:

> We had a very successful experience with last year's Hacktoberfest
> contributions to the Jenkins project.  This year we need help to prepare
> for Hacktoberfest and to review Hacktoberfest contributions during October.
>
> You can read about the 2019 Hacktoberfest
> <https://www.jenkins.io/events/hacktoberfest/> to see some of the types
> of things that could be done as part of 2020 Hacktoberfest.
>
> We need additional help to prepare for Hacktoberfest.  We're looking for
> volunteers that can help with:
>
>- Plan, host, and present at one or more Jenkins Online Meetups for
>Hacktoberfest,  similar to the 2019 welcome session
><https://www.youtube.com/watch?v=nLTfJOZG5kw>
>- Recommend and describe featured projects as pull requests to the 
> Hacktoberfest
>page
>
> <https://github.com/jenkins-infra/jenkins.io/edit/master/content//events/hacktoberfest.adoc>
>- Identify good first issues in Jenkins plugins, Jenkins core, and
>Jenkins docs (Jira issues and GitHub issues)
>- Write a Hacktoberfest blog post similar to the 2019 blog post
><https://www.jenkins.io/blog/2019/10/01/hacktoberfest/>
>- Review Hacktoberfest pull requests
>
> Volunteers, please reply to this message or comment in the Hacktoberfest
> gitter channel at https://gitter.im/jenkinsci/hacktoberfest .
>
> Thanks,
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/f9118fb0-753a-4c52-a2f0-38a3d8245c07n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/f9118fb0-753a-4c52-a2f0-38a3d8245c07n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

Re: Terminology: agent vs node

2020-07-21 Thread Jeff Thompson

Yes, the usages of these terms should cleaned up and made consistent.
"agent" is a better term in almost all cases. Sometimes there is a
technical distinction between the terms, but we should only use "node"
where we really need to distinguish that and use "agent" as much as
possible in the UI.

Jeff

On 7/21/20 3:05 PM, 'Martin Schmude' via Jenkins Developers wrote:

Dear all,

on the occasion of the current effort to replace the term "master" I
learnt, that back in 2016 it had been decided to replace "slave" by
"agent".

This reminds me of that I am worried from time to time by the terms
"agent" and "node".

They seem to be synonyms - am I right?
If so, shouldn't "agent" be the preferred term, due to the decision of
2016 and "node" be dropped?

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/142ebe47-dbc5-4bf5-8bf1-96f69517983ao%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-dev/142ebe47-dbc5-4bf5-8bf1-96f69517983ao%40googlegroups.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/acbbef58-9b51-6515-2d07-daefc1f12aaa%40cloudbees.com.

Re: Jenkins Terminology Poll for ‘master’

2020-07-21 Thread Jeff Thompson

Is this the right link? I'm seeing results but not how to participate.

Jeff

On 7/21/20 1:19 PM, Mark Waite wrote:

The Jenkins terminology poll
<https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1bd92a17371a1ca5> for
the “master” term replacement is open at
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1bd92a17371a1ca5 .
We would appreciate your votes! If you are interested to participate,
please submit your choice by July 29, 14:00 PM UTC.

Context: As decided at the Jun 17, 2020 Governance meeting, we plan to
replace the “master” term which is currently used to describe the
Jenkins application with its web user interface and distribution of
work to agents. The Jenkins board has identified 8 potential options,
and we would like to understand preferences of the Jenkins community
members before choosing a final option. Refer to the Jenkins
Developers mailing list thread
<https://groups.google.com/g/jenkinsci-dev/c/CLR55wMZwZ8/m/uDjgGlnKAQAJ> for
more information.

Thanks,
Mark Waite
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/0bfae5dc-7639-4186-b425-23e12e19d64fn%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-dev/0bfae5dc-7639-4186-b425-23e12e19d64fn%40googlegroups.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/70757f06-e813-36a9-9349-600439fa96ba%40cloudbees.com.

Re: Terminology Updates

2020-07-17 Thread Jeff Thompson


On 7/16/20 7:52 AM, Runxia Ye wrote:
From the shortlisted options 
<https://docs.google.com/document/d/1-8myIWOZZktR0HNtbFIiNA0RfDCvkfKKuNI0C3wcvbo/edit#heading=h.nuysq0m8yl6n> 
selected by the governance board, I see words that in many languages 
have both a male and a female variant. The "default" version 
implicitly implies the the "male" variant. I know we are already 
taking a lot of different aspects into account, so I want to bring to 
attention this implicit association/unconscious bias that we may be 
having when choosing some of these words.


That's a good point. Do you happen to have any suggestions on how to 
deal with this issue? I know a little bit of Spanish and am familiar 
with gendered nouns there. I don't have any idea how people are 
addressing bias in these languages.


Jeff

--
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/cb5eb227-9180-c03e-f6eb-974a72515473%40cloudbees.com.

Re: Terminology Updates

2020-06-25 Thread Jeff Thompson

"maestro" is problematic in our context because it's too similar to the
word we're trying to replace. Because of our usage history, that's a
bigger issue than it might be in other contexts. In English, though they
may have nuanced common usages, they're both basically the same word.
They just got to modern English via different paths. They both derive
from the same Latin root. We would be better to select something
noticeably different.

We should definitely keep i18n in mind in choosing a name.

Jeff

On 6/24/20 4:49 PM, Thomas de Grenier de Latour wrote:
As a native French speaker too, I fear that "conductor" would be
difficult to translate in French. With its "musical director" meaning,
it would be "chef d'orchestre", which is so explicit that it leaves
little room for a figurative sense (and it's also really long). The
word "conducteur" exists in French, but not with this meaning (it's
either an electrical wire, or a car driver; none of which being a good
analogy for the work Jenkins does).

To stay in the same lexical field, I would rather go with "maestro" (a
skilled / well-known conductor), because this word would be understood
as-is at least by Italian (obviously), English, French, and Spanish
speakers (maybe German speakers too, maybe others). Plus, for people
used to the historical Jenkins terminology, it gives an etymological
hint that it is indeed the new word for "master", and not a
new/different concept.

Now, that being said, you can't go wrong with "controller" I think, so
it would have my preference too. I don't think the potential confusion
with k8s controllers is an issue (when writing about Jenkins
deployment on K8S, use "K8S controller" / "Jenkins controller" to
avoid any ambiguity). The word is so widely used in IT that we can
assume most languages already have a well established translation for
it. In French, it's "contrôleur" (fun fact: the most common meaning
for "contrôleur", outside of the IT field, is "bus/train conductor").

Anyway, I guess my point here is that picking the new terminology
should be done with i18n in mind. Maybe double-check with active i18n
contributors for the most spoken languages that they have no issue
with the candidate words, or something like that.

Thomas.

Le 15/06/2020 à 17:03, Angélique Jard a écrit :
My preference goes to "controller", "server" make me think somehow to
the hardware physical machine. "Coordinator" is fine also (in the
link tools.ietf in previous post) but a bit hard to pronounce.

As a non english native speaker (but french), I have some issue with
"valet" and "majordomo" which have fix gender in french and are all
male. I know that it's not like that in english but I think it's
better to tell it now.

As a music player I also like "conductor" (as musical director) this
is how I see my Jenkins instance when I use it, that orchestrate
agents, Jenkinsfile could be the music sheet :)

On Monday, June 15, 2020 at 4:00:27 PM UTC+2 Antonio Muñiz wrote:

In spanish the term "Master" ("Maestro"), when used in isolation (no
"slave" in the context), has no negative connotations. Its main use
is to describe someone very skilled in some matter (often used for
artisans).
I might be suffering of language bias, just wanted to give some "non
english native speaker" perspective to the conversation.

El lun., 15 jun. 2020 a las 7:56, Justin Harringa
() escribió:

Personally I thank the community for having already starting
down this path.

I tend to like leader or controller from
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
but I could also see server working. The difficulty I would see
with primary/active is that folks who run Jenkins would have a
bit of a conflict of terminology there.

Take care all.

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

Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/3411fed5-7e21-454a-b285-f719f07c1b3ao%40googlegroups.com.

-- * Antonio Manuel Muñiz
* amunizmartin.com <http://amunizmartin.com>
* amuniz...@gmail.com

Re: Proposal: Jenkins Code of Conduct update (Contributor Covenant 1.3 -> 1.4)

2020-06-12 Thread Jeff Thompson

I couldn't find any good information on the differences between the
versions so I cloned the repo and diffed between the versions. It works
pretty well, though it's a little difficult to understand the
differences at times.

I find that each new version is an improvement over the previous. The
1.4 is better than the 1.3. I find that the 2.0 version is best.

The 2.0 version changes to using "community" consistently. Formerly it
used both "project" and "community".

This line is added to expected behavior in 2.0 and I really like its
inclusion: "Accepting responsibility and apologizing to those affected
by our mistakes, and learning from the experience."

I like this addition in 2.0: "and will communicate reasons for
moderation decisions when appropriate." As one who has moderated and
been moderated in a variety of forums, communicating reasons is valuable.

This part is very nicely improved in 2.0: "All complaints will be
reviewed and investigated promptly and fairly. All community leaders are
obligated to respect the privacy and security of the reporter of any
incident." This can be extremely important when an incident occurs.

Version 2.0 adds enforcement guidelines, which are important to spell
out if there are ever any misbehaviors. Over the past few years, I've
read many cases of communities, virtual and physical, who have
encountered misbehaving individuals. Having a code of conduct has turned
out to be very valuable for them. Having some part of it include
enforcement gives the leaders and members something to refer to.

I believe the 2.0 version contains the best and latest understandings on
these issues and that we would be best to adopt it.

Jeff

On 6/12/20 3:31 PM, Tracy Miranda wrote:

+1 for proposal (1.4 version)

Tracy

On Fri, Jun 12, 2020 at 5:06 PM Oleg Nenashev <mailto:o.v.nenas...@gmail.com>> wrote:

Dear all,

As a follow-up to the previous Governance meeting, I would like to
propose updating the Jenkins Code of Conduct
<https://www.jenkins.io/project/conduct> (CoC). Currently it is
based on Contributor Covenant 1.3
<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/>
which was officially adopted on Jan 06, 2016. Contributor Covenant
is widely used in open-source projects, and this was the most
recent version at that time. Now there are versions 1.4
<https://www.contributor-covenant.org/version/1/4/code-of-conduct/>
and 2.0
<https://www.contributor-covenant.org/version/2/0/code_of_conduct/>
of Contributor Covenant.
*
*
*Why update? * New versions of Contributor Covenant extend our
version significantly, e.g. pledge and standards,
unacceptable behavior, representing the project and social media
matters, etc. These changes are pretty important IMHO. Also, we
have recently started a process of aligning the Jenkins project
with graduated project criteria defined by the Continuous Delivery
Foundation (see the proposal from Tracy Miranda here
<https://groups.google.com/forum/#!topic/jenkinsci-dev/I3sUP2SB2JI>).
One of the checklist items is adopting the CDF's Code of Conduct
<https://github.com/cdfoundation/toc/blob/master/CODE_OF_CONDUCT.md>
which is based on Contributor Covenant 1.4.

*Background.* At the last Governance Meeting on Jun 03 we had a
sync-up with Dan Lorenc who is the current CDF Technical Oversight
Committee chair. Links are here: recording
<https://youtu.be/R80Rv6G-Oww?t=1728>, meeting notes

<https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#bookmark=id.66p0d0acy2w2>.
Some clarification we have got:

* CDF does not require us to adopt the CDF Code of Conduct as
long as the Jenkins project has one and as long as they are
aligned. We interpret it as using a similar or compatible
version of Contributor Covenant.
* CDF is fine with a 2-stage escalation process. We can keep the
Jenkins Governance Board as a first stage as it is currently
documented
<https://www.jenkins.io/project/conduct/#reporting>. CDF can
act as a second level of escalation and as an entity for
mitigating cross-project Code of Conduct escalations should it
happen
* Right now there is no confirmed plan to update CDF's Code of
Conduct to version 2.0

There is also a consensus that we would like to update the code of
conduct, especially taking the terminology update discussions
<https://groups.google.com/forum/#!topic/jenkinsci-dev/CLR55wMZwZ8>
which are a sensitive topic to many Jenkins contributors. We have
3 options:

* Update to Contributor Covenant 1.4
<https://www.contributor-covenant.org/version/1/4/code-of-conduct/>
* Update to

Re: Terminology Updates

2020-06-12 Thread Jeff

My vote:

   - Master -> Controller (Host and Server are too broad, and Control Plane
   is to verbose)
   - Whitelist/Blacklist -> Allowlist/Blocklist


On Thu, Jun 11, 2020 at 8:34 PM Slide  wrote:

> Hi Everyone,
>
>
>
> Back in the Jenkins 2.0 days, it was decided (rightfully so) to deprecate
> the term "slave" as it was used in the Jenkins project. There has been some
> significant progress made on this effort by many contributors with some
> remaining effort needing to be done (see the JENKINS-42816
>  EPIC). The agent
> terminology cleanup is recognized as a major initiative in the project, and
> it is listed on the Jenkins Public Roadmap Draft
> . We have some additional terminology
> that we would like to look at deprecating and replacing within the Jenkins
> project.
>
>
>
> The following terminology are items that we would like to replace with
> possible options. We would like this discussion to be civil, these words
> have powerful negative meanings for many people and we want to make sure,
> as a project, that we are using terms which are not negative. Please reply
> with opinions on the possible replacements that the Advocacy and Outreach
> SIG came up with, or others if you have additional ideas.
>
>
>
>-
>
>Master ->
>-
>
>   Host
>   -
>
>   Server
>   -
>
>   Control Plane
>   -
>
>Whitelist/Blacklist ->
>-
>
>   Allowlist/Denylist
>   -
>
>   Allowlist/Blocklist
>
>
>
> If there are other terms that you have seen in the Jenkins project that
> may need to be deprecated and replaced, please contact the Jenkins
> Governance Board members (jenkinsci-bo...@googlegroups.com) with your
> concerns.
>
>
>
> Regards,
>
>
>
> Alex Earl
>
> Jenkins Governance Board Member
>
>
> --
> Website: http://earl-of-code.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/CAPiUgVe14X%2B8u8Vy7EGW30GW-i96rxPSMZm7-qMdzM6VcPtcSg%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/CADVhPTrcaWUR7EFU%3DRQge0y3UhVF%3DEE96W8X-xrRHQ_btKZNeA%40mail.gmail.com.

Re: Terminology Updates

2020-06-12 Thread Jeff Thompson

My favorite is "Jenkins server" or something like that. There are
already existing usages and it's reasonably explanatory. Something with
"manager" could also work, but I don't find the term as clean and clear.

Outside of bias issues, one of the problems with whitelist and blacklist
is that the terms don't really say what they do. Sometimes the
interpretation depends on which way you're looking at it. Somewhat
similar to whether a class hierarchy goes up or down.

"AllowList" and "DenyList" are good matching pairs that convey more
semantics about what they do.

In other discussions we have noted that not all usages of
whitelist/blacklist fall into the same behavioral meaning. Sometimes we
will need to use different terminology to better convey the meaning.

Jeff

On 6/12/20 3:20 AM, Oleg Nenashev wrote:
I am +1 for changing the terminology, and I encourage Jenkins
contributors to participate in this effort. It is not something we
could change in a minute, but we could do a gradual cleanup and
improve the overall documentation while doing so.

I am -1 w.r.t "host" due to the following reasons:

* Host term is very generic, it has thousands of usages in Jenkins
https://github.com/search?q=org%3Ajenkinsci+host=Code.
Choosing this term will require a careful cleanup to avoid
confusion in user documentation and the codebase
* "agent host" is often used to describe target hosts for outbound
agents

My suggestion would be to consider a *"Jenkins server"* term. You can
see that such a term is already used in our codebase
<https://github.com/search?q=org%3Ajenkinsci+%22Jenkins+server%22=Code>,
website
<https://github.com/jenkins-infra/jenkins.io/search?q=%22jenkins+server%22_q=%22jenkins+server%22>and
on 3rd party resources
<https://www.google.com/search?q=%22Jenkins+server%22=1C1CHBF_enCH837CH837=%22Jenkins+server%22=chrome..69i57j0l7.2969j0j4=chrome=UTF-8>.

Best regards,
Oleg

On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:

It is a suggestion for consideration if you would like.

On Jun 11, 2020, at 9:35 PM, Richard Bywater > wrote:

Good point. I actually wonder if Manager is a reasonable replacement?

On Fri, 12 Jun 2020 at 16:04, Marky Jackson > wrote:

The concern with controller may be a conflict with Kubernetes
on Jenkins given the same name. This was originally my
suggestion but than I remembered I was also part of renaming
in that community.

> On Jun 11, 2020, at 9:02 PM, Richard Bywater
> wrote:
>

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

Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkin...@googlegroups.com .
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%40mail.gmail.com

<https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%40mail.gmail.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-dev/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.

Re: GitHub issues option in HOSTING

2020-06-11 Thread Jeff Thompson

On 6/11/20 8:32 AM, Slide wrote:
The big problem with GitHub issues is when a bug involves multiple
components, or is filed against the wrong component. If you filed an
issue in the wrong component, what would you expect the maintainers of
that component to do? I don't think it should be on them to find the
right component, so the issue just gets closer and possibly not seen
by the correct people? I definitely prefer GitHub issues, but we need
to address some issues like I describe above.

These are the big issues with moving away from a system-wide tracker to
individual trackers. Jenkins is a system of interacting components and
issues may involve multiple.

As Remoting maintainer I see this frequently. Someone may submit an
issue against Remoting, but often it has to do with a plugin and just
shows up in Remoting. Eventually Remoting is removed from the components
list and the correct one is assigned. Then the maintainer of that one
has notification. Sometimes it helps define the problem. Someone submits
the issue against Remoting and a plugin that might show up in the stack
trace or messages. I look at it and have no idea, but the maintainer of
the other component quickly identifies it.

Sometimes something is submitted against core but we decide it needs to
be fixed somewhere else. Or vice versa.

And then there are security issues. We manage security issues as a
Jenkins system.

If we switch to tracking issues solely by individual component we're
going to lose track of a lot of things. Well, a lot more than we already do.

Jeff

--
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/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.com.

Re: Proposal: Release Jenkins weekly on Tuesday

2020-05-18 Thread Jeff Thompson

+1 on moving to Tuesday. A nice, easy solution, where nobody has
expressed any downsides.

-1 to adding further complexity to the merge process and extending
issues over the weekend. This is too prone to unintentional mistakes.

Jeff

On 5/18/20 2:02 PM, Mark Waite wrote:

On Mon, May 18, 2020 at 1:18 PM Daniel Beck <mailto:m...@beckweb.net>> wrote:

Easy fix: Whoever wants to merge something on a weekend is
responsible for updating the changelog.

If this isn't done, and you've merged fixes a few times, you lose
commit access.

That seems like it will dissuade maintainers from merging on weekends.

The changelog won't be available for most pull request authors to
submit a proposal with their pull requests because it doesn't become
available until Friday. If a maintainer starts the 24 merge clock on
Friday, then when the clock is finished on Saturday, the maintainers
performing a weekend merge would need to update the pull request they
are merging with the changelog entry.

Mark Waite

> On 18. May 2020, at 20:55, Mark Waite mailto:mark.earl.wa...@gmail.com>> wrote:
>
> I worry that creating the changelog on Friday with release on
> Monday seems like it would either preclude merge on Saturday and
on Sunday
> (for those who wish to do so)

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

Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/9E86865E-831C-4B5F-A4A2-77E6AB9882EB%40beckweb.net.

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGoZaKxZWCdwi0e%3DwPpAA25v_AyD35Wvc5xaFcsRc7cAg%40mail.gmail.com
<https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGoZaKxZWCdwi0e%3DwPpAA25v_AyD35Wvc5xaFcsRc7cAg%40mail.gmail.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/16619b69-0889-3c98-3bea-e54693579876%40cloudbees.com.

Re: plugin parent 4.0

2020-03-26 Thread Jeff Thompson

I don't remember if I've pushed any commits that use the beta parent,
but I've tried it out on a variety of different plugins I've
investigated. I've found it to work better than any of the other earlier
versions and can't think of any issues I've encountered.

Jeff

On 3/26/20 3:20 AM, Tim Jacomb wrote:

I've been using it on a few plugins, no issues

On Thu, 26 Mar 2020 at 09:11, James Nord <mailto:jamestn...@gmail.com>> wrote:

Hi Oleg et al.

is it time to move the plugin parent out of beta?

have not seen any negative feedback (or positive door that matter)
but I've been using it for numerous proprietary plugins with no issue.

/James

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

https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%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
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com
<https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com.

Re: Jenkins Release Automation project: Jenkins Code Signing Certificate

2020-03-25 Thread Jeff Thompson

This is great news!

On 3/25/20 2:09 PM, Olblak wrote:

Hello,

I am happy to share that I received a code signing certificate for the
Jenkins project, so the next step is to update the release environment
with the right code signing certificate and the right gpg key, verify
that they are in a safe location (both on Azure Key vault) and then
finalize the publishing part.

Quick reminder on the current state of this project.

I deployed a specific Jenkins instance in the vpn, it's called
release.ci.jenkins.io . This instance
is configured with two jobs one to trigger release and a second one to
trigger packaging for a specific release for debian,redhat,suse, msi

release.ci.jenkins.io configuration is defined on jenkins-infra/charts
.

I created a new repository named "github.com/jenkins-infra/release"
, where that repository
contains scripts, Jenkinsfiles and pod template definition used by
release.ci.jenkins.io

Finally, I reused and adapted scripts from jenkinsci/packaging, with
the last PR located here,
I wish I had the
time to refactor more those scripts to reduce the dependency on
pkg.jenkins.io but I'll probably have to take some shortcut.

Today people that I consider who should be able to trigger a job from
release.ci.jenkins.io are
olblak, danielbeck, olivergondza, oleg_nenashev, anybody else will
have read-only access from the vpn.

Feel free to ask if you have any questions, or just suggestions.

Cheers
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/0e4fac96-0039-487d-a267-f6e7df04cdc9%40www.fastmail.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/7f7b0251-f868-5789-cb2a-3a7993246fd4%40cloudbees.com.

Re: findsecbugs in spotbugs

2020-03-25 Thread Jeff Thompson


On 3/25/20 1:47 PM, James Nord wrote:

I would rather this did not get merged until after the 4.0 release of pom and 
have left further comment in the pr about the lack of reasonable opt out.

James, you're talking about the plugin parent pom, right? The current PR 
is for the Jenkins pom, which is currently at 1.55-SNAPSHOT.


Any idea when we'll move forward to the 4.0 release of the plugin pom?

Jeff

--
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/1fa9591e-1889-b4f6-9f14-6a71dd3e211e%40cloudbees.com.

Re: findsecbugs in spotbugs

2020-03-25 Thread Jeff Thompson

I'm circling back to this discussion here on the dev list. I've gotten
findsecbugs integrated into several Jenkins projects, including Jenkins
itself. I pushed draft PRs demonstrating what it will look like in a
handful of plugins.

I put together information on my observation and recommendations for
developers when they start working with findsecbugs. My blog post is at
https://jenkins.io/blog/2020/03/02/findsecbugs/ and my Jenkins Online
Meetup recording is available at https://youtu.be/fotttu20Mf4 .

Now we're ready to start pushing findsecbugs integration more widely,
particularly into parent poms. StefanSpieker has had a PR for adding it
into the Jenkins parent pom since November:
https://github.com/jenkinsci/pom/pull/61 . It's time to get that moving
forward.

Jeff

On 12/19/19 9:22 AM, Jeff Thompson wrote:

Yes, my goal is to also enable findsecbugs in the plugin parent pom. I
think it's well worth it, just as regular spotbugs provides valuable
findings in a number of cases.

I've currently got PRs awaiting review and approval for jenkins and
remoting. I've got one approval for remoting so I'll proceed to merge
that in before long.

I've also prepared branches for about half a dozen plugins where I've
added it into their local configuration. I have planned on pushing
those soon.

My idea is to prove it out with a selected set of projects and then
work to roll it out more widely. I'm not sure how we want to proceed
with adding it into the plugin parent pom. I'd like to just make it a
standard part, but I think we might need to make it opt-in, such as
with a profile, at least for an introductory period.

Thanks for the response,

Jeff

On 12/19/19 6:41 AM, Ullrich Hafner wrote:
If it helps to prevent some errors I think it would make sense to
enable it for plugins as well (in the parent pom). Can the execution
of this additional plugin be removed in a specific plugin pom
afterwards? I’m not sure how maven handles it.

I enabled the checker in my plugins and needed to disable it for
tests as there where too many false positives have been reported:

Additionally, I deactivated the following rules that seem to produce
too many false positives:

PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>

Maybe it makes sense to gather feedback from some other plugins as
well before changing the parent pom.

--
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/7e79e121-0962-da3a-8071-c37a0a05080a%40cloudbees.com.

Re: XStream almost silently catches NPE

2020-03-04 Thread Jeff Thompson

When I have dug into the Robust*Converters before I've found some
similar problems. The idea behind these converters is interesting, but
there are some weird quirks in the implementation. There are times where
it would be nice to influence or get more information about about the
results, but no hooks for it.

The implementation really needs a re-work but it's a big, very
complicated challenge.

Jeff Thompson

On 3/3/20 3:58 PM, Ullrich Hafner wrote:
Is there a way to prevent Jenkins to silently catch RuntimeExceptions
during unmarshalling? From my perspective our Robost*Converters are
too robust.

Background: After upgrading my warnings plugin to the latest release
Jenkins XStream failed to unmarshall an instance of my old plugin
data. (Actually XStream did not fail, I rather got a corrupt instance
as return value). Rather then failing fast and throwing an exception
(well at list I would expect that the NPE with stack trace is printed
somewhere in the log) the unmarshalling code the prints a rather
unsuspicious and unclear logging message (the important context of the
file, class and attribute is missing):

WARNINGh.util.RobustReflectionConverter#doUnmarshal:
Cannotconverttypeedu.hm.hafner.util.TreeStringtotypejava.lang.String

It took me quite a while to locate the actual problem.
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/D1B81899-E976-4747-9D98-42FB3AF08078%40gmail.com
<https://groups.google.com/d/msgid/jenkinsci-dev/D1B81899-E976-4747-9D98-42FB3AF08078%40gmail.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/b8817b94-65fb-dfb7-b57e-f6721dac2eeb%40cloudbees.com.

Re: Jenkins architecture

2020-02-28 Thread Jeff Pearce

That’s correct. At its heart Jenkins is just a task runner. Most people use if 
for CICD, so they would have a SCM hook, but it’s not required

From:  on behalf of Jeroen Haaksema 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Friday, February 28, 2020 at 10:53 AM
To: Jenkins Developers 
Subject: Re: Jenkins architecture

Notice: This email is from an external sender.

Thank you for your answer! I was assuming that source control management was a 
part of Jenkins since both the Hudson and Jenkins module feature it, but if I 
understand correctly this is actually a plugin? I will look into the @Extension 
decorator as Mike mentioned and see if I can find it in action.

Op vrijdag 28 februari 2020 11:30:07 UTC+1 schreef Esther Alvarez:

I don't have a deep knowledge in jenkins, so apologies in advance if I say 
something which is not accurate.

> What is the reason that plugins can be written in Kotlin?
I would say that plugins can be written in any language executable by the JVM 
that can interoperate with java classes, like scala and groovy. It may be 
challenging having some maven plugins work with them, but should be possible.

> Would you say that an external interface used by Jenkins is a link to a 
> source control management system (eg. GitHub) ?

Another main principle in Jenkins architecture is the plugins system. Most of 
the features are implemented by plugins, including those that interact with 
external interfaces. For example, the interaction with maven, node, git or 
mercurial is implemented by plugins.
So, answering your question, the source control management system is an 
external interface, depending on which plugins you install. Also, integration 
with LDAP for authentication, sonar for code analysis, nexus and docker 
registries, kubernetes, SSH to un agents, all of them can be external 
interfaces too. This list can be as long as you can imagine, as anybody can 
create a plugin to connect with whatever they want.

On Thu, Feb 27, 2020 at 9:21 PM Jeroen Haaksema 
> wrote:
Hey Gwen,

Thank you for taking the time to write an answer! I'm not really sure how I got 
it in my head that Oracle built Jenkins but that interview is really helpfull.

Op donderdag 27 februari 2020 17:27:45 UTC+1 schreef Gwen:
Hey - I sit on this mailing list and am looking at some newbie-issues; I'm 
definitely not a core developer or anything, but I wanted to tackle the Jenkins 
in Java question.

On Thu, Feb 27, 2020 at 8:07 AM Jeroen Haaksema  wrote:

Hello,

First of, I’m really sorry if this is not the right place to ask this, if not 
please let me know who I could direct this to!I am a CS student who is doing a 
course on architecture and I have chosen Jenkins. Part of the course is 
communicating with the architect. There doesn’t seem to be just a single 
architect within Jenkins and your group seems to me the closest I will get to 
an actual architect. The assignment I’m working on is a reconstruction of the 
architecture from an open source software project and one of the things we are 
looking at is Architecturally Significant Requirements(ASR). Which comes down 
to requirements set in stone with no wiggle room. I would really appreciate it 
if someone would be able to either confirm or deny if the ASR’s I have defined 
are correct.

  *   Would you say that part of the reason that Jenkins was developed in Java 
is due to that this means that the codebase can be used for Linux, Mac Os X and 
Windows? (this obviously skips over that Oracle, the owner of Java was part of 
the inception of Jenkins)

If you do a quick wikipedia search for the Jenkins project, you'll see that it 
didn't originate in Oracle at all. Kohsuke Kawagachi, the original author, 
worked at Sun Microsystems, the original developer of the JVM :  )

Checking the references on the wikipedia page got me to this interview with 
Kohsuke after he received an O'Reilly Open Source Achievement Award 
https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/kohsuke-kawaguchi-geek-of-the-week/.
 I picked that because I figure an interview about an award normally covers 
"How did this project start?" kinds of questions.

A quote from that article reads:

There were several motivations for writing it. One was that despite I was 
working in a group of Sun Microsystems that designed and developed JavaEE (the 
framework layer for server applications written in Java), I’ve never written 
apps on top of it. And that’s not a good thing. I’d been meaning to write one 
so effectively that idea became Jenkins; I thought this could be a good vehicle 
to make myself learn JavaEE.

So, he chose Java because he wanted to motivate himself to learn JavaEE for 
work.

  *
  *   Would you say that using HTTP to manage slave nodes is to make it 
possible for Jenkins to have nodes on different operating systems working 
together?

Furthermore I have some other questions:

  *   Would you say that one of the main features of Jenkins is the

Re: [GSOC 2020 PROJECT IDEA] Autobuild without Jenkinsfile

2020-02-26 Thread Jeff

Thanks for the pointers - I suspected this wasn't a novel idea. I'll look
at those plugins.

Jeff

On Wed, Feb 26, 2020 at 7:37 AM Tomas Bjerre 
wrote:

> I prefer setting up a webhook from the Git service to Jenkins. And in
> Jenkins I recognize type. Type of repo in combination with the webhook
> content tells me what should be done. Zero code duplication. I wrote about
> it here:
>
>https://jenkins.io/blog/2019/12/14/generic-webhook-trigger-plugin/
>
>
> Den onsdag 26 februari 2020 kl. 15:00:48 UTC+1 skrev Jeff Pearce:
>>
>> This is an idea I've been thinking about for awhile, and I wanted to run
>> it by the list to see if it's feasible. It's also possible someone else has
>> looked into it in the past.
>>
>> I've noticed that a lot of the projects I work with have a single
>> Jenkinsfile, which they copy from repo to repo. I've been reducing the
>> copy/paste with shared libraries, but I'm wondering if we could make it
>> even easier.
>>
>> I think it would useful if there was a plugin that could connect into the
>> github branch plugin's scanning for Jenkinsfiles, and autodetect the type
>> of project if there's no Jenkinsfile. From there it could reference some
>> sort of template to build/test (or whatever) and generate a pipeline. This
>> would allow branches to have some sort of build without need for any
>> configuration in the branch.
>>
>> Thoughts? I'm happy to write it up if it seems feasible.
>>
>> Best
>> Jeff
>>
> --
> 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/021d80ba-aa46-4b9c-b2f2-f0c8cc8a75df%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/021d80ba-aa46-4b9c-b2f2-f0c8cc8a75df%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

[GSOC 2020 PROJECT IDEA] Autobuild without Jenkinsfile

2020-02-26 Thread Jeff Pearce

This is an idea I've been thinking about for awhile, and I wanted to run it 
by the list to see if it's feasible. It's also possible someone else has 
looked into it in the past.

I've noticed that a lot of the projects I work with have a single 
Jenkinsfile, which they copy from repo to repo. I've been reducing the 
copy/paste with shared libraries, but I'm wondering if we could make it 
even easier.

I think it would useful if there was a plugin that could connect into the 
github branch plugin's scanning for Jenkinsfiles, and autodetect the type 
of project if there's no Jenkinsfile. From there it could reference some 
sort of template to build/test (or whatever) and generate a pipeline. This 
would allow branches to have some sort of build without need for any 
configuration in the branch. 

Thoughts? I'm happy to write it up if it seems feasible.

Best
Jeff

-- 
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/81c2d50a-d955-4661-abf0-f9b750175dad%40googlegroups.com.

Re: PROPOSAL: Remove network discovery services

2020-01-30 Thread Jeff Thompson


On 1/30/20 1:43 PM, Jesse Glick wrote:

On Thu, Jan 30, 2020 at 1:41 PM Jeff Thompson  wrote:

I'd be willing to help get things going with that, but not to maintain it. If 
nobody is interested enough for that, we should kill it off.

Fine with me. My perspective was that it sounded like little
additional effort to dump the extracted code into a plugin repository,
publish a 1.0 release, and then forget about it—immediately mark as up
for adoption. (And do not list in the split plugin metadata for core,
so it has to be opted into.) Of course simply deleting it without
replacement does not prevent someone in the future from looking up the
code deleted in that commit and creating a plugin out of it.


Yeah, if there's some interest I'm willing to help with that. Otherwise, 
I figure it's in the git history and can always be resurrected when 
there's someone motivated enough to keep it going.


Jeff

--
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/cebd21d8-1261-77ef-1fe9-a08a87841e9f%40cloudbees.com.

Re: PROPOSAL: Remove network discovery services

2020-01-30 Thread Jeff Thompson


On 1/30/20 1:33 PM, Baptiste Mathus wrote:
Le jeu. 30 janv. 2020 à 20:10, Tim Jacomb <mailto:timjaco...@gmail.com>> a écrit :


+1 on removing it, is there actually going to be anyone using it
who is updating their Jenkins version? I.e is a plugin needed?


Would it be worth and possible writing a jep-214 Telemetry impl to 
catch stats about this use? (Though it'd take a big time to be used, 
once people upgrade to it, but at least we'd have some trend).


It's probably possible to write some Telemetry code to catch usage 
stats. I'm not sure how useful the data would be. It could tell us who 
has enabled the features. And probably servers where the service is 
probed. It would be harder to tell if they're providing useful value.


I question whether it's worthwhile. If we get some positive response for 
the capability that would better support a need for the Telemetry. Maybe.


Jeff

--
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/01f792a8-fd12-69ad-4b26-e83ff4a484e4%40cloudbees.com.

Re: PROPOSAL: Remove network discovery services

2020-01-30 Thread Jeff Thompson


On 1/30/20 11:25 AM, Jesse Glick wrote:

On Thu, Jan 30, 2020 at 11:47 AM Jeff Thompson  wrote:

the capabilities could be pulled out of core into a plugin

That was the longstanding proposal in JENKINS-33596.


I think it's time to act on it.

The key to implementing it in a plugin is to have someone who relies on 
it maintain it. If swarm uses it maybe someone involved with that could 
take it on. I'd be willing to help get things going with that, but not 
to maintain it. If nobody is interested enough for that, we should kill 
it off.


Jeff

--
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/e8f4603d-a953-10f8-0eb0-8cada6eaae36%40cloudbees.com.

PROPOSAL: Remove network discovery services

2020-01-30 Thread Jeff Thompson

Hi,

Dating back many years, Jenkins has supported two network discovery
services (UDP multicast/broadcast and DNS multicast). When this was
first implemented this may have been a reasonable way to provide useful
lookup services. With modern Jenkins capabilities, networks, and
security considerations, this is no longer a good mechanism. There are
now other ways to better accomplish pretty much everything this does.

With Jenkins Security Advisory 2020-01-29 (
https://jenkins.io/security/advisory/2020-01-29/ ) these services were
disabled by default because
of<https://issues.jenkins-ci.org/browse/SECURITY-1641> SECURITY-1641 /
CVE-2020-2100.

The tests for these services have long been problematic because of
various system issues. They have never passed for me on my development
machine and others have reported the same. The issues are exacerbated
with Java 11.

We propose to remove these network discovery services. See
https://issues.jenkins-ci.org/browse/JENKINS-60913 and
https://github.com/jenkinsci/jenkins/pull/4460 .

Please respond with any agreement or if you have any important
implementations that require these capabilities. Perhaps if this is
still needed, the capabilities could be pulled out of core into a
plugin, maintained by someone that uses it.

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/781cfc3a-3cf6-bfd1-c9ec-759d0db42ecb%40cloudbees.com.

Re: [PROPOSAL] Adding new milestones to Jenkins

2020-01-30 Thread Jeff Thompson

This will be a great improvement! Last time I had to work with
InitMilestones I was very frustrated that there weren't enough
meaningful milestones, resulting in potential collisions in the init
process. I'm glad to see someone is tackling the problem and improving
things.

Jeff

On 1/30/20 7:49 AM, Francisco Javier Fernandez wrote:

Hi all,

So far, jobs are loaded at some moment between "EXTENSIONS_AUGMENTED"
and "JOBS_LOADED" milestones on Jenkins startup. JCasC is more and
more used everyday and it applies changes in the instance
configuration between the same milestones, so there might be a
collision between them. To fix this situation and prevent the
instances/plugins from being unable to start, I've opened
https://github.com/jenkinsci/jenkins/pull/4450 as a proposal to add
some new milestone to Jenkins. Please, anyone interested in this to
review the PR. Any suggestion, missing use case, concern ... is more
than welcome and appreciated.

Cheers
--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/4544036f-bf58-4ecb-bd29-0558e11520d5%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-dev/4544036f-bf58-4ecb-bd29-0558e11520d5%40googlegroups.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/3fed5750-a1fc-9004-842d-149b75edf2d0%40cloudbees.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

2020-01-30 Thread Jeff

I just saw this, but I would be interested in working with you on this even
if it doesn't make it into GSoC.

Rick, do you need help getting a proposal started?

Best
Jeff

On Fri, Jan 17, 2020 at 3:31 AM Chris Kilding <
chris+jenk...@chriskilding.com> wrote:

> The notion of a Jenkins distribution(s) sounds relevant to us.
>
> In my company we have a central team which is trying to put together a
> standardised Jenkins template to deploy on AWS, which all product teams can
> then adopt instead of rolling their own. (This is part of a phased
> deduplication strategy and isn't the end game: I could perhaps see a
> multi-tenant central Jenkins instance for some tasks in the future.)
>
> The work that the central team does in assembling a set of plugin
> versions, configuration etc, certifying that they all work together, and
> then repeating this certification when things change, starts to look like
> the work that the community around a Linux distro does. But unlike the
> Linux community, Jenkins tooling teams can't share the workload with teams
> in other places. Each organisation must duplicate the effort of maintaining
> their own in-house Jenkins distro, even if a lot of those distros look very
> similar to each other. The exception to the rule is Jenkins X for
> Kubernetes, but if a company is not in a position to move their CI/CD to
> Kubernetes then they're out of luck.
>
> For example, I suspect that both my company and Jeff's team at GoDaddy
> have developed variations on a "Jenkins for AWS" distribution, but we've
> reinvented them - and continue to maintain them - independently. If we were
> instead to share the work of building a standardised Jenkins for AWS
> distro, it might look a bit like this:
>
> - Start with Jenkins vanilla
> - Build in a set of core AWS-specific opinions (build agents must be
> spawned on [AWS compute service], logs must be forwarded to [AWS logging
> service], credentials must be stored in [AWS secrets service] etc). These
> would be the defining characteristics of the distro, something like how
> Ubuntu uses Gnome, SystemD etc. All plugins and config required to make
> this work would be pre-packed in the distro.
> - Still allow users to configure this as they please, or to install extra
> plugins etc. This is how they'll customise it to their environments. The
> analogy with Ubuntu is that you would expect to install say language
> runtimes or apps from the APT repos as those are extras, but you wouldn't
> expect to replace the bundled desktop environment (you'd certainly have an
> uphill struggle to do it cleanly).
>
> Anything that would help Jenkins users to reduce duplicated maintenance
> effort sounds good in my book. Whether that's a customisation service, or
> something more pre-packed equivalent to a Linux distro, or something else,
> I don't have a clear picture of yet.
>
> I suppose the cost/benefit comes down to:
>
> - How much we can share
> - How many teams that use Jenkins are interested in participating
> - How difficult it is to build the common packaging tooling (can we do it
> in 1 GSoC or is it a bigger thing?)
> - Time horizons (do the potential participants foresee sticking with their
> Jenkins deployment stack, or something similar to it, for at least N years
> such that it's worth putting the effort in)
>
> Chris
>
> On Thu, 9 Jan 2020, at 12:36 PM, Daniel Beck wrote:
>
>
> On Wed, Jan 8, 2020 at 3:49 PM Rick  wrote:
>
> For many users, they download Jenkins first, then select some plugins and
> config them. It might take a lot of time, like hours. But if we can get a
> perfect Jenkins distribution which contains all we need, it can save that
> time for us. Yes, I propose an out of the box solution.
>
>
> Jesse brings up some potential issues with something like this in
> https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ --
> this could require some work on a fairly badly documented and tested part
> of Jenkins core to make work well.
>
>
> --
> 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/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1tyE_bKp5A-X5xe%2Bjgmd-oKO7nfpg2GMdA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsub

ANN: Removal of old, unsupported agent protocols

2020-01-10 Thread Jeff Thompson

Hi,

For historical reasons, Jenkins has still shipped with old, deprecated
protocols, JNLP1-connect, JNLP2-connect, and JNLP3-connect. These are
also known currently as Inbound TCP Agent Protocol/1, Inbound TCP Agent
Protocol/2, and Inbound TCP Agent Protocol/3. These all have fundamental
issues and known bugs. They were all superseded by the JNLP4-connect
protocol released in Jenkins 2.27 over three years ago (October 2016).
They have all been deprecated and unsupported since Jenkins 2.75 over
two years ago. Since then there have been UI messages and an
administrative monitor strongly discouraging their use. (See more
information about the protocols at
https://github.com/jenkinsci/remoting/blob/master/docs/protocols.md
<https://github.com/jenkinsci/remoting/blob/master/docs/protocols.md> )

We have been discussing plans to remove these old protocols in various
places, including the Users list and a couple of PRs. This removal is in
process with major steps occurring now.

* These protocols were removed from Remoting 3.40, released two weeks ago.
* On the Jenkins master side, the changes were integrated towards
Jenkins 2.214 weekly. ETA is next Monday. The next LTS baseline is
expected to have the protocols removed as well.
* Jenkins docker agent image updates are in process. ETA is next Monday.
* Swarm Plugin Client is updated
<https://github.com/jenkinsci/swarm-plugin/pull/167>, but we need a
release.

Jeff

--
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/53af53f2-ce0f-e0cf-8c4b-469432e247a5%40cloudbees.com.

Re: Is there ant API/way to make a plugin that runs some action periodically?

2020-01-08 Thread Jeff

You could also write a plugin that implements the RunListener extension,
and gather the stats as the jobs complete. In some sense, that might be
better, because you don't have to worry about builds being discarded before
it runs.  Here's an example of that
https://github.com/jenkinsci/github-autostatus-plugin/blob/master/src/main/java/org/jenkinsci/plugins/githubautostatus/BuildStatusJobListener.java#L62


On Wed, Jan 8, 2020 at 7:57 AM Jeff Pearce  wrote:

> I think the Thin Backup plugin does that; you might look at it for ideas.
>
>
>
> *From: * on behalf of Daniel Anechitoaie <
> daniels0...@gmail.com>
> *Reply-To: *"jenkinsci-dev@googlegroups.com" <
> jenkinsci-dev@googlegroups.com>
> *Date: *Wednesday, January 8, 2020 at 7:38 AM
> *To: *Jenkins Developers 
> *Subject: *Is there ant API/way to make a plugin that runs some action
> periodically?
>
>
>
> Notice: This email is from an external sender.
>
>
>
> I need to gather some statistics (nr of jobs, nr of builds, their status,
> etc) for our internal Jenkins and post that report to some HTTPS endpoint.
>
> Is there a way that I can make a plugin or something, that is not an
> actual job, so that doesn't require an actual agent/worker that will do
> this?
>
> Some Jenkins Java API that would allow me to run some code in the
> background every day or so. Kind of like how Jenkins checks for plugin
> updates, new versions, etc.
>
>
>
> My other option would be to use the REST API and pull this data out of
> Jekins if possible but I think pushing it from Jenkins might be better in
> my case.
>
>
>
> Is there any way this can be done? And APIs that Jenkins has for this? Any
> particular Java class that needs to be extended.
>
>
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/7c041c4d-2f5e-4f1d-8803-782e40bbdd80%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/7c041c4d-2f5e-4f1d-8803-782e40bbdd80%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/783F8984-1D7A-4F7E-96B9-6C6DF959C1BD%40godaddy.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/783F8984-1D7A-4F7E-96B9-6C6DF959C1BD%40godaddy.com?utm_medium=email_source=footer>
> .
>

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

Re: Is there ant API/way to make a plugin that runs some action periodically?

2020-01-08 Thread Jeff Pearce

I think the Thin Backup plugin does that; you might look at it for ideas.

From:  on behalf of Daniel Anechitoaie 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Wednesday, January 8, 2020 at 7:38 AM
To: Jenkins Developers 
Subject: Is there ant API/way to make a plugin that runs some action 
periodically?

Notice: This email is from an external sender.

I need to gather some statistics (nr of jobs, nr of builds, their status, etc) 
for our internal Jenkins and post that report to some HTTPS endpoint.
Is there a way that I can make a plugin or something, that is not an actual 
job, so that doesn't require an actual agent/worker that will do this?
Some Jenkins Java API that would allow me to run some code in the background 
every day or so. Kind of like how Jenkins checks for plugin updates, new 
versions, etc.

My other option would be to use the REST API and pull this data out of Jekins 
if possible but I think pushing it from Jenkins might be better in my case.

Is there any way this can be done? And APIs that Jenkins has for this? Any 
particular Java class that needs to be extended.

Thank you.
--
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7c041c4d-2f5e-4f1d-8803-782e40bbdd80%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/783F8984-1D7A-4F7E-96B9-6C6DF959C1BD%40godaddy.com.

Re: Plugin host

2019-12-26 Thread Jeff Pearce

I agree with Ullrich. Please consider including adequate unit tests for any 
plugin hosted on Jenkinsci.

Sent from my iPhone

> On Dec 26, 2019, at 2:03 PM, Ulli Hafner  wrote:
> 
> 
> Notice: This email is from an external sender.
>  
> 
> While we do not enforce plugins to have tests I would encourage you to create 
> at least a few of them. Writing software without tests is not recommended in 
> any domain (especially not for a CI/CD system). Our users will expect a given 
> level of quality for the plugins that are available in the update center.
> 
>>> Am 26.12.2019 um 16:14 schrieb Slide :
>>> 
>> 
>> We do want the InjectedTests to run as part of CI. During the hosting 
>> process this will be checked. These are part of the tests that Tim is 
>> referring to.
>> 
>>> On Thu, Dec 26, 2019, 05:19 Tim Jacomb  wrote:
>>> Not that I’m aware of
>>> If you start from one of the plugin archetypes you should get a test or two 
>>> that can be useful depending on what your plugin does 
>>> https://github.com/jenkinsci/archetypes
>>> 
 On Thu, 26 Dec 2019 at 20:08, selva vignesh  
 wrote:
 Hi Tim,
 Is unit test mandatory for hosting plugin?
 
 On Thu, Dec 26, 2019 at 2:10 PM Tim Jacomb  wrote:
 
> https://jenkins.io/doc/developer/publishing/requesting-hosting/
> 
> 
>> On Thu, 26 Dec 2019 at 16:46, selva vignesh  
>> wrote:
>> Hello Team,
>> Currently, I am looking for a guide to host my plugin in Jenkins side.
>> Kindly assite me.
>> Thanks in advance
>> -- 
>> 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/68666448-18e0-4f91-8ff7-c0fc39b62bd0%40googlegroups.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifQLw3h08dvchXMjSp-Pt2T7DPp5FcB6RP9CwE-JraD8Q%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/CAOVVkp%3Dk_TgPSqGgt9Kj3bm9k5nXMnQNoH_%3DCUQ4L6STE_5sPg%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-3Bif6sL4WGbq9Cix8xC4XOpjnh5HhD86gWFdYj4qrepPnWA%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/CAPiUgVeKditqVVhJZnaHUvpwH68hcexXdYneK-OvJst9XhYPmg%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/27A16616-A9C5-400E-8EE6-02BD695E3631%40gmail.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/9890CB96-C889-495E-AC0D-41E57726C7A8%40gmail.com.

Re: findsecbugs in spotbugs

2019-12-19 Thread Jeff Thompson

Yes, my goal is to also enable findsecbugs in the plugin parent pom. I
think it's well worth it, just as regular spotbugs provides valuable
findings in a number of cases.

I've currently got PRs awaiting review and approval for jenkins and
remoting. I've got one approval for remoting so I'll proceed to merge
that in before long.

I've also prepared branches for about half a dozen plugins where I've
added it into their local configuration. I have planned on pushing those
soon.

My idea is to prove it out with a selected set of projects and then work
to roll it out more widely. I'm not sure how we want to proceed with
adding it into the plugin parent pom. I'd like to just make it a
standard part, but I think we might need to make it opt-in, such as with
a profile, at least for an introductory period.

Thanks for the response,

Jeff

I enabled the checker in my plugins and needed to disable it for tests
as there where too many false positives have been reported:

Additionally, I deactivated the following rules that seem to produce
too many false positives:

PATH_TRAVERSAL_IN, WEAK_FILENAMEUTILS"/>

Maybe it makes sense to gather feedback from some other plugins as
well before changing the parent pom.

--
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/30893ff4-685f-f31a-632a-6b938b91a4b1%40cloudbees.com.

Re: Jenkins Plugin pom (future of)

2019-12-12 Thread Jeff Thompson

On 12/12/19 2:23 PM, James Nord wrote:
For those of you that are not aware the jenkins bom is trying to solve
to problem of not consuming newer versions of libraries that are
shipped in Jenkins core as this can cause unexpected failure at
runtime, and to make keeping the versions used in step with the
Jenkins version targeted in the POM.
I really like the goals you are pursuing here, to produce a parent pom
that is more consistent and reduces problems at build and run time. It's
a hard task to get everything lined up right and it does require
"breaking some eggs".
(skipTests is a surefire flag but we abuse it to also skip spotbugs
which when you know how maven works becomes surprising)
I would really like to break that egg. That overloading is just
confusing and it causes problems when people aren't aware of its
non-standard behavior. If people need they can create local aliases or
whatever to achieve the same result. It shouldn't be in a parent pom
like this.
we have findbugs properties as well (to cope with people that are have
used a findbugs flag in their build and we now use spotbugs.

I'm in favor of breaking this egg, also. Findbugs is dead and has been
for a while. We're past the point of needing to support a migration period.

Jeff

--
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/082a905a-9370-aec9-3065-9a0cad80f3bf%40cloudbees.com.

Re: findsecbugs in spotbugs

2019-12-12 Thread Jeff Thompson

On 12/12/19 7:10 AM, Jesse Glick wrote:

On Wed, Dec 11, 2019 at 2:06 PM Jeff Thompson wrote:

As I was analyzing one findsecbugs finding, I immediately recognized it as
SECURITY-1322 […]
If someone had run findsecbugs a year ago it would have caught that as a real
vulnerability.

You are referring to

https://github.com/jenkinsci/credentials-plugin/commit/40d0b5cc53c265b601ffaa4469310fad390a80fb

I guess? If it managed to catch that, then this alone seems to justify
turning it on. My concern was that the idiosyncratic architecture of
Jenkins would make it hard for a generic security scanner to find
relevant issues.

Yes, that's the one.

Findsecbugs is clearly biased to web applications, which makes it fairly
applicable to Jenkins. Some things it reports on the agent side of
Remoting would be important on a server. Remoting operates on both sides
so it requires consideration as to how or where each piece runs. There
are some findsecbugs rules (at least 1) that just aren't treated as a
concern in Jenkins. As I've been analyzing findings I've thought it
would be cool to have some Jenkins-specific rules for findsecbugs,
spotbugs, or some other tool to catch some of those idiosyncratic
things. But, there's enough value in the rules it does have to catch
common things. We should move forward on these ones because they're
useful and maybe someday we can introduce some Jenkins-specific checks
somewhere.

One thing I do wish for (not limited to security issues): that
SpotBugs could be asked to report a warning (or error?) if you have an
annotation in the code which would _not_ be required in its current
scanner configuration. Sometimes people just drop an annotation onto
some 100-line method asking it to ignore an apparent NPE or
synchronization mismatch or whatever, the code is subsequently
refactored, and then no one ever thinks to go back and verify that the
annotation is still necessary. IDEs and style checkers can flag unused
imports or private methods; this would be in the same mold.

+10

This would be fantastic. Sometimes I remove a suppress annotation and
see if it's still necessary -- often it isn't. Going through these
analyses I found a number of cases where an existing annotation was no
longer necessary. It would be great to have this capability, but I'm not
motivated enough to contribute this to spotbugs.

Jeff

--
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/f1e2acb5-f896-3048-eca1-bdc8cbf968d9%40cloudbees.com.

Re: findsecbugs in spotbugs

2019-12-11 Thread 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

findsecbugs in spotbugs

2019-12-10 Thread Jeff Thompson

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/abf5a687-e4a1-6c44-6c2a-fab071ef84cd%40cloudbees.com.

Re: JEP draft posted: WebSocket Services

2019-11-26 Thread Jeff Thompson

The JEP is nicely done and very explanatory for anyone who wants to 
learn about this new, upcoming capability. I've done a preliminary 
review of the four linked draft implementation PRs. They look good so 
far. Looks like we should be able to get this feature in nicely without 
disrupting anything.


This will be a great connection mechanism to have.

Jeff Thompson

On 11/25/19 10:00 AM, Jesse Glick wrote:

Should have sent a message about this on Friday but Gmail was being
cranky. Anyway:

https://github.com/jenkinsci/jep/pull/250

tl;dr: This lets “inbound” agents (`JNLPLauncher`) make a Remoting
connection to the master via a WebSocket upgrade on the HTTP port
rather than using the TCP port, to simplify Jenkins setup in special
network topologies (including basically any Kubernetes installation).
Currently working at a prototype level.

Comments welcome on either the JEP or the linked draft implementation PRs.



--
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/ad3d25e1-4af9-389f-6326-42727f829f0f%40cloudbees.com.

Re: SIG Status

2019-10-23 Thread Jeff Pearce

+1, Marky you’ve made a huge contribution to the Jenkins community.

From:  on behalf of Mark Waite 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Wednesday, October 23, 2019 at 10:20 AM
To: jenkinsci-dev 
Subject: Re: SIG Status

Notice: This email is from an external sender.


Thanks for all your help with the special interest groups!

On Wed, Oct 23, 2019 at 11:15 AM Marky Jackson 
mailto:marky.r.jack...@gmail.com>> wrote:
For the remainder of this year I will by pulling back from my work with SIG’s 
for the Jenkins project to focus on some other items.
Have a great rest of the year all and happy New Years!

--
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/86A89FF1-2A1B-4952-8909-A7261F852D73%40gmail.com.


--
Thanks!
Mark Waite
--
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFANg8gTHZ4xA03y2xPyQM%3D29ffWp5C75KnnFfkupFuNw%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/A7B07087-3C56-4709-8950-0CB9D093EAAD%40godaddy.com.

Re: Question about reading json for plugin

2019-10-16 Thread Jeff

In the past I've ignored Freestyle jobs in my plugins, but it's hard to say
whether that works for you. I will say that I've had to retroactively add
it when I found some luddites at my company that wanted to use it.

How is the React component being served? Is it possible to add the JSON as
a global object in your HTML?

Jeff

On Tue, Oct 15, 2019 at 11:34 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hey everyone,
>
> I'm making a simple little plugin that takes in some json and spits it out
> again inside of a react component.
>
> My original plan was just to do step(readFile('./report.json')) and take
> in the json as a large blob. I wanted to do this so I didn't have to worry
> about any logic to determine if the file was safe to read. I've now
> realized that won't work with extends Builder implements SimpleBuildStep
> since freestyle would have to know the json ahead of time.
>
> So suggestions please.
>
> 1) Do I drop freestyle support? Are people still making freestyle plugins?
> 2) Copy the checks from readJSON that make sure its a valid file -
> https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/json/ReadJSONStepExecution.java#L66-L80
> 3) Don't have the checks as it seems readFile doesn't have them -
> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/f9f082f4e1069cf69feba3a326d15e01f5ecea21/src/main/java/org/jenkinsci/plugins/workflow/steps/ReadFileStep.java#L111
>
> the problem with 2 and 3 are if any security updates get made, i'll
> probably not see them
> But its also such a stupidly simple problem, I'm probably over thinking it.
>
> Gavin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutnM9dPicBtT%2Bd8gfr8QCd3M5hVsn%2BsR1OuZ9YapcUJ-A%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutnM9dPicBtT%2Bd8gfr8QCd3M5hVsn%2BsR1OuZ9YapcUJ-A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CADVhPTqFfuE337CtEFS4qg5dF-bT0-6EUOP%3DUN7Bkz%2BuJVdA9w%40mail.gmail.com.

Re: Plugin execution is not aborted which I cancelled build strp

2019-10-15 Thread Jeff Pearce

I’m not sure I understand the question, but are you sure you need to do this in 
a plugin? Does it add something beyond running the command from your pipeline?

Sent from my iPhone

On Oct 15, 2019, at 5:39 AM, varun vikas  wrote:


Hi,

I am creating a Jenkins plugin which executes command( bat file or .sh file) on 
slave node using

launcher.launch().cmds(buildCommandLine(script)).envs(envVars).stdout(listener).pwd(ws).start());

I have extended Builder and implements SimpleBuildStep.
But when I tried to abort the plugin , it is not aborted.What could be issue.


Thanks,
Varun


--
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/3b890d9d-016f-4c09-92c2-8e0218bce87e%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/D0988696-EDE0-4945-96E4-67D613C9F22B%40godaddy.com.

Re: auto backward compatibility of plugin

2019-10-13 Thread Jeff

Does readResolve help? I would expect you just want to repopulate an
existing string value on load?

Best
Jeff

On Sun, Oct 13, 2019 at 12:01 AM Nikhil Bhoski 
wrote:

> Thanks Jeff,
> i am planning to add dropdown instead of text box from earlier layout
> which will be auto populated from the global tool configuration page.
> Regards
> Nikhil
>
> On Saturday, 12 October 2019 17:51:54 UTC+5:30, Jeff wrote:
>>
>> Are you adding a new field to your global config? I think you might want
>> the readResolve() method.
>>
>> Here's some hints about maintaining backward compatibility
>> https://wiki.jenkins.io/display/JENKINS/Hint+on+retaining+backward+compatibility
>>
>> Best
>> Jeff
>>
>> On Sat, Oct 12, 2019 at 4:36 AM Nikhil Bhoski 
>> wrote:
>>
>>> Hi Guys ,
>>>
>>> I have plugin with few input parameters. one of the parameter which
>>> accepts installation path of a 3 rd party tool from user. Now in new
>>> version i am planning to add those installation through global tool config
>>> area and then auto populate during build as dropdown selection. I want to
>>> make sure when i make these changes and release it, existing users need not
>>> to reconfigure their jobs. i want my plugin to identify if old config.xml
>>> present . and if it is present then automatically add the path in tools
>>> section and populate the same as default under my build. please guide me if
>>> this auto upgrade is possible. i came across some method like readResolve()
>>> but did not understand fully.
>>>
>>> Nikhil
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/c0d217b2-1d75-46bc-b4b9-d68eec14db05%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/c0d217b2-1d75-46bc-b4b9-d68eec14db05%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/711c7bcc-0220-4532-b19c-040f696b3dac%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/711c7bcc-0220-4532-b19c-040f696b3dac%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CADVhPTp47h-5Z%2BJ9Bu-KQjpCNGNV%2BY94JsWo%2BEXD5pxaQHeRmw%40mail.gmail.com.

Re: auto backward compatibility of plugin

2019-10-12 Thread Jeff

Are you adding a new field to your global config? I think you might want
the readResolve() method.

Here's some hints about maintaining backward compatibility
https://wiki.jenkins.io/display/JENKINS/Hint+on+retaining+backward+compatibility

Best
Jeff

On Sat, Oct 12, 2019 at 4:36 AM Nikhil Bhoski 
wrote:

> Hi Guys ,
>
> I have plugin with few input parameters. one of the parameter which
> accepts installation path of a 3 rd party tool from user. Now in new
> version i am planning to add those installation through global tool config
> area and then auto populate during build as dropdown selection. I want to
> make sure when i make these changes and release it, existing users need not
> to reconfigure their jobs. i want my plugin to identify if old config.xml
> present . and if it is present then automatically add the path in tools
> section and populate the same as default under my build. please guide me if
> this auto upgrade is possible. i came across some method like readResolve()
> but did not understand fully.
>
> Nikhil
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c0d217b2-1d75-46bc-b4b9-d68eec14db05%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/c0d217b2-1d75-46bc-b4b9-d68eec14db05%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

Re: Catching a job cancel

2019-09-26 Thread Jeff Pearce

You can probably get the info if you implement the RunListener extension point

From:  on behalf of John Westcott IV 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Thursday, September 26, 2019 at 1:17 PM
To: Jenkins Developers 
Subject: Catching a job cancel

Notice: This email is from an external sender.


Is it possible for a plugin to get a notification if a Jenkins job is cancelled 
while the plugin is working?
i.e. is there some kind of "public void on_job_cancel()" method I can implement 
to take some action if my plugin is actively running when a job is canceled?
I'm not seeing anything in the docs but wanted to double check in case I am 
missing something.

-John

--
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/6296320b-1e84-4caa-9686-475650e8d334%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/AEC405E5-912A-46E2-9FD2-84836E31A08E%40godaddy.com.

Re: jenkins not working after server reboot

2019-09-25 Thread Jeff Pearce

Are the containers running, i.e. can you see them with `docker ps`?

From:  on behalf of rupali dixit 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Wednesday, September 25, 2019 at 6:30 AM
To: Jenkins Developers 
Subject: jenkins not working after server reboot

Notice: This email is from an external sender.


i have jenkins running as container inside docker. We had server reboot and 
after that docker service didnt comeup. i started docker service and then 
restart containers. but still jenkins is not working. any suggestion what need 
to be done?
--
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/8eaa05c0-3ce5-4008-a124-ce4942ac3e4a%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/BDB2E95A-2D69-4AE7-859F-4F618A1295FE%40godaddy.com.

Re: How to get current running job name without build number?

2019-08-10 Thread Jeff Pearce

Where are you trying to get it from? Groovy script, plugin extension point, 
something else?
Sent from my iPhone

> On Aug 10, 2019, at 5:04 AM, Navnath Kumbhar  wrote:
> 
> Hello,
> 
> I want to get my current running job name without build number.  [Because I 
> do not have build number]
> How can I do that?
> 
> Thank you in advance!
> 
> -- 
> 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/cc54491c-6123-4517-a016-615c209e7a1e%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/746F25C7-C9A0-45CF-8D53-0E3457961560%40gmail.com.

Re: Jenkins GSoC Budget update + JEP-8 confirmation for 2019

2019-07-31 Thread Jeff

+1 as well.

On Wed, Jul 31, 2019 at 2:55 AM Lloyd Chang  wrote:

> +1
>
> --
> 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/9873c541-ebae-4759-9d85-f4b390a4ac35%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/CADVhPTqRhdgL3Pgj6KqdK3GVJnwETtV%2B%3D4A%3DEe5hJBRxgorfWA%40mail.gmail.com.

Re: Doubt in Workflow plugin

2019-07-29 Thread Jeff

I've used RunListener before, and its methods definitely gets called for
pipeline jobs.

e.g.
https://github.com/jenkinsci/github-autostatus-plugin/blob/master/src/main/java/org/jenkinsci/plugins/githubautostatus/BuildStatusJobListener.java#L48

I'm not sure whether you're not seeing it getting called, or whether you're
having problems getting some specific build detail though.

Best
Jeff

On Mon, Jul 29, 2019 at 3:57 AM selva vignesh 
wrote:

> Hi,
> I am tracking the every build details of Freestyle and pipeline job. For
> freestyle i am using Runlistener and able to trace the details when build
> onStarted and onCompleted function.
> But Pipline (Workflow) job i am not able to track the build details at
> onStarted and onCompleted function in runListener. Can anyone please
> suggest how to achieve this. Kindly share me the examples if anything
> available.
> Thanks in advance
>
> --
> 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/CAOVVkpk0Rj3BLE0BXsxqjtpE4vZbPWsUXaZ4U%2Boo%2Bma0djWoOA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAOVVkpk0Rj3BLE0BXsxqjtpE4vZbPWsUXaZ4U%2Boo%2Bma0djWoOA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

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

Re: What keeps CI tests from running on this Jenkinsci repository?

2019-07-12 Thread Jeff

I don't think it was the either. Looking at the scan logs for
jenkinsio.plugins, it seems like the last time GitHub was scanned was on
Wednesday, and at least at that time it was ignoring the plugin.

On Fri, Jul 12, 2019 at 7:43 AM 'Benjamin Beggs' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Terrific, if you can do that it would be great. :)
>
> On Friday, July 12, 2019 at 10:38:27 AM UTC-4, R. Tyler Croy wrote:
>>
>> (replies inline)
>>
>> On Fri, 12 Jul 2019, 'Benjamin Beggs' via Jenkins Developers wrote:
>>
>> > Does anyone know why CI tests aren't running on pull requests for this
>> > repository?
>> > [1]https://github.com/jenkinsci/enhanced-old-build-discarder
>> >
>> > I've added a Jenkinsfile to the source root directory on the master
>> branch ([2]
>> > https://github.com/jenkinsci/enhanced-old-build-discarder/blob/master/
>> > Jenkinsfile). No CI is coming up for my latest PR ([3]
>> https://github.com/
>> > jenkinsci/enhanced-old-build-discarder/pull/3).
>> >
>>
>>
>> The directory name doesn't match the convention used by most (all?) the
>> other
>> plugins which is $(name)-plugin.git, and thus it fails the regular
>> expression
>> used by our Organization Folder.
>>
>>
>> I can change the repo name to match if you'd like
>> >
>> >
>> >
>> --
>> GitHub:  https://github.com/rtyler
>>
>> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2
>>
> --
> 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/dd6e31cc-aba5-4626-ab33-355f41e67542%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: What keeps CI tests from running on this Jenkinsci repository?

2019-07-12 Thread Jeff

I wonder if it's because you're using a very old version of the parent pom?

This line

specifies
the parent pom version, not the version of Jenkins to build against per the
comment.

On Fri, Jul 12, 2019 at 7:05 AM 'Benjamin Beggs' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Does anyone know why CI tests aren't running on pull requests for this
> repository?
> https://github.com/jenkinsci/enhanced-old-build-discarder
>
> I've added a Jenkinsfile to the source root directory on the master branch
> (
> https://github.com/jenkinsci/enhanced-old-build-discarder/blob/master/Jenkinsfile).
> No CI is coming up for my latest PR (
> https://github.com/jenkinsci/enhanced-old-build-discarder/pull/3).
>
>
>
> --
> 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/1200949864.857781.1562940329308%40mail.yahoo.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/CADVhPTp3m-eoZ885-USs-oqHC%2BYQ3yNBAZdqebyyZ7JbeBvggQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin pom http/https mass cleanup

2019-07-11 Thread Jeff Thompson


On 7/11/19 8:22 AM, Jesse Glick wrote:

On Thu, Jul 11, 2019 at 7:51 AM Daniel Beck  wrote:

3. Start with PRs, but merge myself when maintainers don't. This is basically 
what Oliver ended up doing when we added Jenkinsfiles to plugin repositories.[2]

+1 for this. An unmentioned benefit over #1 is that CI will catch
fatal mistakes in your tool, and if you are doing some batch POM
transformation with hundreds of cases you are going to have made a
couple of mistakes.


Another +1 for approach #3 from me. It's the only approach that makes 
any sense as far as I can tell.


Jeff

--
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/b9a3fd6d-4f09-ac7b-c04e-e18b5c424d21%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline API stage listener ?

2019-06-25 Thread Jeff Pearce

Code sample: 
https://github.com/jenkinsci/github-autostatus-plugin/blob/master/src/main/java/org/jenkinsci/plugins/githubautostatus/GithubBuildStatusGraphListener.java

Best 
Jeff

Sent from my iPhone

> On Jun 25, 2019, at 4:16 AM, Jesse Glick  wrote:
> 
>> On Tue, Jun 25, 2019 at 12:34 AM Felipe F  wrote:
>> an API that listens as the pipeline execution transitions between stages, 
>> and lets you grab the stage name
> 
> https://javadoc.jenkins.io/plugin/workflow-api/org/jenkinsci/plugins/workflow/flow/GraphListener.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/CANfRfr10388j-Ungkz5b1DJSDjh7Kwnk2UDbLS%3DWK%3D7szJ1jig%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/24A1BABB-DD23-4C9F-B0F0-F3893D2EB595%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [EVENT]: DevOps World Jenkins World San Francisco volunteers needed

2019-06-18 Thread Jeff

Hi Alyssa

Here's my demo info:

Title: Using React for plugin UI

The working hours plugin has a date driven UI. During this summer's Google
Summer of Code, our student rewrite the UI in React, so that we could take
advantage open source modules such as calendar pickers. I'll talk about how
the student approached the UI, demonstrate the UI and talk about particular
challenges we faces.

Best
Jeff

On Tue, Jun 18, 2019 at 9:09 AM Marky Jackson 
wrote:

> Alyssa,
> As discussed in our meeting, here is my demo titled and blurb:
>
> Title: Sysdig Secure Jenkins Plugin
> Sysdig Secure <https://sysdig.com/products/secure/> is a container
> security platform that brings together docker image scanning and run-time
> protection to identify vulnerabilities, block threats, enforce compliance,
> and audit activity across your microservices. The Sysdig Secure Jenkins
> plugin can be used in a Pipeline job, or added as a build step to a
> Freestyle job, to automate the process of running an image analysis,
> evaluating custom policies against images, and performing security scans.
>
> Please also add me to “Ask the Expert”
> My area of expertise is plugin development and CICD in Kubernetes
>
> On Jun 18, 2019, at 9:04 AM, Alyssa Tong  wrote:
>
> Hi Martin,
>
> Thank you. Yes, we can always make room for you :o) Pls send me your demo
> title and a 1-2 sentence description. And yes we will have the community
> booth space again, I can certain add you to our list of contributors (Ask
> the Experts). Can you let me know your area of expertise so I can have it
> on a slide.
>
> Thank you Martin.
> alyssa
>
>
> On Sat, May 25, 2019 at 4:37 AM martinda 
> wrote:
>
>> Hi Alyssa,
>>
>> If there is still room, I can give a a demo. I can also be at the
>> contributor's corner if there is one this year.
>>
>> Martin
>>
>> On Thursday, May 23, 2019 at 4:34:11 PM UTC-4, alytong13 wrote:
>>>
>>> Hi All,
>>>
>>> We are planning activities for the community booth at DW JW SF
>>> <https://www.cloudbees.com/devops-world/san-francisco> and are looking
>>> for the following volunteers:
>>>
>>>- Jenkins gurus for "Ask the Experts". This role is to help provide
>>>(Jenkins) tech support to attendees during the expo hours. Added bonus is
>>>you get to hang out with other Jenkins contributors.
>>>- Jenkins demos. The community booth will be showcasing 15 min demos
>>>during the lunch hours, we are accepting cool plugin or best practices
>>>demos. Can not be a product/marketing pitch.
>>>
>>> Pls reach out to me directly if you're interested in the above.
>>>
>>> Lastly, if you're attending the event, use "*FOSS" *for 30% discount.
>>>
>>> thanks,
>>> alyssa
>>>
>>
>> --
>> 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/296715fa-c932-48c4-9acb-7702221132bf%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/296715fa-c932-48c4-9acb-7702221132bf%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/yro4NtWqGKA/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/CAC9wNaxCMXYpyiy8MMexn5BXRbiMmm4XFW2_v-o3dk3EB%3DEFeQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAC9wNaxCMXYpyiy8MMexn5BXRbiMmm4XFW2_v-o3dk3EB%3DEFeQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/21ADE8BD-8BB4-4D2A-BAAD-AC6A3

Re: Accessing parameter values form a different plugin

2019-06-06 Thread Jeff Pearce

If I understand correctly, this code 
https://github.com/jenkinsci/github-autostatus-plugin/blob/daf4bf1a0553f91bb0b4deaee32905f077f050ec/src/main/java/org/jenkinsci/plugins/githubautostatus/BuildStatusJobListener.java#L83-L94
Is what you want – it puts all the parameters passed to a job into a map. It’s 
a different than what I wrote earlier, I was referencing broken code.

Best
Jeff
From: 'Jordan Vogel' via Jenkins Developers 
Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Thursday, June 6, 2019 at 7:53 AM
To: Jenkins Developers 
Subject: Re: Accessing parameter values form a different plugin

Notice: This email is from an external sender.

I'll try and give you some more specifics. Basically I am trying to access a 
parameter the jobs are passed when they are triggered by scripts. So the url 
for the POST request is my-dns.net/MyJobName/buildWithParameter
?parameterName=Value. I want to be able to access that value from a plugin. For 
example I would like to access that value within in the Perforce plugin so I 
can have some custom sync behaviors for changelists. The thing I am struggling 
with is I don't know where/how to access that parameter from a different plugin.

Thanks

On Thursday, 6 June 2019 06:22:51 UTC-6, Jesse Glick wrote:
On Wed, Jun 5, 2019 at 1:12 PM Jeff Pearce > 
wrote:
> Assuming you have the current build project, It might be included in 
> build.getParent().getProperties() 
> https://javadoc.jenkins.io/hudson/model/Job.html#getProperties--

No, `Job.properties` is unrelated.

From: 'Jordan Vogel' via Jenkins Developers 
>
> I have tried System.getEnv(EnvVar), and System.getProperty(EnvVar) both to no 
> avail

No, these are things set on the Jenkins JVM, nothing to do with build variables.

You want to get access to an `EnvVars` object. Depending on what
exactly you are doing, this might be passed in as a parameter to a
method you implement, etc. Your original description

> have some settings changes

is too vague to help with, I am afraid.
--
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
jenkinsci-dev+unsubscr...@googlegroups.com<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4255741c-9afc-493c-ae71-8e26c362ac2a%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-dev/4255741c-9afc-493c-ae71-8e26c362ac2a%40googlegroups.com?utm_medium=email_source=footer>.
For more options, visit https://groups.google.com/d/optout.

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

Re: Accessing parameter values form a different plugin

2019-06-05 Thread Jeff Pearce

Assuming you have the current build project, It might be included in 
build.getParent().getProperties() 
https://javadoc.jenkins.io/hudson/model/Job.html#getProperties--

From: 'Jordan Vogel' via Jenkins Developers 
Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Wednesday, June 5, 2019 at 10:02 AM
To: Jenkins Developers 
Subject: Accessing parameter values form a different plugin

Notice: This email is from an external sender.

Hey, so I am trying to access the variable of the job parameter which comes 
though the Parameterized Build Jobs plugin. This variable is passed in through 
the URL of the script that triggers the job. I am writing a custom plugin to 
have some settings changes based on the parameter the job gets passed in. I, 
for the life of me, can't seem to access the variable, and I am thinking this 
is because it is a variable that comes from another plugin, not inherent to 
jenkins.

I have tried System.getEnv(EnvVar), and System.getProperty(EnvVar) both to no 
avail, I have even tried to get an Array of all parameters, all of these return 
null.

Does anyone know how this is done? Do I have to change functionality in the 
Parameterized Build Jobs plugin (not ideal). Or how can I access a job 
parameter passing in from the above plugin, from a separate plugin?

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/2637a384-e218-45e1-af1b-2951708a2f09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/AE5FB6F5-A7F4-47FD-8BD7-7F526F2DA3BF%40godaddy.com.
For more options, visit https://groups.google.com/d/optout.

Re: [EVENT]: DevOps World Jenkins World San Francisco volunteers needed

2019-05-24 Thread Jeff

HI Alyssa. I'd like to participate in "Ask the Experts", and I can do a
demo as well.

Best
Jeff

On Fri, May 24, 2019 at 8:24 AM Mark Waite 
wrote:

> I'd like to participate in the "Ask the Experts" and in demos.
>
> Mark Waite
>
> On Fri, May 24, 2019 at 8:06 AM Rick  wrote:
>
>> Hi Alyssa. I want to do both if I could get my visa successfully.
>>
>> On Fri, May 24, 2019 at 5:40 PM Marky Jackson 
>> wrote:
>>
>>> I would like to participate in both the demo and ask the expert
>>>
>>> --
>>> 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/19bf8733-cf54-47b5-9456-f69dcff82238%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Zhao Xiaojie (Rick)
>> Blog: https://github.com/LinuxSuRen
>> Twitter: https://twitter.com/suren69811254
>>
>> --
>> 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/CAMM7nTGv%2BgUhHmT4XKS6S9Zyr%2BOsBdC_yEk_Bf2azDJx-Xd1XA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTGv%2BgUhHmT4XKS6S9Zyr%2BOsBdC_yEk_Bf2azDJx-Xd1XA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEynAZ9i3hm_it1m97XDyXW%3D2PZG%3DrwkLStNgumqWnGMw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEynAZ9i3hm_it1m97XDyXW%3D2PZG%3DrwkLStNgumqWnGMw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [JENKINS 57012] Need help to get current ItemGroup in configuration

2019-05-24 Thread Jeff

Hi Mathieu

Are you looking from something like the Folder Properties Plugin?
<https://wiki.jenkins.io/display/JENKINS/Folder+Properties+Plugin>

Best
Jeff

On Fri, May 24, 2019 at 5:10 AM Mathieu Delrocq 
wrote:

> Hello,
>
> I want to add the possibility to configure a folder scope credential on
> jira-plugin.
> Actually we can configure a JiraSite on the global config and on a folder
> config.
>
> I want to add the current ItemGroup in JiraSite class to know if it was
> created on a folder or on Global Config but I didn't find a way to do this.
>
> Do you have any idea how to get the ItemGroup in DataBoundConstructor or
> if there is a way to get it and set it in a configuration class?
>
> Thanks.
>
> Mathieu
>
> --
> 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/06699172-88c0-48f5-9434-4aa91ba1db2c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/06699172-88c0-48f5-9434-4aa91ba1db2c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

2019-05-20 Thread Jeff Pearce

Hi Chris

No need to publish an Alpha version for me – I’m happy to build and install 
manually

Best
Jeff

From:  on behalf of Chris Kilding 

Reply-To: "jenkinsci-dev@googlegroups.com" 
Date: Monday, May 20, 2019 at 4:56 AM
To: "jenkinsci-dev@googlegroups.com" 
Subject: Re: Proposal: AWS Secrets Manager Credentials Provider plugin

Notice: This email is from an external sender.


Jeff - I’m close to getting the plugin released via the Jenkins Incrementals 
update site (the new repository for automated plugin deployments). Will that be 
sufficient for your engineers to test with, or will you need a traditional 
alpha/beta release to the Experimental update site?

I should be able to release to Incrementals as soon as I’ve received upload 
permissions: 
https://github.com/jenkins-infra/repository-permissions-updater/pull/1137

Chris

On Fri, 17 May 2019, at 2:55 PM, Joseph P wrote:
- If I update to parent POM v3.36+ then Findbugs is replaced by Spotbugs. Will 
the Jenkins Findbugs report publisher (which all plugin builds have access to) 
understand Spotbugs reports?

Yes, SpotBugs is configured to work as a replacement and Jenkins CI will 
continue to fail.

Latest that is the experience many repos who have switched have noticed, see 
this PR: https://github.com/jenkinsci/credentials-plugin/pull/114
Which has a commit directed for "fix spotbugs"

On Friday, May 17, 2019 at 2:19:43 PM UTC+2, Chris Kilding wrote:
Alrighty, the manual way it is.

I’m following the steps to trim down the plugin POM in the release manual. 
However I’ve noticed the following quirks:

- When I inherit the parent POM’s groupId, I get the older 
“org.jenkins-ci.plugins” rather than the newer “io.jenkins.plugins”. Is this a 
problem, or can I stick with the older groupId? (It seems preferable for the 
plugin to inherit settings wherever possible.)
- When I took out the repositories and pluginRepositories sections, the plugin 
could not compile. Is there a fix for this, or should I keep a local copy of 
those sections in my POM?
- If I update to parent POM v3.36+ then Findbugs is replaced by Spotbugs. Will 
the Jenkins Findbugs report publisher (which all plugin builds have access to) 
understand Spotbugs reports?

Regards,

Chris

On Thu, 16 May 2019, at 7:15 PM, Slide wrote:
There is not currently an automated way to do this, the manual way is the only 
way.

On Thu, May 16, 2019 at 10:55 AM Chris Kilding  wrote:

The plugin now has a passing CI build on its master branch.

The next step would probably be to release an alpha version to the update site. 
I’ve seen the instructions for doing this manually, but I’m wondering if 
Jenkins has an automated pipeline to release plugins?

Chris

On Tue, 14 May 2019, at 11:03 AM, Chris Kilding wrote:
The plugin is now hosted by @jenkinsci at 
https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin

Jeff - could you delete and re-create your fork, so that the @jenkinsci repo is 
the authoritative root of the repository graph?

Regards,

Chris

On Mon, 13 May 2019, at 2:17 PM, Chris Kilding wrote:
Due to the interest in the plugin I’ve now opened a hosting request to transfer 
it to @jenkinsci at https://issues.jenkins-ci.org/browse/HOSTING-763

Chris

On Mon, 13 May 2019, at 12:08 AM, Chris Kilding wrote:
Hi Jeff,

Yep, the compile error appears to be because the Maven localize plugin is not 
run when our IDEs compile the project, so the Messages class is never generated 
from the translation files. I’ll see about a fix tomorrow. The workaround in 
the meantime is to run ‘mvn localize:generate’ manually and then resume 
compilation with the IDE.

For testing I’d appreciate your team’s input on aspects like:

- Checking plugin stability over time - can it run for long periods without 
memory leaks or crashing?
- Finding edge cases related to AWS secrets lifecycle management (eg rapid soft 
deletion or undeletion of secrets).
- Finding edge cases related to AWS API calls (the AWS SDK does retry with 
backoff and jitter automatically, but are the defaults good for our use case - 
or do we need to tweak the retry / timeout / delay parameters?)
- Documentation - is the README easy enough for a first-time user to understand?

Regards,

Chris

On Sun, 12 May 2019, at 2:56 PM, Jeff Pearce wrote:
I think you forgot to include some resources - when I build it can't find 
Messages.*. I can work around for my testing though

On Friday, May 10, 2019 at 6:08:31 AM UTC-7, Chris Kilding wrote:
The AWS Secrets Manager Credentials Provider plugin is now up on Github at 
https://github.com/chriskilding/aws-secrets-manager-credentials-provider-plugin

I need to do some initial exploratory testing and bug fixing on the plugin 
before I can release any official builds of the compiled .hpi file. But if 
you’d like to try it, you can check it out, install dependencies, and run ‘mvn 
clean verify’ to build it (see the README).

Once the plugin is ready, I’ll get t

Re: Dependency plugin specifier in Pom.xml

2019-05-18 Thread Jeff Pearce

I don’t quite get it. Can you describe the real world scenario you’re trying to 
implement?

Best,
Jeff

Sent from my iPhone

> On May 18, 2019, at 8:07 AM, selva vignesh  wrote:
> 
> Hi Adrien, 
> Thanks for replying.. my question is if I want to install my plugin it should 
> ask me to mentioned plugin should be installed example pipeline plugin should 
> be installed first and after that only allow to install my plugin.  Or else 
> installation must be failed and showing warning message as pipeline plugin 
> install before install my plugin. 
> Hope you understand now.. If not please let me know. I will explain again. 
>> On Sat, 18 May 2019 at 3:17 PM, Adrien Lecharpentier 
>>  wrote:
>> Hello,
>> 
>> all you need is to declare the plugins as dependencies of your plugin. 
>> You need to specify them in `compile` scope and not optional. 
>> 
>> However, you should only declare those plugins if you need their code for 
>> your own plugin. 
>> From your question, I'm not sure it's the case.
>> 
>> BR,
>> -- Adrien
>> 
>>> Le sam. 18 mai 2019 à 08:40, selva vignesh  a 
>>> écrit :
>>> HI,
>>>   How to make some dependency plugin to be installed while our plugin 
>>> before installing.
>>> What are the changes need to be done at pom.xml.
>>> Thanks in advance
>>> -- 
>>> 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/f678a5d0-0ee5-4a76-b5f5-ed2b395bc674%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> -- 
>> 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/CAKwJSvyFrXQFEfo_mCpvzZWiKc_rUZaz28r9Hx2mRg3S%2B0ACoQ%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/CAOVVkp%3D9e_QYCutDYnVL3qq4SMtuia%2BGyKJPGAV57GWdumDHTA%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/FC7C0AA5-276E-4A8A-8CAC-1D17758D682C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Doubt in build end of Job

2019-05-16 Thread Jeff

have you looked at BuildStatusJobListener?

On Thu, May 16, 2019 at 5:57 AM selva vignesh 
wrote:

> Hi,
> I want to do some operation at the end of the build post Action.
> is there any wiki available for the same?
>
> --
> 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/bb3fbfd2-6e45-451a-8c84-8898e4ffce31%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: How to get Build running status

2019-05-14 Thread Jeff

Depends on what you're trying to do, but after the build is complete it
should be available from the job via getResult
()

On Tue, May 14, 2019 at 2:08 AM selva vignesh 
wrote:

> Hi All,
> Can any one please let me know how to get build running status. What
> kind of class should i extend for the same.
> Thanks in advance
>
> --
> 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/b272366e-66f3-4811-8f71-72264ca7d804%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: How does the "Credentials Binding Plugin" work?

2019-05-14 Thread Jeff Pearce

I don’t know the answer, but generally when I’m trying to figure something like 
this out, I clone the repo, run it locally, and set breakpoints in the places 
I’m interested. I find I learn quite a bit doing this.

Best
Jeff

Sent from my iPhone

> On May 14, 2019, at 5:01 AM, Shihaaz Buhary  wrote:
> 
> How does the "Credentials Binding Plugin" work internally? How is the 
> credentials are stored?
> -- 
> 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/06e103fc-e92e-42af-bd94-33caa9b839cb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Have doubt in Jenkins plugin development

2019-05-12 Thread Jeff

Are you looking for something like JobProperty
<https://javadoc.jenkins.io/hudson/model/JobProperty.html> to even
OptionalJobProperty
<https://javadoc.jenkins.io/jenkins/model/OptionalJobProperty.html>?

Best
Jeff

On Sun, May 12, 2019 at 6:56 AM selva vignesh 
wrote:

> Hi All,
>  I am developing a Jenkins plug-in which almost in releasing stage. Still
> I haven’t find any wiki to create custom project parameter option. Like
> String Parameter I would like to create my own parameter. Can any one help
> me to finish this thing.
> Thanks in Advance
>
> --
> 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/fc319655-007c-42b2-b9a9-0ef36bfb9c53%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

2019-05-12 Thread Jeff Pearce

I think you forgot to include some resources - when I build it can't find 
Messages.*. I can work around for my testing though

On Friday, May 10, 2019 at 6:08:31 AM UTC-7, Chris Kilding wrote:
>
> The AWS Secrets Manager Credentials Provider plugin is now up on Github at 
> https://github.com/chriskilding/aws-secrets-manager-credentials-provider-plugin
>
> I need to do some initial exploratory testing and bug fixing on the plugin 
> before I can release any official builds of the compiled .hpi file. But if 
> you’d like to try it, you can check it out, install dependencies, and run 
> ‘mvn clean verify’ to build it (see the README).
>
> Once the plugin is ready, I’ll get the show on the road to migrate it to 
> @jenkinsci and make it official.
>
> Chris
>
> On Tue, 7 May 2019, at 2:19 PM, Chris Kilding wrote:
>
> Hello again,
>
> I solved my previous question when I found that Jenkins would sensibly 
> handle a CredentialsUnavailableException thrown from the getSecret() 
> implementation. This is just a suitably named unchecked exception that’s 
> provided by the credentials plugin.
>
> Chris
>
> On Tue, 23 Apr 2019, at 5:37 PM, Chris Kilding wrote:
>
> Hi Stephen,
>
> I did have one question that’s not covered by the guide...
>
> The guide says that a credential that fetches its secret value from a 
> remote service must throw an IOException if there is a data-related problem 
> (eg 404 not found), and an InterruptedException if the lookup times out.
>
> However the guide also says that if there is already a de-facto standard 
> credential type, one’s own credential Provider should use that.
>
> In my case I need to extend BaseStandardCredentials / implement 
> StringCredentials, and look up the AWS Secret Value within getSecret(). 
> However the StringCredentials interface does not allow IOException or 
> InterruptedException to be thrown by implementations.
>
> The guide even acknowledges that this was a design flaw in the standard 
> credentials types... but unfortunately it doesn’t say what to do instead, 
> to work around this.
>
> So, should an implementation of StringCredentials#getSecret()...
>
> - Throw an unchecked exception?
> - Return null?
> - Something else?
>
> Chris
>
> On Tue, 9 Apr 2019, at 1:41 PM, Stephen Connolly wrote:
>
>
>
> On Tue, 9 Apr 2019 at 11:57, Chris Kilding  > wrote:
>
>
> Hi Stephen,
>
> When I started building the plugin my basis was a combination of your 
> guide and the Kubernetes Credentials Provider.
>
> The following sections of your guide were particularly valuable right from 
> the start of development:
>
> - The caching strategy guide for remote credentials providers (cache 
> metadata for N minutes, retrieve secret data live).
> - “Implementing a new Credentials type” (when and how to extend the 
> standard types properly, when to make a new type).
>
> I’m finding the guide is becoming more understandable (and I can get more 
> out of it) now I’ve learned the basic architecture of Jenkins plugins. In 
> the beginning it’s easier to work off an existing plugin’s code, but now I 
> can read more of your guide and see implementation mistakes that need to be 
> corrected.
>
> Much like any other technical manual, its utility for the reader increases 
> with the reader’s knowledge of the subject. Many thanks for writing it :)
>
>
> Glad to hear. I wasn't happy moving my focus away from Jenkins plugins 
> without leaving guides to the community for the stuff I believe to be 
> important (credentials and scm-api). I am glad you have found (and are 
> still finding) utility in the content. Feel free to create PRs with any 
> suggested improvements as I am paying attention... just not as frequently 
> ;-)
>
> - Stephen
>  
>
>
>
> Chris
>
> On Mon, 8 Apr 2019, at 8:00 PM, Stephen Connolly wrote:
>
> It would be great to get any feedback on the docs I left for writing such 
> things: 
>
> https://github.com/jenkinsci/credentials-plugin/blob/master/docs/implementation.adoc#implementing-a-new-credentialsprovider
>
> On Thu 4 Apr 2019 at 17:10, Chris Kilding  > wrote:
>
>
> Hi,
>
> That sounds good - we’re happy to host in jenkinsci and make the plugin 
> available through the built-in Jenkins plugin manager.
>
> As Jesse suggested we did indeed base our plugin on the Kubernetes 
> credentials provider.
>
> Would we be able to do it all in a single Github repo inside the jenkinsci 
> org? Or would we have to run a separate upstream repo in our own Github 
> account, with a fork under jenkinsci? (We’d prefer to go with the first 
> option and cut out the middleman, if that makes sense.)
>
> On Thu, 4 Apr 2019, at 4:51 PM, Daniel Beck wrote:
>
> Can't wait to check this out. Thanks for publishing it!
>
> > On 4. Apr 2019, at 16:21, Chris Kilding  > wrote:
> > 
> > We’re initially thinking it should be a Github repo under the 
> ‘jenkinsci’ or ‘aws’ organisations, with our own engineers added to that 
> repo as external collaborators. (These would seem to be the most natural

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

2019-05-12 Thread Jeff Pearce

This is an awesome plugin. I have a couple of people at my company 
interested in testing it - let me know if there are any specific areas that 
need focus.

I'd suggest getting hosting on jenkinio soon. That would allow you to 
release alpha and beta versions of the plugin. I'm happy to help if you 
haven't gone through the process before

Best
Jeff


On Friday, May 10, 2019 at 6:08:31 AM UTC-7, Chris Kilding wrote:
>
> The AWS Secrets Manager Credentials Provider plugin is now up on Github at 
> https://github.com/chriskilding/aws-secrets-manager-credentials-provider-plugin
>
> I need to do some initial exploratory testing and bug fixing on the plugin 
> before I can release any official builds of the compiled .hpi file. But if 
> you’d like to try it, you can check it out, install dependencies, and run 
> ‘mvn clean verify’ to build it (see the README).
>
> Once the plugin is ready, I’ll get the show on the road to migrate it to 
> @jenkinsci and make it official.
>
> Chris
>
> On Tue, 7 May 2019, at 2:19 PM, Chris Kilding wrote:
>
> Hello again,
>
> I solved my previous question when I found that Jenkins would sensibly 
> handle a CredentialsUnavailableException thrown from the getSecret() 
> implementation. This is just a suitably named unchecked exception that’s 
> provided by the credentials plugin.
>
> Chris
>
> On Tue, 23 Apr 2019, at 5:37 PM, Chris Kilding wrote:
>
> Hi Stephen,
>
> I did have one question that’s not covered by the guide...
>
> The guide says that a credential that fetches its secret value from a 
> remote service must throw an IOException if there is a data-related problem 
> (eg 404 not found), and an InterruptedException if the lookup times out.
>
> However the guide also says that if there is already a de-facto standard 
> credential type, one’s own credential Provider should use that.
>
> In my case I need to extend BaseStandardCredentials / implement 
> StringCredentials, and look up the AWS Secret Value within getSecret(). 
> However the StringCredentials interface does not allow IOException or 
> InterruptedException to be thrown by implementations.
>
> The guide even acknowledges that this was a design flaw in the standard 
> credentials types... but unfortunately it doesn’t say what to do instead, 
> to work around this.
>
> So, should an implementation of StringCredentials#getSecret()...
>
> - Throw an unchecked exception?
> - Return null?
> - Something else?
>
> Chris
>
> On Tue, 9 Apr 2019, at 1:41 PM, Stephen Connolly wrote:
>
>
>
> On Tue, 9 Apr 2019 at 11:57, Chris Kilding  > wrote:
>
>
> Hi Stephen,
>
> When I started building the plugin my basis was a combination of your 
> guide and the Kubernetes Credentials Provider.
>
> The following sections of your guide were particularly valuable right from 
> the start of development:
>
> - The caching strategy guide for remote credentials providers (cache 
> metadata for N minutes, retrieve secret data live).
> - “Implementing a new Credentials type” (when and how to extend the 
> standard types properly, when to make a new type).
>
> I’m finding the guide is becoming more understandable (and I can get more 
> out of it) now I’ve learned the basic architecture of Jenkins plugins. In 
> the beginning it’s easier to work off an existing plugin’s code, but now I 
> can read more of your guide and see implementation mistakes that need to be 
> corrected.
>
> Much like any other technical manual, its utility for the reader increases 
> with the reader’s knowledge of the subject. Many thanks for writing it :)
>
>
> Glad to hear. I wasn't happy moving my focus away from Jenkins plugins 
> without leaving guides to the community for the stuff I believe to be 
> important (credentials and scm-api). I am glad you have found (and are 
> still finding) utility in the content. Feel free to create PRs with any 
> suggested improvements as I am paying attention... just not as frequently 
> ;-)
>
> - Stephen
>  
>
>
>
> Chris
>
> On Mon, 8 Apr 2019, at 8:00 PM, Stephen Connolly wrote:
>
> It would be great to get any feedback on the docs I left for writing such 
> things: 
>
> https://github.com/jenkinsci/credentials-plugin/blob/master/docs/implementation.adoc#implementing-a-new-credentialsprovider
>
> On Thu 4 Apr 2019 at 17:10, Chris Kilding  > wrote:
>
>
> Hi,
>
> That sounds good - we’re happy to host in jenkinsci and make the plugin 
> available through the built-in Jenkins plugin manager.
>
> As Jesse suggested we did indeed base our plugin on the Kubernetes 
> credentials provider.
>
> Would we be able to do it all in a single Github repo inside the jenkinsci 
> org

Re: Looking to contribute to official Discard Old Build plugin distribution

2019-05-08 Thread Jeff

HI Benjamin

You should be able to just submit a PR to the repo, and one of the
maintainers should review it and merge it if they feel it's a good
addition. I'd suggest smaller PRs, and if appropriate you can discuss
individual proposed changes here, or you could contact the maintainers
directly.

Keep in mind that most plugin maintainers are volunteers, and it's easy for
them to miss a PR, so don't be discouraged if you have trouble getting
traction at first. I've found direct emails to work well when my PRs aren't
reviewed within a few days.

Best,
Jeff

On Wed, May 8, 2019 at 8:12 AM Benjamin Beggs 
wrote:

> Hi,
>
> I'm hoping to update the Discard Old Build plugin (
> https://plugins.jenkins.io/discard-old-build) to expand its feature set
> and improve general reliability/stability. I will be updating the code to
> allow for more sophisticated discard conditions. For e.g. allowing a user
> to request that builds older than N days are discarded but at least the M
> most recent builds are kept no matter their age. How do I go about having
> my contributions added to the distribution provided by the Jenkins plugin
> server?
>
> Best,
> Benjamin
>
> --
> 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/d813ec6c-521b-4b10-ab5c-388bad9ddbce%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/d813ec6c-521b-4b10-ab5c-388bad9ddbce%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Request to be made a maintainer - Cobertura plugin

2019-05-07 Thread Jeff

I'm one of the maintainers of the Cobertura plugin, and Shenyu has spoken
to me about this. I think it's a great idea to have an additional
maintainer, and ShenYu has done lots of code coverage related work in the
past, including authoring the code coverage API plugin during last summer's
Google Summer of Code.

Shenyu, please submit a PR to
https://github.com/jenkins-infra/repository-permissions-updater to add
yourself.

All the best
Jeff

On Mon, May 6, 2019 at 8:32 PM Zheng Shenyu  wrote:

> Hi all,
>
> I want to be the maintainer of the Cobertura plugin
> https://github.com/jenkinsci/cobertura-plugin.
>
> There are several issues about Cobertura in Code Coverage API plugin:
>
>- https://github.com/jenkinsci/code-coverage-api-plugin/issues/69
>- https://github.com/jenkinsci/code-coverage-api-plugin/issues/79
>- https://github.com/jenkinsci/code-coverage-api-plugin/issues/80
>
> In order to fix them, I need to change or add some codes to the Cobertura
> plugin. Also, there might be more issues about Cobertura in the future. So
> If I can be the maintainer I can fix them easier.
>
> I am familiar with the codes of the Cobertura plugin, so I can also do
> some other improvements.
>
> My GitHub username is https://github.com/cizezsy
> My Jenkins Infrastructure ID is cizezsy
>
> Thanks,
> Shenyu Zheng
>

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

Re: Seeking 2nd mentor for React based Google Summer of Code project

2019-04-16 Thread Jeff

Thanks, Keith!

I added you to the project as a mentor.

Jeff

On Sun, Apr 14, 2019 at 6:25 PM Keith Zantow  wrote:

> It looks like this is not really a React-heavy project; nonetheless, I'm
> happy to offer guidance/mentorship from the React UI perspective,
> especially as a secondary mentor.
>
> Cheers,
> -Keith
>
> On Sun, Apr 14, 2019 at 11:04 AM Jeff Pearce  wrote:
>
>> Hi all.
>>
>> We're busy gearing up for Jenkins' involvement in the Google Summer of
>> Code <https://summerofcode.withgoogle.com/>. I'm planning on mentoring
>> this project if it's accepted by Google:
>>
>>
>> https://jenkins.io/projects/gsoc/2019/project-ideas/working-hours-improvements/
>>
>> It's best to have more than one mentor on a project, so I'm looking for
>> someone to help out. Responsibilities would include attending regular
>> office hours as available, reviewing code, and providing suggestions. I
>> expect to be able to attend office hours except while on vacation. The
>> project runs from early May until the end of August.
>>
>> One of the goals for this project is to use React to host a javascript
>> calendar control, which if successful will provide a sample for future
>> plugins.
>>
>> This is a great opportunity to share your experience with students, while
>> also helping to expose potential new contributors to Jenkins open source.
>> If the idea of mentoring a student appeals do you, but this project does
>> not, please let me know, as we can always use additional mentors.
>>
>> Thanks for your consideration
>> Jeff
>>
>> --
>> 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/f894d825-79e6-4cba-933b-712daab075b3%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/f894d825-79e6-4cba-933b-712daab075b3%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Keith Zantow
> Senior Software Engineer
> CloudBees, Inc.
>
> [image: CloudBees-Logo.png]
>
>
> E: kzan...@cloudbees.com
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/qDvFW4H0saI/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/CAJTHQaFY-n254f-SAh1iwwv7MP5SJXWGZtPYtOy5nMve%3DmEdug%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAJTHQaFY-n254f-SAh1iwwv7MP5SJXWGZtPYtOy5nMve%3DmEdug%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Seeking 2nd mentor for React based Google Summer of Code project

2019-04-14 Thread Jeff Pearce

Hi all.

We're busy gearing up for Jenkins' involvement in the Google Summer of Code 
<https://summerofcode.withgoogle.com/>. I'm planning on mentoring this 
project if it's accepted by Google:

https://jenkins.io/projects/gsoc/2019/project-ideas/working-hours-improvements/

It's best to have more than one mentor on a project, so I'm looking for 
someone to help out. Responsibilities would include attending regular 
office hours as available, reviewing code, and providing suggestions. I 
expect to be able to attend office hours except while on vacation. The 
project runs from early May until the end of August.

One of the goals for this project is to use React to host a javascript 
calendar control, which if successful will provide a sample for future 
plugins.

This is a great opportunity to share your experience with students, while 
also helping to expose potential new contributors to Jenkins open source. 
If the idea of mentoring a student appeals do you, but this project does 
not, please let me know, as we can always use additional mentors.

Thanks for your consideration
Jeff

-- 
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/f894d825-79e6-4cba-933b-712daab075b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jaxen

2019-03-07 Thread Jeff Thompson

Yes, that’s my proposal.

Jeff


> On Mar 7, 2019, at 4:30 PM, R. Tyler Croy  wrote:
> 
> 
> Archival in GitHub sounds reasonable to me, I presume we won't do anything in
> Artifactory?
> 
> 
> If everybody's fine with this, either an Infra ticket, or one of the other
> github admins can take care of this easily.
> 
> 
> --
> GitHub:  https://github.com/rtyler
> 
> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
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/4BF6F506-DEAC-4BA3-9407-A8CBBD76F426%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

jaxen

2019-03-07 Thread Jeff Thompson

Recently while looking to clean up something else I ran across a Jenkins 
specific fork of the jaxen library. The fork is at 
https://github.com/jenkinsci/jaxen <https://github.com/jenkinsci/jaxen>

I haven’t been able to detect any changes in the Jenkins fork. Indeed, the last 
commit in the fork seems to match perfectly to this commit in the official 
repository: 
https://github.com/jaxen-xpath/jaxen/commit/b08dc0a896a3712f636202e020bfcfa98ece4fb7
 
<https://github.com/jaxen-xpath/jaxen/commit/b08dc0a896a3712f636202e020bfcfa98ece4fb7>

I also cannot find any uses of the fork in Jenkins. The version in the fork is 
the same as the latest standard published one. Most dependency references in 
the Jenkins ecosystem are actually to older versions. (That’s another issue.)

I propose to archive or delete the fork from the Jenkins organization to clean 
things up.

Any concerns or agreement?

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/BA3DD97A-90BA-4807-A98F-1CD88F8CA09A%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing CLI over Remoting

2019-01-07 Thread Jeff Thompson

It’s not exactly a third opinion because I agree with Jesse. Jenkins build and 
test structures are already complicated enough. I would hope to not increase 
that complexity with a clear, demonstrated need.

Jeff Thompson

> On Jan 7, 2019, at 7:20 AM, Jesse Glick  wrote:
> 
> On Sun, Jan 6, 2019 at 12:32 PM Oleg Nenashev  wrote:
>> maybe it makes sense to move [Remoting-based CLI] to a plugin
> 
> Not possible I am afraid. It either needs to be baked into core and
> supported, or deleted.
> 
>> It is just a matter of time till we hit another Java-specific test class
> 
> There is no indication that we will. The only Java 8-specific tests
> are those which use ysoserial, which deliberately compiles against
> internal JRE classes to simulate deserialization exploits.
> 
>> we may need to create Java11-only tests
> 
> I would hope that if we start having lots of Java 11-specific code, we
> should simply decide to drop support for 8 already. In the past when
> we needed on occasion to (for example) test some 7+ API when the repo
> as a whole depended only on 6, we used reflection with a TODO comment
> to clean it up when requiring the newer Java level.
> 
>> add tests relying on modules detached from Java 11
> 
> I am not sure what this means, could you elaborate?
> 
>> I prefer to keep the code ready to such requirements
> 
> My preference was to keep the source structure as simple as possible
> and make it more complex only if and when there is a demonstrated need
> that cannot be solved in a simpler way. If that ever happens, we have
> Git history to serve as a working example.
> 
> Any third opinions?
> 
> -- 
> 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/CANfRfr3Jh6udHP2z1ndpKNjrRB8qzSgwgQDuC1yTczNvMXjWiA%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/57BB7C5A-656D-453A-B643-2BD137DA10E2%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2019 - Remoting project ideas

2019-01-06 Thread Jeff Pearce

I’m willing to be a co-mentor on either of the two options, depending on how
many others are selected

Sent from my iPhone

On Jan 6, 2019, at 9:57 AM, Supun Wanniarachchi
mailto:supunpram...@gmail.com>> wrote:

Sounds interesting. Last year we had a successful remoting project and it would
be nice to have a remoting project this year as well. I also would try to find
some spare time to help the project.

On Fri, Jan 4, 2019 at 7:08 PM Pham Vu Tuan
mailto:phamvutua...@gmail.com>> wrote:
Hi,

After checking through Oleg's suggestions, I am thinking we can move it forward
with 2 projects this year:
- Project 1: Update Remoting over Kafka to support K8s - Current demo setup is
using Docker compose, and I think K8s is more popular nowadays, maybe we can
somehow integrate this. And if this setup is done, maybe auto provisioning of
Kafka cluster can be more convinient?

- Project 2: Integrating Remoting messaging with Prometheus monitoring - By
this you mean we will do this for JNLP agents monitoring? To replace the
traditional monitoring we are having in Jenkins master? I suggest we can rename
it to "Integrating remoting with monitoring tools", because there are many
monitoring tools out there (not only Prometheus), and we let the student choose
one? We can also make the plugin generic such that user can integrate Jenkins
with any monitoring system of their choice (but Im not sure it's doable).

I can be the mentor for Project 1 (because I understand about remoting over
Kafka), and can help for project 2 with other mentors (I think we need to have
someone with deep understanding of remoting for this project).

On Fri, Jan 4, 2019 at 8:44 AM Pham Vu Tuan
mailto:phamvutua...@gmail.com>> wrote:
Hi, I am happy to help as a mentor for GSoC this year. I will try to check the
details and get back to you about my ideas asap. I will join the GSoC weekly
meeting from next week so that we can discuss about this topic.
(Sorry for not attending the meeting last month, I was a bit busy + holiday
period).

On Fri, Jan 4, 2019 at 7:33 AM Jeff Thompson
mailto:jthomp...@cloudbees.com>> wrote:
These sound like good projects. It would be nice to get a GSoC project going in
Remoting. Last year’s project was a very good, productive one.

At this time I don’t know that I can commit to being a primary mentor but I
could help out some.

Jeff Thompson

On Jan 3, 2019, at 4:00 AM, Oleg Nenashev
mailto:o.v.nenas...@gmail.com>> wrote:

I have also added the Jenkins Developers mailing list to Cc so that we can get
more inputs and ideas

On Thu, Jan 3, 2019 at 11:20 AM Oleg Nenashev
mailto:o.v.nenas...@gmail.com>> wrote:
Hi all,

Just to follow-up on the Remoting topic, it would be great to have a GSoC
project idea for Remoting this year. You were interested in mentoring a project
in the area, so it would be great to get your feedback.

One of the ideas I have is to continue improving Remoting over Kafka to improve
Remoting behavior in Docker and K8s environments. Examples:

* Cloud API implementation for Kafka agents
* Simplify JAR cache warmup while building agent images
* Update Remoting over Kafka to improve support of Kubernetes there
* Descriptions
* Connector logic using credentials from K8s
* Automatic provisioning of the Kafka cluster from the plugin
* etc.
* Create reference K8s specks and Helm charts for Remoting over Kafka system
* Integrate Remoting messaging with Prometheus monitoring
* ...

WDYT? If you are interested in such idea, we could create a project idea draft
together. I might not be available to be a mentor this year, but I will be
happy to be a technical advisor in this project.

Best regards,
Oleg

--
Thank You & Best Regards,

Supun Wanniarachchi | Software Engineer

Sysco LABS | 55A Dharmapala Mw, Col. 03
• Mobile: +94716326119 | Blog: blog.supun.me<http://blog.supun.me>)

[Github]<https://github.com/Supun94> [LinkedIn]
<https://www.linkedin.com/in/supun-wanniarachchi-21b37a97/> [Twitter]
<https://twitter.com/SuuPuuN>
[https://docs.google.com/uc?export=download=1MlUl8_XPozvuz4sXHk-qjq2ovdRAKJw5=0B80JGoHVmUHwUllMTGVhdUNVR3BPam1Zc1hSaTRmd01hbFpNPQ]

--
You received this message because you are subscribed to the Google Groups
"jenkinsci-gsoc-all-public" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
jenkinsci-gsoc-all-public+unsubscr...@googlegroups.com<mailto:jenkinsci-gsoc-all-public+unsubscr...@googlegroups.com>.
To post to this group, send email to
jenkinsci-gsoc-all-pub...@googlegroups.com<mailto:jenkinsci-gsoc-all-pub...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-gsoc-all-public/CAGUi3yW%2Bw62m5dA5szSiqjmxvTvhQQNgk7nFE2OKk%2BPQMV3K4w%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-gsoc-all-publ

Re: Removing CLI over Remoting

2019-01-04 Thread Jeff Thompson

+1

I support this proposal. We’ve seen another case recently of a problem with 
this antiquated mode. We have had to adjust tests to continue supporting it.

I don’t think there is enough value in continuing to support it, particularly 
with the costs to keep coaxing it along.

Jeff Thompson

> On Jan 4, 2019, at 2:42 PM, Jesse Glick  wrote:
> 
> As of JENKINS-41745, merged in Jenkins 2.54 more than a year and a
> half ago, the Remoting transport for the Jenkins CLI has been
> deprecated as inherently hard to secure and just plain unwise. As far
> as I know, all important CLI commands have long since removed any
> dependency on this mode, or offered an alternative mode. The UI warns
> you if you enable it. Is it time to finally remove this code?
> 
> I bring this up now because of Java 11 work:
> 
> https://github.com/jenkinsci/jenkins/pull/3759
> 
> made the physical layout of Jenkins core more complex, just in order
> to maintain some exploit tests which were really only interesting in
> CLI over Remoting, and not even that interesting anyway after JEP-200.
> (Deserialization attacks via agents could still be launched, but
> again, that would be much harder after JEP-200.)
> 
> I propose this `jenkins-test-jdk8` module and its three test suites
> and ysoserial library be deleted, whether or not CLI over Remoting is
> also removed, so that we can remove `jenkins-test-parent` and go back
> to having only `jenkins-test`.
> 
> -- 
> 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/CANfRfr3RN-dRrPFXW%2Bn1S9V8VXDPRqxQL02t0NHcVyqwEq1n3g%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/78DB206D-FBA7-4F95-8AE8-AFC5280800CF%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2019 - Remoting project ideas

2019-01-03 Thread Jeff Thompson

These sound like good projects. It would be nice to get a GSoC project going in 
Remoting. Last year’s project was a very good, productive one.

At this time I don’t know that I can commit to being a primary mentor but I 
could help out some.

Jeff Thompson

> On Jan 3, 2019, at 4:00 AM, Oleg Nenashev  wrote:
> 
> I have also added the Jenkins Developers mailing list to Cc so that we can 
> get more inputs and ideas
> 
> On Thu, Jan 3, 2019 at 11:20 AM Oleg Nenashev  <mailto:o.v.nenas...@gmail.com>> wrote:
> Hi all,
> 
> Just to follow-up on the Remoting topic, it would be great to have a GSoC 
> project idea for Remoting this year. You were interested in mentoring a 
> project in the area, so it would be great to get your feedback.
> 
> One of the ideas I have is to continue improving Remoting over Kafka to 
> improve Remoting behavior in Docker and K8s environments. Examples:
> Cloud API implementation for Kafka agents
> Simplify JAR cache warmup while building agent images
> Update Remoting over Kafka to improve support of Kubernetes there
> Descriptions
> Connector logic using credentials from K8s
> Automatic provisioning of the Kafka cluster from the plugin
> etc.
> Create reference K8s specks and Helm charts for Remoting over Kafka system
> Integrate Remoting messaging with Prometheus monitoring
> ...
> WDYT? If you are interested in such idea, we could create a project idea 
> draft together. I might not be available to be a mentor this year, but I will 
> be happy to be a technical advisor in this project.
> 
> Best regards,
> 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/4EA7A403-1BFC-4668-9998-A8D8DC8B40EC%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Be able to merge on core

2019-01-03 Thread Jeff Thompson

+1

Ramón has been contributing lots of great work in authoring and reviewing PRS 
and other efforts.

Jeff Thompson

> On Jan 2, 2019, at 9:50 AM, Baptiste Mathus  wrote:
> 
> I agree with this request.
> 
> Ramon has helped a lot also recently on ATH and a few other components 
> <https://github.com/pulls?q=is%3Apr+author%3Amramonleon+archived%3Afalse+is%3Aclosed>,
>  many reviewed and merged by Oliver. So I believe this request is reasonable.
> 
> Le mer. 2 janv. 2019 à 11:02, Manuel Ramón León Jiménez 
>  <mailto:manuel.ramon.leon.jime...@gmail.com>> a écrit :
> 
> Hello guys, happy new year.
> 
> I'm working at CloudBees on the open source size and due to the limited 
> bandwith from Oleg and to gain more velocity in some developments, specially 
> on java11, I believe it could be interesting that you allow me to have write 
> permission on Jenkins core and jenkins infra github repos to be able to merge 
> some PRs. 
> 
> If it helps: 
> 
> I've being contributing with some PRs already merged to the core as well as 
> reviewed some other ones:
> PRs merged into core:
> https://github.com/jenkinsci/jenkins/pull/3816 
> <https://github.com/jenkinsci/jenkins/pull/3816>
> https://github.com/jenkinsci/jenkins/pull/3769 
> <https://github.com/jenkinsci/jenkins/pull/3769>
> https://github.com/jenkinsci/jenkins/pull/3768 
> <https://github.com/jenkinsci/jenkins/pull/3768>
> https://github.com/jenkinsci/jenkins/pull/3718 
> <https://github.com/jenkinsci/jenkins/pull/3718>
> https://github.com/jenkinsci/jenkins/pull/3695 
> <https://github.com/jenkinsci/jenkins/pull/3695>
> https://github.com/jenkinsci/jenkins/pull/3648 
> <https://github.com/jenkinsci/jenkins/pull/3648>
> PRs reviewed in core:
> https://github.com/jenkinsci/jenkins/pull/3786 
> <https://github.com/jenkinsci/jenkins/pull/3786>
> https://github.com/jenkinsci/jenkins/pull/3795 
> <https://github.com/jenkinsci/jenkins/pull/3795>
> https://github.com/jenkinsci/jenkins/pull/3797 
> <https://github.com/jenkinsci/jenkins/pull/3797>
> https://github.com/jenkinsci/jenkins/pull/3807 
> <https://github.com/jenkinsci/jenkins/pull/3807>
> https://github.com/jenkinsci/jenkins/pull/3804 
> <https://github.com/jenkinsci/jenkins/pull/3804>
> https://github.com/jenkinsci/jenkins/pull/3815 
> <https://github.com/jenkinsci/jenkins/pull/3815>
> https://github.com/jenkinsci/jenkins/pull/3818 
> <https://github.com/jenkinsci/jenkins/pull/3818>
> 
> I'm also a maintainer of two plugins 
> (plugin-apache-httpcomponents-client-4-api 
> <https://github.com/jenkins-infra/repository-permissions-updater/blob/c36791fe566600eb60d0e74e12014ab913e8fe03/permissions/plugin-apache-httpcomponents-client-4-api.yml>
>  and plugin-jdk-tool 
> <https://github.com/jenkins-infra/repository-permissions-updater/blob/65d87d830348fb504ce28f10982c9baafb3c02a9/permissions/plugin-jdk-tool.yml>).
> 
> My user id in all systems (github, jenkins jira, ...) is: mramonleon
> 
> Thank you, kind regards.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/7fedc96c-5b22-4234-a2b5-b7afd5dc688a%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/7fedc96c-5b22-4234-a2b5-b7afd5dc688a%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7yLsQ3zYav%2BmktD-cu07_Q20Uu1ePAQogZxbmgkDzppw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7yLsQ3zYav%2BmktD-cu07_Q20Uu1ePAQogZxbmgkDzppw%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/D7B2A5B8-E4C5-434D-B251-B966FFD82B85%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to join organization

2019-01-03 Thread Jeff Thompson

+1 from me.

Fran does good work and granting him the permissions will help get more 
productive stuff done in Jenkins.

Jeff Thompson


> On Jan 2, 2019, at 9:51 AM, Baptiste Mathus  wrote:
> 
> +1 from me.
> 
> Le jeu. 27 déc. 2018 à 12:14,  <mailto:fjfernan...@cloudbees.com>> a écrit :
> Hi all,
> 
> I am Francisco Javier Fernández González, currently engineer at CloudBees. 
> During the last year I've been collaborating with some work of the community, 
> becoming co-maintainer of the Jenkinsfile-runner project 
> <https://github.com/jenkinsci/jenkinsfile-runner/> with Oleg Nenashev 
> <https://github.com/oleg-nenashev> and Evaristo Gutiérrez 
> <https://github.com/varyvol>, and maintainer of Folders plugin 
> <https://github.com/jenkinsci/cloudbees-folder-plugin/>. I would like to 
> continue collaborating in the maintenance of Jenkins and its ecosystem of 
> plugins, and in terms of easing my collaborations and reviews, I would like 
> to become a member of the organization getting the merge permissions for the 
> core. Would it be possible?
> 
> Just in case you're interested in knowing more from me:
> My Jenkins JIRA user is fcojfernandez 
> <https://issues.jenkins-ci.org/secure/ViewProfile.jspa?name=fcojfernandez>
> My github user is fcojfernandez <https://github.com/fcojfernandez>
> My contributions to the jenkinsci organization: 
> https://github.com/pulls?utf8=%E2%9C%93=is%3Apr+author%3Afcojfernandez+archived%3Afalse+user%3Ajenkinsci+
>  
> <https://github.com/pulls?utf8=%E2%9C%93=is%3Apr+author%3Afcojfernandez+archived%3Afalse+user%3Ajenkinsci+>
> Specific contributions to jenkins-core: 
> https://github.com/jenkinsci/jenkins/pulls?utf8=%E2%9C%93=is%3Apr+author%3Afcojfernandez+
>  
> <https://github.com/jenkinsci/jenkins/pulls?utf8=%E2%9C%93=is%3Apr+author%3Afcojfernandez+>
> 
> Best Regards!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/3a997e95-4d44-4933-bc9e-a92c1a574644%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/3a997e95-4d44-4933-bc9e-a92c1a574644%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6mb7ztsLXZ4306XN%2B-%2BcOriAZqnZJ5-XdDoL-rs-cCMg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6mb7ztsLXZ4306XN%2B-%2BcOriAZqnZJ5-XdDoL-rs-cCMg%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/5559A2A9-34EC-43D5-A5E8-7BBD51F9B781%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: adopt thin-backup plugin

2018-09-20 Thread Jeff Pearce

Adding current plugin maintainers to thread 

On 8/12/18, 4:29 PM, "jenkinsci-dev@googlegroups.com on behalf of Daniel Beck" 
 wrote:


> On 11. Aug 2018, at 16:20, jxpea...@godaddy.com wrote:
> 
> The wiki page for the thin-backup plugin says it's up for adoption. I 
reached out to the two people currently listed as maintainers to see if there 
were sill maintaining it, but got no response.
> 
> Hence, I'd like to adopt this plugin.

Please file a PR at 
https://github.com/jenkins-infra/repository-permissions-updater/ as described 
in the README, reference this thread, and make sure to ping the existing 
maintainers (GitHub users). Mention that you will also need GitHub commit 
access.

Please also CC the existing maintainer(s) in this thread after a genuine 
effort to find valid email addresses (for example Git commit data, Jira 
profile, ...).

-- 
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/hMi8XPTfwwQ/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/2B65C30D-C1C1-4D57-8E6F-E93925E9D162%40beckweb.net.
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/11CFAF0E-C91F-4D4C-AA06-1E6F7387AC79%40godaddy.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to join the Security Team

2018-09-06 Thread Jeff Thompson

+1
I would appreciate David’s contributions to the security team.

Jeff Thompson

> On Sep 6, 2018, at 10:44 AM, David Lin  wrote:
> 
> Hello!
> 
> I'm interested in joining the Security Team. I'm an Engineering Manager at 
> CloudBees and have vested interest in the security of Jenkins and it's 
> related items.
> 
> I've enabled 2FA on GitHub - Username: davidbees
> I've signed and added my CLA - https://github.com/jenkinsci/infra-cla/pull/63
> I've registered my Freenode IRC Handle - davidbees
> My Jenkins Community is also davidbees
> 
> I'm looking forward to helping ensure the security process around Jenkins is 
> sound as well as contributing. 
> 
> Thanks!
> 
>  - David
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/f419faa0-96dd-42a9-8f54-cac246fc4dc8%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/f419faa0-96dd-42a9-8f54-cac246fc4dc8%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/359898A7-272D-427A-A491-8D85B8F039EC%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

2018-05-18 Thread Jeff Thompson

I agree on the value of having a version identifier. At some level, there is a 
structure that may change, as anything tends to do over time. Stephen’s 
description of a meta-schema version shows the existence of one such structure.

In my experience there have been times where I created a version identifier for 
something and didn’t end up using it. But I can’t think of an instance where 
keeping that at version 1 was ever a burden. There have been other times where 
I didn’t add a version identifier and later wished I had. And other times where 
I created one that I didn’t know I needed and was later glad I had.

Jeff


> On May 17, 2018, at 5:44 PM, Stephen Connolly 
> <stephen.alan.conno...@gmail.com> wrote:
> 
> But I still think you should include the (let’s invent a different name to 
> show the purpose) meta-schema version
> 
> Most likely the meta-schema version will always be 1, but if you ever need to 
> revise then you will thank Jesse and I for suggesting it.
> 
> CaaC has a schema for generating the schema at runtime... this is the 
> meta-schema... it says things like: Java Maps are represented by , use 
> the @Symbol as a , etc
> 
> That is what the meta-schema version represents. If it changes then you are 
> saying the way of binding between yaml and runtime (in the general sense) has 
> changed.
> 
> On Tue 15 May 2018 at 19:30, nicolas de loof <nicolas.del...@gmail.com 
> <mailto:nicolas.del...@gmail.com>> wrote:
> I've added a section on this topic in JEP-201: 
> https://github.com/jenkinsci/jep/tree/master/jep/201#versioning 
> <https://github.com/jenkinsci/jep/tree/master/jep/201#versioning>
> 
> We can already generate a json-schema you can use to validate your yaml 
> file(s) before applying configuration.
> What you miss is a tool to convert jenkins-core + plugins.spec -> json 
> schema. 
> This is something we could package as well (something comparable to 
> jenkinsfile-runner) or even provide "as a service".
> 
> We could also get such a tool both generate a schema and validate your 
> config, as it seems there's not  (yet) so much text editors to support json 
> schema validation in yaml
> 
> Would this help ?
> 
> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy <ty...@monkeypox.org 
> <mailto:ty...@monkeypox.org>>:
> (replies inline)
> 
> On Tue, 15 May 2018, nicolas de loof wrote:
> 
> > 2018-05-15 0:20 GMT+02:00 Liam Newman <bitwise...@gmail.com 
> > <mailto:bitwise...@gmail.com>>:
> > 
> > >
> > > Putting all that aside (as that is not the original point of this thread),
> > > the original suggestion was to include a version field in the CasC YAML.
> > > You said it would not work because the version would have to take into
> > > account the core version and versions of all plugins, otherwise it might
> > > break. Does that mean the CasC YAML could break _any time_  I upgrade any
> > > component? Doesn't that rather defeats the purpose of CasC?
> > >
> > 
> > Yes indeed. CasC doesn't have it's own model, everything is based on actual
> > java code discovery at runtime. So upgrading core or any plugin is changing
> > this model. CasC targets reproducibility and immutability use-cases. If you
> > want to upgrade anything you need to test it before.
> 
> 
> Testing of changes between plugin versions was something I had great 
> difficulty
> with for Groovy-scripting-based configuration, which was much more common 
> prior
> to Configuration as Code. Do you have suggestions for administrators such as
> myself on how I might validate that my configuration YAML is correct/applies
> between any core or plugin upgrades?
> 
> This gets to the underlying concern I had in mind when starting this thread, 
> as
> an administrator, how will I know that my configuration applies correctly
> between any core or plugin upgrades? My initial thought was schema-versioning,
> but I'm certainly open to other suggestions.
> 
> 
> 
> Cheers
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/20180515181926.GB3395%40grape.lasagna.io
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/20180515181926.GB3395%40grape.lasagna.io>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.co

Request Jenkins security team membership for Jeff Thompson

2018-05-14 Thread Jeff Thompson

I’d like to request to join the Jenkins security team to help review and fix 
security changes and issues. I’m a software engineer at CloudBees and have 
begun contributing to Jenkins projects and plugins. In the past, I’ve worked on 
security issues for a variety of other projects or companies.

Requirements:
2FA at GitHub: yes
ICLA: PR #57 ( https://github.com/jenkinsci/infra-cla/pull/57 
<https://github.com/jenkinsci/infra-cla/pull/57> )
IRC nickname: jeffret-b
GitHub name: jeffret-b
Jenkins community name: jthompson

Thanks

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/BC6C8C3D-7E3C-4A56-88FD-EAD7092C8100%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to join security team

2018-05-14 Thread Jeff Thompson


+1
——

Jeff Thompson
Senior Software Engineer
CloudBees.com

Fort Collins, Colorado
E: jeff.thomp...@cloudbees.com

> On May 14, 2018, at 9:55 AM, Matt Sicker <msic...@cloudbees.com> wrote:
> 
> Hi, I'm interested in joining the security team. I'm a software engineer at 
> CloudBees who is working on some security-related epics. I've got 2FA enabled 
> on GitHub (username: jvz), signed the CLA, and am registered on Freenode 
> (nick: musigma). My Jenkins community username is also jvz.
> 
> As for experience, I've handled or collaborated on several CVEs at the Apache 
> Logging Services and Apache Commons projects.
> 
> -- 
> Matt Sicker
> 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 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz9pfvQivZ2-7EMg%2BkNf0qToF8Aq%3D-kZHb0yhCucz5Ccg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz9pfvQivZ2-7EMg%2BkNf0qToF8Aq%3D-kZHb0yhCucz5Ccg%40mail.gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/54E4FE07-7B50-4E17-8EFD-8D376DDB2CC1%40cloudbees.com.
For more options, visit https://groups.google.com/d/optout.

Re: Starting an asynchronous step

2018-04-08 Thread Jeff Wilson

And it would have to survive a Jenkins restart, I would think.

On Sunday, April 8, 2018 at 12:06:37 PM UTC-4, Jeff Wilson wrote:
>
> Probably I'm using the wrong terminology. I have a long running build 
> action that involves sending commands to a REST API, getting the results, 
> parsing them and writing out artifacts that could be used by a later build 
> step. This step can also break the build based on the output of the REST 
> calls.  Obviously the Jenkinsfile would have to include things like the URI 
> to the REST API and timeouts, etc. I'm simply looking for an example in 
> case I'm missing out on built in functionality of the pipeline APIs, rather 
> than doing the whole thing myself including the multithreading. The Jenkins 
> pipeline APIs are fairly dense and under-documented (IMO), so I'm having a 
> bit of difficulty getting started.
>
> On Friday, April 6, 2018 at 4:56:35 PM UTC-4, Jesse Glick wrote:
>>
>> On Fri, Apr 6, 2018 at 4:48 PM, Jeff Wilson <geek.m...@gmail.com> wrote: 
>> > So, we basically handle our own multi-threading in the start() command, 
>> as 
>> > in this example? 
>>
>> Yes, it is an asynchronous API—the Pipeline runtime tells your step 
>> when to start, and you tell it when it is finished. What you do in the 
>> meantime is your business. Perhaps nothing is happening in Jenkins—you 
>> may simply be passively awaiting a webhook or something. 
>>
>> > Does that change if, within the StepExecution, I want to trigger a 
>> BuildStep 
>> > asynchronously? 
>>
>> I do not think you want to do that. `BuildStep.perform` is synchronous 
>> (blocking). 
>>
>> If the only thing you are doing is calling some synchronous Jenkins 
>> APIs, and you cannot get around that easily, then you probably just 
>> want to extend `SynchronousNonBlockingStepExecution`. The step will 
>> then not survive a Jenkins restart—since the underlying API it is 
>> calling could not either. 
>>
>

-- 
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/c176acfe-b78c-41d8-814c-6cd88e5ae807%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Starting an asynchronous step

2018-04-08 Thread Jeff Wilson

Probably I'm using the wrong terminology. I have a long running build 
action that involves sending commands to a REST API, getting the results, 
parsing them and writing out artifacts that could be used by a later build 
step. This step can also break the build based on the output of the REST 
calls.  Obviously the Jenkinsfile would have to include things like the URI 
to the REST API and timeouts, etc. I'm simply looking for an example in 
case I'm missing out on built in functionality of the pipeline APIs, rather 
than doing the whole thing myself including the multithreading. The Jenkins 
pipeline APIs are fairly dense and under-documented (IMO), so I'm having a 
bit of difficulty getting started.

On Friday, April 6, 2018 at 4:56:35 PM UTC-4, Jesse Glick wrote:
>
> On Fri, Apr 6, 2018 at 4:48 PM, Jeff Wilson <geek.m...@gmail.com 
> > wrote: 
> > So, we basically handle our own multi-threading in the start() command, 
> as 
> > in this example? 
>
> Yes, it is an asynchronous API—the Pipeline runtime tells your step 
> when to start, and you tell it when it is finished. What you do in the 
> meantime is your business. Perhaps nothing is happening in Jenkins—you 
> may simply be passively awaiting a webhook or something. 
>
> > Does that change if, within the StepExecution, I want to trigger a 
> BuildStep 
> > asynchronously? 
>
> I do not think you want to do that. `BuildStep.perform` is synchronous 
> (blocking). 
>
> If the only thing you are doing is calling some synchronous Jenkins 
> APIs, and you cannot get around that easily, then you probably just 
> want to extend `SynchronousNonBlockingStepExecution`. The step will 
> then not survive a Jenkins restart—since the underlying API it is 
> calling could not either. 
>

-- 
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/903db347-bc9e-4c8c-acf7-4ea85bd2010e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Starting an asynchronous step

2018-04-06 Thread Jeff Wilson

In this example, the important parts are in the setUpTimer() method, as are 
as follows:

task = Timer.get().schedule(new Runnable() {
   @Override public void run() {
  getContext().onSuccess(null);
   }
}, end - now, TimeUnit.MILLISECONDS);

So, we basically handle our own multi-threading in the start() command, as 
in this example?

Does that change if, within the StepExecution, I want to trigger a 
BuildStep asynchronously? 



On Friday, April 6, 2018 at 2:57:04 PM UTC-4, Jesse Glick wrote:
>
> On Fri, Apr 6, 2018 at 10:30 AM, Jeff Wilson <geek.m...@gmail.com 
> > wrote: 
> > I can't find a (canonical) example -- does anyone 
> > have a pointer to such? 
>
> The `sleep` step is probably the simplest to understand. The most relevant 
> bits: 
>
>
> https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/7d42af656e09eda765befc8d2267064e1a46a824/src/main/java/org/jenkinsci/plugins/workflow/steps/SleepStep.java#L74-L128
>  
>

-- 
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/a1097dbe-8800-4aeb-aa0f-589bc8f5dfee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Starting an asynchronous step

2018-04-06 Thread Jeff Wilson

Indeed. It simply says to implement the start() method as needed. There are 
no examples of what an implementation might look like, nor is there a 
description/documentation of what to do.

On Friday, April 6, 2018 at 12:12:47 PM UTC-4, Robert Sandell wrote:
>
> Perhaps you've already read this guide? 
> https://github.com/jenkinsci/workflow-step-api-plugin/blob/master/README.md#creating-an-asynchronous-step
>
> /B
>
> 2018-04-06 16:30 GMT+02:00 Jeff Wilson <geek.m...@gmail.com >
> :
>
>> I'm trying to write a new pipeline plugin for a build step that is 
>> long-running and prone to network delays and timeouts, so it would appear 
>> that an asynchronous step is the best way to implement this. However, I 
>> have questions about how to implement the StepExecution.start() method to 
>> start this asynchronous step. I can't find a (canonical) example -- does 
>> anyone have a pointer to such? Alternatively, a good development guide that 
>> shows how to implement this type of step?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/1652f66e-46bc-4d94-8e30-dac8993e817c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/1652f66e-46bc-4d94-8e30-dac8993e817c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> *Robert Sandell*
> Software Engineer
> CloudBees, Inc.
> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
> E: rsan...@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/9702d1d6-e186-4fb3-955b-2a04360c46c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Taking over maintenance for fitnesse plugin

2018-04-06 Thread Jeff Wilson

Michaël,

I am also interested in helping maintain the fitnesse plugin. I'm currently 
looking at what it will take to turn it into a pipeline-aware plugin, but I 
am a neophyte at plugin development. Let me know if you want me to help in 
anyway.

On Monday, March 26, 2018 at 1:47:12 PM UTC-4, Michaël St-Georges wrote:
>
> Hi all,
>
> The fitnesse plugin seems to be dead. There are a few PRs that are pending 
> for quite some time including some that are required to make the plugin 
> work with the current version of Jenkins.
>
> I would like to give a hand by becoming maintainer for this plugin. My 
> github and jenkins infra account is CSLTech.
>
> Sincerely,
> Michaël St-Georges
>

-- 
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/1b269355-dc53-46a7-8f97-ad04c0dafd1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Starting an asynchronous step

2018-04-06 Thread Jeff Wilson

I'm trying to write a new pipeline plugin for a build step that is 
long-running and prone to network delays and timeouts, so it would appear 
that an asynchronous step is the best way to implement this. However, I 
have questions about how to implement the StepExecution.start() method to 
start this asynchronous step. I can't find a (canonical) example -- does 
anyone have a pointer to such? Alternatively, a good development guide that 
shows how to implement this type of step?

-- 
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/1652f66e-46bc-4d94-8e30-dac8993e817c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC] 2018 Student Introduction

2018-03-14 Thread Jeff Knurek

Hello Ibrahim,

Thanks for the interest!
Please see information for students 
<https://jenkins.io/projects/gsoc/students/> for application guidelines.

My recommendation would be to...

   1. Study the existing plugins, try to setup your Jenkins instance with 
   them. It may give you some ideas of what needs to be enhanced there
   2. Take a look at existing plugin issues, for example the Cobertura 
   plugin 
   
<https://issues.jenkins-ci.org/browse/JENKINS-31353?jql=component%20%3D%20%27cobertura-plugin%27%20and%20status%20%3D%20Open%20>

   3. Join one of office hours to discuss the project with them (
   https://jenkins.io/projects/gsoc/#office-hours)
   
Hopefully it helps,
Jeff


On Monday, March 12, 2018 at 1:50:02 AM UTC+1, Ibrahim Abdullah wrote:
>
> Hello,
>
> My name is Ibrahim Abdullah, a final year student at Ashesi University 
> College, Ghana. I am studying computer science and very interested in 
> software development, distributed systems and Machine learning. Java is the 
> main programming language I use for development and have little experience 
> with Jenkins as well. 
>
> I have always wanted to contribute to open source projects to improve my 
> programming skills but find it difficult to start as a newbie. I believe 
> Google Summer of Code will provide the platform and give me a head start to 
> join the open source community. Additionally, I found some of the Jenkins 
> projects exciting to work on given that I have a strong Java background and 
> quite familiar with using Jenkins as a developer. I will like to work on 
> any of the following projects: Jenkins Remoting over Message Bus/Queues, 
> Code Coverage Plugin and Simple pull request Plugin.
>
> The following are the links GutHub and LinkedIn profile;
>
> GitHub : https://github.com/Ibrahim-Abdullah
> LinkedIn : www.linkedin.com/in/ibabdullah
> Twitter: https://twitter.com/braimahabdulla
>
>

-- 
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/a5cfb003-d3e1-47a1-bf0b-713b268e739a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Update Fitnesse plugin to be compatible with Pipeline

2018-03-06 Thread Jeff Wilson

Is anyone working on updating the Fitnesse plugin 
 to be pipeline compatible?

If not, is there a guide for doing such a refactor?

-- 
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/30f957e8-e54d-404f-bcdc-5e5648012727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC: Code Coverage API Plugin

2018-03-06 Thread Jeff Knurek

Hi Sugirjan,

I would recommend taking a look at some of the current existing bugs for 
the Cobertura plugin: 
https://issues.jenkins-ci.org/browse/JENKINS-31353?jql=component%20%3D%20%27cobertura-plugin%27%20and%20status%20%3D%20Open%20
 
and see which ones look easy to fix. From there we can work together to 
help define a Project Proposal on this topic.

There will be office hours on Wednesdays for when this email channel isn't 
helpful enough: https://jenkins.io/projects/gsoc/#office-hours

Thank you,
Jeff K

On Monday, March 5, 2018 at 2:45:49 PM UTC+1, sugir...@cse.mrt.ac.lk wrote:
>
> Hi,
>
> I'm Sugirjan, final year undergraduate student from Computer Science and 
> Engineering Department, University of Moratuwa, Sri Lanka. I wish to 
> contribute to this 'Code Coverage API Plugin' project. Can you give some 
> guidelines for starting to work on this project?
>
> Thank you.
>
> Regards,
> R. Sugirjan
> *CSE,*
> *University Of Moratuwa.*
> *linkedIn: https://www.linkedin.com/in/sugirjan/ 
> <https://www.linkedin.com/in/sugirjan/>*
>
>
>
>

-- 
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/c3a14496-6f6b-4b85-9e27-959c64a2e3d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with jenkinsci failure

2017-11-09 Thread Jeff Pearce

Yeah, that's why I wonder if it's infra related (out of disk space, 
network). I can download the bad larry locally. I can also try upgrading 
the base jenkins version 

Is it possible to trigger a new build without pushing changes?

On Thursday, November 9, 2017 at 3:18:36 PM UTC-8, Jeff Pearce wrote:
>
> The ci.jenkins.io build for one of the plugins I maintain seems like it's 
> failing with an infrastructure issue. Would anyone who knows more take a 
> quick peek and see if the error rings any bells? Builds fine locally.
>
>
> https://ci.jenkins.io/job/Plugins/job/cobertura-plugin/job/builderror/5/consoleFull
>
> *8:25:22* [linux-8]
>> *18:25:22* [linux-8] 
>> ---
>> *18:25:22* [linux-8] T E S T S
>> *18:25:22* [linux-8] 
>> ---
>> *18:25:22* [linux-8] Running 
>> CoverageTablePortlet.CoverageTablePortletTest
>> *18:25:24* [linux-8] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, 
>> Time elapsed: 1.486 sec <<< FAILURE!
>> *18:25:24* [linux-8] 
>> testBuildUrlShouldBeCorrectInFolder(CoverageTablePortlet.CoverageTablePortletTest)
>>  
>> Time elapsed: 0.897 sec <<< ERROR!
>> *18:25:24* [linux-8] java.lang.Exception: Failed to initialize exploded 
>> war
>
>
>

-- 
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/074af22a-a708-4ede-b38e-189c28e3fb12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help with jenkinsci failure

2017-11-09 Thread Jeff Pearce

The ci.jenkins.io build for one of the plugins I maintain seems like it's 
failing with an infrastructure issue. Would anyone who knows more take a 
quick peek and see if the error rings any bells? Builds fine locally.

https://ci.jenkins.io/job/Plugins/job/cobertura-plugin/job/builderror/5/consoleFull

*8:25:22* [linux-8]
> *18:25:22* [linux-8] 
> ---
> *18:25:22* [linux-8] T E S T S
> *18:25:22* [linux-8] 
> ---
> *18:25:22* [linux-8] Running CoverageTablePortlet.CoverageTablePortletTest
> *18:25:24* [linux-8] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, 
> Time elapsed: 1.486 sec <<< FAILURE!
> *18:25:24* [linux-8] 
> testBuildUrlShouldBeCorrectInFolder(CoverageTablePortlet.CoverageTablePortletTest)
>  
> Time elapsed: 0.897 sec <<< ERROR!
> *18:25:24* [linux-8] java.lang.Exception: Failed to initialize exploded 
> war


-- 
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/b4e3275d-a1c8-40fa-a43c-2c8e4c9393e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adoption Requests

2017-11-09 Thread Jeff Pearce

Pretty sure you just need to follow the instructions 
here https://github.com/jenkins-infra/repository-permissions-updater

On Wednesday, November 8, 2017 at 9:25:27 AM UTC-8, Experimental Insanity 
wrote:
>
> Jenkins Team,
>
>  
>
> I would like to be the maintainer for the following Jenkins Plugins.  Both 
> are currently listed as available for adoption.
>
>  
>
> GitHub ID: experimentalinsanity (https://github.com/experimentalinsanity)
>
> Jenkins Infrastructure Account ID: wulfgar61
>
>  
>
> ArtifactDeployer Plugin 
>  — This 
> plugin makes it possible to copy artifacts to remote locations.
>
>  
>
> Open Adoption Request: 
> https://github.com/jenkinsci/artifactdeployer-plugin/pull/12
>
>  
>
> Copy To Slave Plugin 
>  — This 
> plugin allows to copy a set of files, from a location somewhere on the 
> master node, to jobs' workspaces. It also allows to copy files back from 
> the workspaces of jobs located on a slave node to their workspaces on the 
> master one.
>
>  
>
> Open Adoption Request: 
> https://github.com/jenkinsci/copy-to-slave-plugin/pull/7
>
>  
>
> Thanks,
>
> JD
>
>  
>
>
>
> *
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. 
> If you are not the named addressee you should not disseminate, distribute 
> or copy this e-mail. Please notify the sender immediately by e-mail if you 
> have received this e-mail by mistake and delete this e-mail from your 
> system. Please note that any views or opinions presented in this email are 
> solely those of the author and do not necessarily represent those of the 
> sender of the e-mail. The sender of the e-mail accepts no liability for any 
> damage caused by any virus transmitted by this email. (IP)
>
> *
>

-- 
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/9bb1a5bf-7b28-453d-a551-41a0dd5a2273%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Adoption Requests

2017-11-08 Thread Jeff DeFauw

Jenkins Team,

I would like to be the maintainer for the following Jenkins Plugins. Both are
currently listed as available for adoption.

GitHub ID: experimentalinsanity (https://github.com/experimentalinsanity)
Jenkins Infrastructure Account ID: wulfgar61

ArtifactDeployer
Plugin - This
plugin makes it possible to copy artifacts to remote locations.

Open Adoption Request:
https://github.com/jenkinsci/artifactdeployer-plugin/pull/12

Copy To Slave
Plugin - This
plugin allows to copy a set of files, from a location somewhere on the master
node, to jobs' workspaces. It also allows to copy files back from the
workspaces of jobs located on a slave node to their workspaces on the master
one.

Open Adoption Request: https://github.com/jenkinsci/copy-to-slave-plugin/pull/7

Thanks,
JD

*
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the named addressee you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately by e-mail if you have
received this e-mail by mistake and delete this e-mail from your system. Please
note that any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the sender of the e-mail. The
sender of the e-mail accepts no liability for any damage caused by any virus
transmitted by this email. (IP)
*

--
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/f3d25f364ac14cac8e158c9b3d03f421%40CHR2PR1EX63.chrobinson.com.
For more options, visit https://groups.google.com/d/optout.

1 2 >

1 - 100 of 141 matches

Mail list logo