Renaming Jenkins Essentials to 'Evergreen'

[R. Tyler Croy]

I wanted to send an broader email to the dev list indicating that I will be
changing the name of what we have thus far referred to as "Jenkins Essentials"
to "Evergreen." The latter has been the name of the distribution system since
day one, and as we near completion on "Milestone 1", which will be useable by
actual people, I wanted to fix the name to ensure that what "it" is, is clear
and understandable.


Since the early days, "Essentials" has unfortunately been a bit of a confusing
name for some folks. It tended to be related to the "Suggested Plugins" feature
far more than I had ever wanted. The key aspect of it is _not_ the selection of
plugins, but rather how those plugins get out there to users.


>From my perspective, the always-automatically-up-to-date distribution aspect of
what we've built, *that* is the key take-away.


Evergreen captures that promise _far_ better in my opinion.

(with a nice hat-tip towards Green Balls and Blue Ocean's green status
indicator :))


The four pillars remain the same, but the key premise of Evergreen is being
highlighted much more with this change.


>From a practical standpoint, I will be submitting updates to the JEPs we have
written thus far, add an update note to old blog posts, and post an blog post
explaining what Jenkins Evergreen (nee Essentials) is and how to use it as of
Milestone 1 (:clap:).




Let me know if you've got any questions, and of course, I look forward to
chatting with many of you about Evergreen at DevOps World - Jenkins World San
Francisco coming up soon :D


Cheers
-R Tyler Croy

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


signature.asc
Description: PGP signature

Re: What's the api to fail a build

[Jesse Glick]

On Tue, Aug 14, 2018 at 11:43 AM Michael Fowler
 wrote:
> FATAL: execution failed

I do not recognize where this message line is coming from.

Throwing an `AbortException` is the correct response to a foreseeable,
user-level error condition. It should not be displayed as a stack
trace.

>From a full-text search of @jenkinsci I would look first at

https://github.com/jenkinsci/windows-exe-runner-plugin/blob/813facfd3b4482ddd7492e0c904c957e18a45257/src/main/java/org/jenkinsci/plugins/windows_exe_runner/ExeBuilder.java#L244

which appears wrong. All the `catch` blocks (lines 242, 246, and 254)
should be deleted.

If you are working on some other code and still having problems,
narrow down your issue to a minimal reproducible test case (e.g., a
small plugin adding a Pipeline step) and file a bug report.

-- 
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/CANfRfr21zjLF5%3DdwTXQj2ye%2B1tHs3m%2B90mr6JRYjymnWK5enYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Docker Swarm plugin evolutions

[Gabriel Augendre]

Hi Baptiste,
I don't know the implications of becoming a maintainer and I don't have a 
lot of time to offer to this plugin since I work on something else now, but 
if you feel that would work why not !

Le mardi 14 août 2018 17:56:23 UTC+2, Baptiste Mathus a écrit :
>
> Hello Gabriel,
> Did you consider adopting this plugin and take over its maintenance? 
> Didn't check for that plugin, but if you didn't get an answer since long, 
> then maybe it's time to start the process.
>
> Cheers
>
> Le mar. 14 août 2018 à 14:44, Gabriel Augendre  > a écrit :
>
>> Hello,
>>
>> I made several changes to the Docker Swarm plugin (
>> https://github.com/jenkinsci/docker-swarm-plugin) and proposed them as 
>> pull requests.
>>
>> However I didn’t get an answer one month after contacting the original 
>> author.
>>
>> Please note that I have an integration branch where all features that I 
>> separately proposed as PRs are merged into one branch, compatible with 
>> master.
>>
>>  
>>
>> I’m not familiar with the Jenkins organization, so if I’m not posting 
>> this in the right place, please feel free to redirect me.
>>
>>
>> Thanks !
>>
>> Gabriel
>>
>> -- 
>> 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/73fbc475-2c02-43d6-82e6-e7dbb03b227d%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/072c3542-963b-42e8-89c9-c9cd1f4d6447%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopting jUnit Attachments Plugin

[Oleg Nenashev]

I agree with Alex. I believe that plugin maintainers should be default
assignees.
Maintainers should be triaging the issues, verifying their validity and
then unassigning themselves when they do not plan to work on them.

Otherwise we get to the case when many issues are invalid or mis-reported.
And it causes lot of problems:

   - People get discouraged, as Alex mentioned. When a user reports an
   issue, he is likely expecting some kind of response (at least acknoldgement)
   - Potential plugin contributors/adopters get lost in the tons of BS
   reports in JIRA, which have never been triaged
   - People do mess up components a lot, things like jenkins-* and pipeline
   are affected a lot

Alternative way would be to get all issues reported to the "_unsorted"
component by common users (so a limited number of users can report to
components directly). In such case a team of reviewers could be triaging
issues and providing a first response. It would also help maintainers to
work effectively instead of spending much time on invalid reports. Many
projects use "_unsorted"-alike components in their trackers.

We have it as well, and I triage reports there. But it does not really work
well when people report issues randomly. Nowadays I take a look at the
entire list of incoming issues (on a ~daily basis). If we had a number of
JIRA reviewers (e.g. 3-4 people), we could really change the model in JIRA
and prevent random reporting at all. If there is somebody interested, I
could create a writeup for such conversion in JIRA model.

BR, Oleg


On Tue, Aug 14, 2018 at 6:10 PM Peter John Hampton <
peterjohn.hamp...@gmail.com> wrote:

> I also disagree. I reckon the best way is to assign the maintainer
> (however, this word seems rather loaded in Jenkins world). If the assignee
> doesn’t want to work on it for whatever reason they could free it up by
> unassigning and labelling the issue appropriately.
>
> This seems like a separate discussion though.
>
> On 14 Aug 2018, at 16:59, Slide  wrote:
>
> I somewhat disagree with this, as I generally only see emails about issues
> if I am assigned to it (maybe my settings are setup incorrectly
> somewhere?). If I don't get emails, the issue will sit without me looking
> at it for a fairly long period of time, which means the person could get
> discouraged in that case as well since no one sees the issue.
>
> On Tue, Aug 14, 2018 at 8:56 AM Baptiste Mathus  wrote:
>
>>
>>
>> Le jeu. 9 août 2018 à 23:47, Jesse Glick  a écrit :
>>
>>> On Thu, Aug 9, 2018 at 12:57 PM Oleg Nenashev 
>>> wrote:
>>> > Should I also change the default assignee in JIRA?
>>>
>>> I have no opinion about that. Generally I find the default assignee
>>> option to be a bad idea—you should assign an issue to yourself if and
>>> when you plan to actually work on it, or someone has a specific reason
>>> to think you are the one who _should_ work on it (for example because
>>> you introduced a regression). If a plugin has only ever had one
>>> maintainer, maybe it makes sense to just assume that any newly filed
>>> issue is going to be handled by them or not at all.
>>>
>>
>> +1. I think there should not be a default assignee. It conveys the wrong
>> message:
>> * That the assignee is going to look into the issue
>> * It probably hence discourages some people to try and propose a fix when
>> they see someone is already working on it (they think)
>>
>>
>>> --
>>> 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/CANfRfr2hAyfHmpmJZwv_EAJoECZM8HxYx17eAvJJgcQ10A%3Dscw%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/CANWgJS6W3t%2BEdqVY%3Dz3gvwMkq1LYk%3DXDoEM6gmW5mVGGGnSfhA%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/CAPiUgVcqpRRwP9_XCA%2B8KMBmPmRErS5ZgErYPd5s6OBhESrhDw%40mail.gmail.com
> 

Re: Adopting jUnit Attachments Plugin

[Peter John Hampton]

I also disagree. I reckon the best way is to assign the maintainer (however, 
this word seems rather loaded in Jenkins world). If the assignee doesn’t want 
to work on it for whatever reason they could free it up by unassigning and 
labelling the issue appropriately.

This seems like a separate discussion though. 

> On 14 Aug 2018, at 16:59, Slide  wrote:
> 
> I somewhat disagree with this, as I generally only see emails about issues if 
> I am assigned to it (maybe my settings are setup incorrectly somewhere?). If 
> I don't get emails, the issue will sit without me looking at it for a fairly 
> long period of time, which means the person could get discouraged in that 
> case as well since no one sees the issue.
> 
>> On Tue, Aug 14, 2018 at 8:56 AM Baptiste Mathus  wrote:
>> 
>> 
>>> Le jeu. 9 août 2018 à 23:47, Jesse Glick  a écrit :
>>> On Thu, Aug 9, 2018 at 12:57 PM Oleg Nenashev  
>>> wrote:
>>> > Should I also change the default assignee in JIRA?
>>> 
>>> I have no opinion about that. Generally I find the default assignee
>>> option to be a bad idea—you should assign an issue to yourself if and
>>> when you plan to actually work on it, or someone has a specific reason
>>> to think you are the one who _should_ work on it (for example because
>>> you introduced a regression). If a plugin has only ever had one
>>> maintainer, maybe it makes sense to just assume that any newly filed
>>> issue is going to be handled by them or not at all.
>> 
>> 
>> +1. I think there should not be a default assignee. It conveys the wrong 
>> message:
>> * That the assignee is going to look into the issue
>> * It probably hence discourages some people to try and propose a fix when 
>> they see someone is already working on it (they think)
>> 
>>> 
>>> -- 
>>> 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/CANfRfr2hAyfHmpmJZwv_EAJoECZM8HxYx17eAvJJgcQ10A%3Dscw%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/CANWgJS6W3t%2BEdqVY%3Dz3gvwMkq1LYk%3DXDoEM6gmW5mVGGGnSfhA%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/CAPiUgVcqpRRwP9_XCA%2B8KMBmPmRErS5ZgErYPd5s6OBhESrhDw%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/5C1DA500-5BDC-4516-802B-5915D55A139C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopting jUnit Attachments Plugin

[Slide]

I somewhat disagree with this, as I generally only see emails about issues
if I am assigned to it (maybe my settings are setup incorrectly
somewhere?). If I don't get emails, the issue will sit without me looking
at it for a fairly long period of time, which means the person could get
discouraged in that case as well since no one sees the issue.

On Tue, Aug 14, 2018 at 8:56 AM Baptiste Mathus  wrote:

>
>
> Le jeu. 9 août 2018 à 23:47, Jesse Glick  a écrit :
>
>> On Thu, Aug 9, 2018 at 12:57 PM Oleg Nenashev 
>> wrote:
>> > Should I also change the default assignee in JIRA?
>>
>> I have no opinion about that. Generally I find the default assignee
>> option to be a bad idea—you should assign an issue to yourself if and
>> when you plan to actually work on it, or someone has a specific reason
>> to think you are the one who _should_ work on it (for example because
>> you introduced a regression). If a plugin has only ever had one
>> maintainer, maybe it makes sense to just assume that any newly filed
>> issue is going to be handled by them or not at all.
>>
>
> +1. I think there should not be a default assignee. It conveys the wrong
> message:
> * That the assignee is going to look into the issue
> * It probably hence discourages some people to try and propose a fix when
> they see someone is already working on it (they think)
>
>
>> --
>> 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/CANfRfr2hAyfHmpmJZwv_EAJoECZM8HxYx17eAvJJgcQ10A%3Dscw%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/CANWgJS6W3t%2BEdqVY%3Dz3gvwMkq1LYk%3DXDoEM6gmW5mVGGGnSfhA%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/CAPiUgVcqpRRwP9_XCA%2B8KMBmPmRErS5ZgErYPd5s6OBhESrhDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hangouts Chat Plugin

[Baptiste Mathus]

Hey folks,

If, as you seem to, would like your work to get a bigger audience, you
probably want to look into how to host it under the official Jenkins update
center.

We generally kindly ask people to do a best effort to add features to
existing plugins, but in case this proves impractical, we can still host
'competing' plugins.

Cheers


Le ven. 10 août 2018 à 19:01, André Eickler 
a écrit :

> Hi Mehmet,
>
> same here: https://bitbucket.org/eickler/hangouts-chat :-)
>
> You can use it also from Pipelines as step and it sends aggregated error
> reports from JUnit(-derivatives), Cucumber and Maven. Maybe throw things
> together?
>
> Btw. I am currently struggling with the Jenkins test harness. I would like
> to inject mock hangouts communication instead of the real communication
> with the Google API. That works fine with the Notifier, but it doesn't seem
> to work with the Step. I also do not know how to interfere with this from
> my test case, because Pipelines probably instantiates the Step from the
> script.
>
> Any hint on how to do that? My feeble attempts at
> https://bitbucket.org/eickler/hangouts-chat/src/99d45946ae0098e520a1a84850e28f7df25e5cfb/src/test/java/c8y/jenkins/hangouts/RunReporter2Test.java?at=default=file-view-default
> ...
>
> Cheers,
> André
>
> On Tuesday, 7 August 2018 13:52:54 UTC+2, Mehmet Salim Ayan wrote:
>>
>> Hello Jenkins CI Dev Team,
>>
>> We currently work on a plugin for Hangouts Chat. It works just like Slack
>> Notification Plugin.
>> You can check our plugin with this link(
>> https://github.com/general-mobile/jenkins-hangout-chat-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/55dd4057-eec1-42b0-b040-758be760ddeb%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

Le 10 août 2018 19:01, "André Eickler"  a
écrit :

Hi Mehmet,

same here: https://bitbucket.org/eickler/hangouts-chat :-)

You can use it also from Pipelines as step and it sends aggregated error
reports from JUnit(-derivatives), Cucumber and Maven. Maybe throw things
together?

Btw. I am currently struggling with the Jenkins test harness. I would like
to inject mock hangouts communication instead of the real communication
with the Google API. That works fine with the Notifier, but it doesn't seem
to work with the Step. I also do not know how to interfere with this from
my test case, because Pipelines probably instantiates the Step from the
script.

Any hint on how to do that? My feeble attempts at
https://bitbucket.org/eickler/hangouts-chat/src/99d45946ae0098e520a1a84850e28f7df25e5cfb/src/test/java/c8y/jenkins/hangouts/RunReporter2Test.java?at=default=file-view-default
...

Cheers,
André

On Tuesday, 7 August 2018 13:52:54 UTC+2, Mehmet Salim Ayan wrote:
>
> Hello Jenkins CI Dev Team,
>
> We currently work on a plugin for Hangouts Chat. It works just like Slack
> Notification Plugin.
> You can check our plugin with this link(
> https://github.com/general-mobile/jenkins-hangout-chat-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/55dd4057-eec1-42b0-b040-758be760ddeb%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/CANWgJS4XPhFLzPzdiMLJSJynnvu_W2_%3DZqj3zNoeHcC8UgiCdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopting jUnit Attachments Plugin

[Baptiste Mathus]

Le jeu. 9 août 2018 à 23:47, Jesse Glick  a écrit :

> On Thu, Aug 9, 2018 at 12:57 PM Oleg Nenashev 
> wrote:
> > Should I also change the default assignee in JIRA?
>
> I have no opinion about that. Generally I find the default assignee
> option to be a bad idea—you should assign an issue to yourself if and
> when you plan to actually work on it, or someone has a specific reason
> to think you are the one who _should_ work on it (for example because
> you introduced a regression). If a plugin has only ever had one
> maintainer, maybe it makes sense to just assume that any newly filed
> issue is going to be handled by them or not at all.
>

+1. I think there should not be a default assignee. It conveys the wrong
message:
* That the assignee is going to look into the issue
* It probably hence discourages some people to try and propose a fix when
they see someone is already working on it (they think)


> --
> 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/CANfRfr2hAyfHmpmJZwv_EAJoECZM8HxYx17eAvJJgcQ10A%3Dscw%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/CANWgJS6W3t%2BEdqVY%3Dz3gvwMkq1LYk%3DXDoEM6gmW5mVGGGnSfhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Driver Uploader Plugin

[Baptiste Mathus]

Hello,

You can file an issue in the Jenkins jira for this purpose. In the
'HOSTING' project.

Google for "Jenkins hosting plugin" to find the associated docs on the wiki.

Cheers!

Le mer. 8 août 2018 à 18:48, Mustafa Kuloglu <
mustafa.kulo...@generalmobile.com> a écrit :

> Hi,
> Of course we are interested. Thank you for your interest.
>
> BR,
> Mustafa.
>
> 8 Ağustos 2018 Çarşamba 15:40:37 UTC+3 tarihinde Oleg Nenashev yazdı:
>>
>> Hi,
>>
>> Would you be interested to host this (and the Google Hangouts) plugin in
>> Jenkins Update Centers?
>>
>> Best reagrds,
>> Oleg
>>
>> On Wednesday, August 8, 2018 at 2:00:46 PM UTC+2, Mustafa Kuloglu wrote:
>>>
>>> Hello Jenkins CI Dev Team,
>>>
>>> We currently work on a plugin for Google Drive upload.
>>> You can check our plugin with this link(
>>> https://github.com/general-mobile/jenkins-google-drive-uploader).
>>>
>>> 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/8e029a82-4830-4ad7-bacc-edfa682bfc40%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/CANWgJS6QJKDtwDfGZsPQ-q4fbcJksNRyf81KeVx%2BWFugyWAk0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Docker Swarm plugin evolutions

[Baptiste Mathus]

Hello Gabriel,
Did you consider adopting this plugin and take over its maintenance? Didn't
check for that plugin, but if you didn't get an answer since long, then
maybe it's time to start the process.

Cheers

Le mar. 14 août 2018 à 14:44, Gabriel Augendre  a
écrit :

> Hello,
>
> I made several changes to the Docker Swarm plugin (
> https://github.com/jenkinsci/docker-swarm-plugin) and proposed them as
> pull requests.
>
> However I didn’t get an answer one month after contacting the original
> author.
>
> Please note that I have an integration branch where all features that I
> separately proposed as PRs are merged into one branch, compatible with
> master.
>
>
>
> I’m not familiar with the Jenkins organization, so if I’m not posting this
> in the right place, please feel free to redirect me.
>
>
> Thanks !
>
> Gabriel
>
> --
> 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/73fbc475-2c02-43d6-82e6-e7dbb03b227d%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/CANWgJS5LnUZS3wTk9CjrtfVuePCU9AcSLBSXOQrA-8PX9aGVOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bill of Materials

[Oleg Nenashev]

Thanks for the update, Tyler!


On Tue, Aug 14, 2018 at 5:38 PM R. Tyler Croy  wrote:

> (replies inline)
>
> On Tue, 07 Aug 2018, Oleg Nenashev wrote:
>
> > Hi Tyler,
> >
> > Thanks for the feedback!
> >
> >
> > > I believe the only think which needs to be resolved which is likely
> just an
> > > obsolete part of the example YAML.  The root `status` key in the YAML
> for a
> > > "realized" BOM I don't believe we've ever actually used and is worth
> > > removing.
> >
> >
> > Actually I use it in some cases in order to implement custom packaging
> > Pipelines after customWARPackager()
> > <
> https://github.com/jenkins-infra/pipeline-library/blob/master/vars/customWARPackager.groovy
> >.
> >
> >
> >- BOM's specification lists explicit dependencies
> >- BOM's specification does not require all dependencies to be explicit
> >   - Some dependencies may have "dir" references
> >   - Some dependencies may be transitive. JEP-309 permits that though
> >   does not recommend for production use (dependency resolution
> >   <
> https://github.com/jenkinsci/jep/tree/master/jep/309#dependency-resolution
> >
> >   in the spec)
> >   - "status" key returns the full list of resolved dependencies
> >   - In addition to transitive deps, CWP uses "status" to squash the
> >   "environment" definitions into a single list in order to show what
> was
> >   actually packaged into the WAR file
> >
> > I would rather prefer the "status" section to stay in the specification.
> It
> > is helpful for CWP at least (though it may be possible to just generate a
> > new output BOM). If we do that, it would be nice to get feedback from
> Raul
> > who is also experimenting with processing of BOMs.
> >
> > In order to address your comment, we could explicitly say that the
> "status"
> > section is optional so that you do not need to implement it in Evergreen
> if
> > not needed. WDYT?
>
>
>
> I mentioned in a video call with Oleg this morning that I've gone ahead and
> implemented the `status` section for the  Bill of Materials being used in
> the
> jenkins-infra/evergreen repository.
>
>
> Overall I'm quite happy with this work by Oleg and Carlos, and I will be
> submitting a PR (with my BDFL-Delegate hat on) to mark JEP-309 as
> 'Accepted'
> later today.
>
>
> Thanks for the  hard work everybody!
>
> --
> 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/pR2ZQMj95Zc/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/20180814153826.GH17800%40grape.lasagna.io
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Bill of Materials

[R. Tyler Croy]

(replies inline)

On Tue, 07 Aug 2018, Oleg Nenashev wrote:

> Hi Tyler,
> 
> Thanks for the feedback!
> 
> 
> > I believe the only think which needs to be resolved which is likely just an
> > obsolete part of the example YAML.  The root `status` key in the YAML for a
> > "realized" BOM I don't believe we've ever actually used and is worth
> > removing.
> 
> 
> Actually I use it in some cases in order to implement custom packaging
> Pipelines after customWARPackager()
> .
> 
> 
>- BOM's specification lists explicit dependencies
>- BOM's specification does not require all dependencies to be explicit
>   - Some dependencies may have "dir" references
>   - Some dependencies may be transitive. JEP-309 permits that though
>   does not recommend for production use (dependency resolution
>   
> 
>   in the spec)
>   - "status" key returns the full list of resolved dependencies
>   - In addition to transitive deps, CWP uses "status" to squash the
>   "environment" definitions into a single list in order to show what was
>   actually packaged into the WAR file
> 
> I would rather prefer the "status" section to stay in the specification. It
> is helpful for CWP at least (though it may be possible to just generate a
> new output BOM). If we do that, it would be nice to get feedback from Raul
> who is also experimenting with processing of BOMs.
> 
> In order to address your comment, we could explicitly say that the "status"
> section is optional so that you do not need to implement it in Evergreen if
> not needed. WDYT?



I mentioned in a video call with Oleg this morning that I've gone ahead and
implemented the `status` section for the  Bill of Materials being used in the
jenkins-infra/evergreen repository.


Overall I'm quite happy with this work by Oleg and Carlos, and I will be
submitting a PR (with my BDFL-Delegate hat on) to mark JEP-309 as 'Accepted'
later today.


Thanks for the  hard work everybody!

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


signature.asc
Description: PGP signature

Re: [bulk-builder-plugin] follow up on pull request

[hugo . boog]

Hi Oleg,

I just created a Jenkins JIRA ID: Alien_Fromspace
My Github account: alienfs

Kind regards,

Hugo Boog

Op zaterdag 11 augustus 2018 15:57:57 UTC+2 schreef Oleg Nenashev:
>
> Hi Hugo,
>
> In order to complete ownership transfer, we need your GitHub and Jenkins 
> JIRA IDs.
>
> Thanks in advance,
> Oleg
>
> On Tuesday, July 31, 2018 at 5:38:42 PM UTC+2, Simon Westcott wrote:
>>
>>
>>
>> On Thursday, 26 July 2018 00:04:39 UTC+1, Daniel Beck wrote:
>>>
>>>
>>> > On 25. Jul 2018, at 15:52, hugo...@gmail.com wrote: 
>>> > 
>>> > I have contacted the original author and unfortunately he can no 
>>> longer access the repo anymore.I 
>>>
>>> Please have them file in iNFRA issue in our Jira for the 'github' 
>>> component. This can also be used to request that you be granted access. If 
>>> they're still around, this is the cleanest solution. 
>>>
>>>
>> Hey, I'm the original plugin author. I've raised 
>> https://issues.jenkins-ci.org/browse/INFRA-1731.
>>
>

-- 
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/833f0e25-669c-496f-b026-4a892afb2b65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Growing community via a stronger Twitter presence

[Tracy Miranda]

Thanks Tyler, Daniel & Mark for the feedback so far.

I've updated the JEP based on this:
https://github.com/jenkinsci/jep/pull/176

Please review and let me know any further thoughts.

Tracy

On Mon, Aug 13, 2018 at 8:22 PM, R. Tyler Croy  wrote:

>
> Following up on this thread, Tracy's taken the initiative to create a good
> JEP
> describing the proposed process here:
> https://github.com/jenkinsci/jep/pull/175
>
>
> As the primary poster of @jenkinsci, I'm really looking forward to sharing
> some
> responsibilities with other passionate twitter/jenkins contributors :)
>
>
>
>
>
> --
> 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/20180813192211.GG17800%40grape.lasagna.io.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Get current git branch in plugin securely

[Daniel Beck]

> On 12. Aug 2018, at 13:40, Dário Nascimento  wrote:
> 
> I want to execute a plugin using Jenkinsfile pipeline and I want that plugin 
> to have the context (branch & job) without user interference. This plugin 
> generates a token identifying the job so we can authenticate with other 
> services.
> If I allow users to set the branch as env var, then the token content is 
> compromised and my plugin is insecure. This is critical to developing a 
> secure self-service CI/CD. How can I do it?
> 

https://jenkins.io/blog/2018/05/15/incremental-deployment/ might help 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/CA5FBA4D-822D-4F40-8800-1B52A355BD54%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Chinese Localization SIG

[xuesea]

I am using Jenkins for my works every day and searching the documentation 
from jenkins.io. I also use Kubernetes to handle some work, and it provides 
the multi-language version including Chinese, that is very nice. Found this 
topic and interested in this proposal, hope this proposal can 
be implemented quickly.

-- 
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/0bbcf32c-c3a7-43bc-9170-99fda2d1c215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Docker Swarm plugin evolutions

[Gabriel Augendre]

 

Hello,

I made several changes to the Docker Swarm plugin (
https://github.com/jenkinsci/docker-swarm-plugin) and proposed them as pull 
requests.

However I didn’t get an answer one month after contacting the original 
author.

Please note that I have an integration branch where all features that I 
separately proposed as PRs are merged into one branch, compatible with 
master.

 

I’m not familiar with the Jenkins organization, so if I’m not posting this 
in the right place, please feel free to redirect me.


Thanks !

Gabriel

-- 
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/73fbc475-2c02-43d6-82e6-e7dbb03b227d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Get current git branch in plugin securely

[Dário Nascimento]

Hi,

I want to execute a plugin using Jenkinsfile pipeline and I want that
plugin to have the context (branch & job) without user interference. This
plugin generates a token identifying the job so we can authenticate with
other services.
If I allow users to set the branch as env var, then the token content is
compromised and my plugin is insecure. This is critical to developing a
secure self-service CI/CD. How can I do it?

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/CAMa-MX%2Bs-jhngF%2BWBvVd--gsg_KOUUDU%2BgLj5RLOU%3D%2Bg4Gp%3D3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What's the api to fail a build

[Daniel Beck]

> On 14. Aug 2018, at 05:34, Michael Fowler  wrote:
> 
>  It's in a pipeline. No exception was thrown, that line was removed. The 
> pipeline stopped on the next line. I checked the source for that plugin, it 
> throws an exception. There's got to be a better way than having a stack trace 
> in the build log.

Oops -- read the diff the wrong way, since throwing AbortException is the 
recommended way to do something like this. Could you provide more context about 
the stack trace?


-- 
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/C18B5A57-A565-46A6-B951-230747192FB2%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.