Re: Artifactory Problems?

[slide]

Hi,

I just cloned the repo, ran mvn clean package and I did not see the error 
you are seeing. Here is my settings.xml

http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
http://maven.apache.org/xsd/settings-1.0.0.xsd;>

  

  maven.jenkins-ci.org
  slide_o_mix
  

  
  

  repo.jenkins-ci.org
  *,!repo.jenkins-ci.org,!incrementals
  https://repo.jenkins-ci.org/public/

  
  
org.jenkins-ci.tools
  
  


  jenkins
  
true
  
  

  repo.jenkins-ci.org
  https://repo.jenkins-ci.org/public/

  
  

  repo.jenkins-ci.org
  https://repo.jenkins-ci.org/public/

  

  



On Thursday, October 20, 2022 at 3:40:00 PM UTC-7 nowak.b...@gmail.com 
wrote:

> Hi,
>
> I'm still fighting with this problem.
> I think it's not a settings.xml fault, because it happens on Jenkins CI 
> infra too.
>
> https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fcrowd2-plugin/detail/master/177/pipeline/63
>
> I use standard settings.xml, fetched with curl from artifactory.
> I noticed that this error disappeared when I'm setting a default profile 
> in settings.xml.
> I guess it's my pom.xml fault.
> I would be grateful if somebody could take a look on it and give me some 
> advice what i did wrong.
>
> Thanks
>
> środa, 28 września 2022 o 16:07:18 UTC+2 db...@cloudbees.com napisał(a):
>
>> On Wed, Sep 28, 2022 at 3:21 PM DuMaM  wrote:
>>
>>>
>>> Could you share sample of correct settings.xml file so i can compare it?
>>>
>>
>> The linked documentation has two complete examples of the settings.xml 
>> file you need (just needs replacing username/password entries as 
>> appropriate).
>>
>

-- 
You received this message because you 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/0c547324-e52e-44dd-accb-818eed40904cn%40googlegroups.com.

Fwd: WMI Windows Agents plugin

[slide]

Cross posting to the dev group to see if there is any feedback there.

-- Forwarded message -
From: slide 
Date: Friday, May 6, 2022 at 3:13:33 PM UTC-7
Subject: WMI Windows Agents plugin
To: Jenkins User Mailing List 


Hi Everyone,

The WMI Windows Agents plugin uses a library called j-interop. This library 
was last released in 2010. Microsoft has made some changes to the DCOM 
protocol since this time. One particular change is highlighted in 
https://issues.jenkins.io/browse/JENKINS-67604, currently you can override 
this behavior in the registry, but in March of 2023, that will no longer be 
possible. This means that the WMI Windows Agent plugin may become unusable, 
unless someone who knows enough about DCOM internals can update j-interop 
with support for the new features (j-interop supports DCOM 5.4, the current 
version is 5.7 and has several additions/changes). With Windows Server 2019 
and Windows 10, SSH is a viable option for Windows agents.

I would like to recommend deprecating the WMI Windows Agents plugin by 
March 2023. I think this gives enough time for people to migrate to either 
SSH or the Windows Cloud plugin (which uses a more modern remote management 
interface, WinRM). Basically this would mean the option to "Let Jenkins 
control this Windows agent as a Windows service" would no longer be 
available. 

Any thoughts on this? 

Regards,

Alex

-- 
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/8f36cc54-7fe0-4ef0-9364-12ae8413ccban%40googlegroups.com.

Hosting

[slide]

Since I have been out of the loop for a while, I was reviewing the new(ish) 
hosting requirements documentation 
here: 
https://www.jenkins.io/doc/developer/publishing/requesting-hosting/#open-hosting-request.
 

Does this mean we can remove the hosting checker and such from the ircbot, 
or has it been updated for the new flow to check the PRs?

Thanks,

Alex

-- 
You received this message because you 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/3bf1914e-98ef-4132-8b27-afc3b3ac5f4en%40googlegroups.com.

Re: Governance meeting Feb 23, 2022

[Slide]

>
>
>>-
>>
>>
>>Version number to yearly?
>>-
>>
>>   Starting in with 23.01 being the first week of the year 2023
>>   -
>>
>>   Harder to skip/reissue/etc a release
>>
>> Or format as a date, like 2022.02.23, so we can issue up to one release a
> day. Or drop MRP and use CD versions…
>

Windows installers have issues with versions like this, there are limits on
how high the major/minor/build version can go.

FileVersions and ProductVersions are unrelated. ProductVersion is shown in
Add/Remove Programs ( Programs and Features ) and is mainly used during
Major Upgrade scenarios to decide what should happen.

ProductVersion Property is defined as [0-255].[0-255].[0-65535] ( 8,8,16
signed bit respectively) File Version is defined as
[0-65535].[0-65535].[0-65535].[0-65535] ( 16,16,16,16 signed bit... )

The product version is already mangled to support LTS releases, it might
get confusing as to what version is installed if we have to mangle more.

-- 
You received this message because you 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/CAPiUgVc1HtMoz32xGzaKix8Hh5Ce3SZzGy%3DGxJHbqy_tezEuzw%40mail.gmail.com.

Re: Plugin Adoption Request: publish-over-ssh-plugin

[Slide]

I used to be the developer for this plugin, it would be good to have
someone take this over, so a huge +1 from me.

On Sat, Jan 22, 2022 at 11:07 AM Gavin McDonald  wrote:

> Hi All,
>
> I'd like to become maintainer of the publish-over -ssh-plugin.
> This would be my first plugin adoption.
>
> https://github.com/jenkinsci/publish-over-ssh-plugin
> Plugin is up for adoption
> There are currently no developers listed (so nobody to ping?)
> Github ID: https://github.com/gmcdonald
> Jenkins ID: gmcdonald
> Permissions Updater PR:
> https://github.com/jenkins-infra/repository-permissions-updater/pull/2332
>
> Let me know what else you need.
>
> Thanks!
>
> Gav...
>
>
>
> --
> You received this message because you 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/50e2d8ec-3986-45e5-93d0-abe300e277e1n%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVdsoB%2B4XO5ARaCXe18t%2BuPTa0%2BH4Fr3tCKHQbrbjoimDw%40mail.gmail.com.

Re: Hosting && Gavin Schedule

[Slide]

We've been doing it for a long time already. Allowing insecure plugins into
the infra creates a LOT of work for the security folks. I think it's a
benefit to run the security checks to reduce that already heavy workload.
It usually just takes a couple of back and forth discussions on Jira for
hosting issues to get things resolved to cover most of the security issues.
It's not a large barrier to overcome in my opinion.

On Tue, Sep 21, 2021 at 8:57 AM Robert Sandell 
wrote:

> I understand the case that we wan't to make sure users/administrators can
> somehow trust what is offered in the public/official update center.
> But I don't like the idea of restricting or putting up barriers for new
> contributors to join the project, or hindering the potential innovation
> coming in from the outside.
> It was the welcoming and open approach of "just ask and you shall receive"
> that made me like this community so much and stay around for 11 years and
> hopefully many more.
> There must be some way we can address both without sacrificing one?
> So by all means, run the script to find the issues, but please don't block
> a contribution based on the findings from it.
>
> /B
>
> Den lör 18 sep. 2021 kl 05:20 skrev 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com>:
>
>> I can run them before approving  / reviewing them
>>
>> In addition, i would like to help manage end users expectation about what
>> kind of support a plugin might have (Core, Community, Professional, etc).
>> Just one more thing to do on the todo list.
>>
>> Gavin
>>
>> On Fri, Sep 17, 2021 at 8:16 PM Gavin Mogan  wrote:
>>
>>> I Lost track of where you did the ping to me. Sounds out I need to be
>>> clearer. if I get more scripts to run, I can run them before
>>>
>>> On Thu, Sep 16, 2021 at 10:10 PM Gavin Mogan 
>>> wrote:
>>>
 I'm sorry I thought you were offering them up. I didn't realize you
 were asking if I wanted them. I can certainly try them out

 As for the banner. It might be worth some sort of verified publisher or
 something else that indicates when the company maintains the plugin and you
 should contact thier support, vs community maintained plugins with
 community support avenues.

 On Thu., Sep. 16, 2021, 9:16 p.m. 'Daniel Beck' via Jenkins Developers,
  wrote:

>
>
> > On 17. Sep 2021, at 04:32, 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
> >
> > So sure, someone other than you can do more in-depth reviews of the
> code. I've been doing absolute basic checks with the expertise I have. I
> was very clear when I took over the hosting lead position that I wasn't
> going to be spending much time doing reviews. I'm absolutely happy for
> someone to step up and do more code reviews.
>
> Thanks for starting this conversation.
>
> My preferred option (that I mentioned in Jira) is to have a basic
> review of the plugin. My offer from August to give you access to the code
> scanning rules for plugins to quickly identify the low hanging fruit at
> least still stands. I haven't heard back from you about that.
>
> Another option could be not have reviews, instead to do something
> similar to what Mozilla does[1], and prominently display that plugins are
> not reviewed for security. At least then we let admins know what they're
> getting. This would require criteria for other badges that need 
> maintaining
> however, and certainly will take time to set up.
>
> I'm sure there are other approaches we can take, but admitting code
> with very obvious security flaws doesn't seem like a great approach given
> how critical Jenkins is for many of its users.
>
>
> 1: https://support.mozilla.org/en-US/kb/add-on-badges
>
> --
> You received this message because you 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/8E216E2D-EA35-4A21-99C8-44A026BFD592%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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dusvy%3D0f_XCDrGpZ8FS5HmOdck4xORvtjdScfzc43iu3gQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> *Robert Sandell*
> Senior Software Engineer
> CloudBees, Inc.
> 
> E: 

Re: Filename too long issues in https://ci.jenkins.io/ on Windows workers

[Slide]

Yes, it would need to be added to the images for the infra.

On Tue, Sep 14, 2021 at 10:22 AM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Isn't all the advice specific to building locally? The problem was stated
> on CI.jenkins
>
> So I'm guessing an infra ticket/pr to enable the Reg key?and maybe agents
> should be on the root instead of users Jenkins work?
>
> On Tue., Sep. 14, 2021, 9:53 a.m. Slide,  wrote:
>
>> You could try this when building the images for Windows:
>>
>> reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
>> /v LongPathsEnabled /t REG_DWORD /d 1
>>
>> This should enable long file names in the OS itself
>>
>> On Tue, Sep 14, 2021 at 9:09 AM Mark Waite 
>> wrote:
>>
>>> I've not found a technique that resolves the issue for all cases.  Some
>>> of the techniques we've tried with varying levels of non-success have
>>> included:
>>>
>>>- Shorten the job name and file path as much as possible (C:\J
>>>instead of C:\Users\Jenkins\Work) (helps, but doesn't fix it, could be
>>>applied to ci.jenkins.io configuration and our Windows image
>>>generation <https://github.com/jenkins-infra/packer-images>)
>>>- Git config system level core.longpaths true (seems to help in some
>>>cases, but doesn't fix it in all cases
>>><https://github.com/git-for-windows/git/issues/2576>) (this change
>>>could be applied in the Windows image generation for ci.jenkins.io,
>>>since we have that in code now
>>><https://github.com/jenkins-infra/packer-images>)
>>>- Git config repository level core.longpaths true (helps in cases
>>>where the initial clone and checkout was successful but later operations
>>>failed, can be implemented in the tests of the plugin)
>>>
>>> Some of the references that provide more information about the issue:
>>>
>>>- Git for windows open issue -
>>>https://github.com/git-for-windows/git/issues/2576
>>>- Example using repository level config -
>>>https://github.com/jenkinsci/git-client-plugin/pull/595
>>>- Attempt to create that configuration in the git client plugin -
>>>https://github.com/jenkinsci/git-client-plugin/pull/523
>>>- Second attempt to create that configuration in the git client
>>>plugin - https://github.com/jenkinsci/git-client-plugin/pull/537
>>>
>>>
>>> On Tue, Sep 14, 2021 at 9:54 AM Victor Martinez <
>>> victormartinezru...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Is there any specific configuration I could apply permanently to avoid
>>>> the below error that happens in https://ci.jenkins.io/ when running
>>>> the tests on Windows?
>>>>
>>>>  > git.exe init
>>>> C:\Users\jenkins\Work\workspace\gins_opentelemetry-plugin_PR-167\target\tmp\j
>>>> h927479030425102413\workspace\co-3 # timeout=10
>>>> Fetching upstream changes from
>>>> https://github.com/jenkinsci/opentelemetry-plugin
>>>> ...
>>>> [Pipeline] }
>>>> [Pipeline] // stage
>>>> [Pipeline] }
>>>> [Pipeline] // node
>>>> [Pipeline] End of Pipeline
>>>> hudson.plugins.git.GitException: Command "git.exe checkout -f
>>>> a1479a055ebb33d6abf48ce9238fb586edc97203" returned status code 1:
>>>> stdout:
>>>> stderr: error: unable to create file
>>>> src/main/resources/io/jenkins/plugins/opentelemetry/JenkinsOpenTelemetryPluginConfiguration/help-exportOtelConfigurationAsEnvironmentVariables.html:
>>>> Filename too long
>>>>
>>>> I've been shorting the pipeline names for the time being, but I think
>>>> the workaround doesn't work anymore.
>>>>
>>>> Thanks so much.
>>>>
>>>> --
>>>> You received this message because you 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/e9e92f22-2b38-48fb-86ac-7e216d67db61n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/e9e92f22-2b38-48fb-86ac-7e216d67db61n%40googlegroups.com?utm_medium=email_source=foote

Re: Filename too long issues in https://ci.jenkins.io/ on Windows workers

[Slide]

You could try this when building the images for Windows:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
/v LongPathsEnabled /t REG_DWORD /d 1

This should enable long file names in the OS itself

On Tue, Sep 14, 2021 at 9:09 AM Mark Waite 
wrote:

> I've not found a technique that resolves the issue for all cases.  Some of
> the techniques we've tried with varying levels of non-success have included:
>
>- Shorten the job name and file path as much as possible (C:\J instead
>of C:\Users\Jenkins\Work) (helps, but doesn't fix it, could be applied to
>ci.jenkins.io configuration and our Windows image generation
>)
>- Git config system level core.longpaths true (seems to help in some
>cases, but doesn't fix it in all cases
>) (this change
>could be applied in the Windows image generation for ci.jenkins.io,
>since we have that in code now
>)
>- Git config repository level core.longpaths true (helps in cases
>where the initial clone and checkout was successful but later operations
>failed, can be implemented in the tests of the plugin)
>
> Some of the references that provide more information about the issue:
>
>- Git for windows open issue -
>https://github.com/git-for-windows/git/issues/2576
>- Example using repository level config -
>https://github.com/jenkinsci/git-client-plugin/pull/595
>- Attempt to create that configuration in the git client plugin -
>https://github.com/jenkinsci/git-client-plugin/pull/523
>- Second attempt to create that configuration in the git client plugin
>- https://github.com/jenkinsci/git-client-plugin/pull/537
>
>
> On Tue, Sep 14, 2021 at 9:54 AM Victor Martinez <
> victormartinezru...@gmail.com> wrote:
>
>> Hi all,
>>
>> Is there any specific configuration I could apply permanently to avoid
>> the below error that happens in https://ci.jenkins.io/ when running the
>> tests on Windows?
>>
>>  > git.exe init
>> C:\Users\jenkins\Work\workspace\gins_opentelemetry-plugin_PR-167\target\tmp\j
>> h927479030425102413\workspace\co-3 # timeout=10
>> Fetching upstream changes from
>> https://github.com/jenkinsci/opentelemetry-plugin
>> ...
>> [Pipeline] }
>> [Pipeline] // stage
>> [Pipeline] }
>> [Pipeline] // node
>> [Pipeline] End of Pipeline
>> hudson.plugins.git.GitException: Command "git.exe checkout -f
>> a1479a055ebb33d6abf48ce9238fb586edc97203" returned status code 1:
>> stdout:
>> stderr: error: unable to create file
>> src/main/resources/io/jenkins/plugins/opentelemetry/JenkinsOpenTelemetryPluginConfiguration/help-exportOtelConfigurationAsEnvironmentVariables.html:
>> Filename too long
>>
>> I've been shorting the pipeline names for the time being, but I think the
>> workaround doesn't work anymore.
>>
>> Thanks so much.
>>
>> --
>> You received this message because you 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/e9e92f22-2b38-48fb-86ac-7e216d67db61n%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/CAO49JtF8rg%3D43JRe1NQt%3Dxv8Pyhqe9dVeehUmrWWh_L4vyFfGQ%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVe8abek4JJrgsz-MxrFnG9-DsxaWnotn2ytFfzEpBGORw%40mail.gmail.com.

Re: Hosting

[Slide]

I should probably be removed from that team as well.

On Wed, Aug 25, 2021 at 1:18 PM Tim Jacomb  wrote:

> Oleg has permissions on the team or Olivier:
> https://github.com/orgs/jenkins-infra/teams/hosting/members
>
>
> On Wed, 25 Aug 2021 at 21:03, Slide  wrote:
>
>> Those are the basics, just the bot checker (jenkins-admin: check
>> HOSTING-) in the jenkins-hosting channel.
>>
>> On Wed, Aug 25, 2021 at 12:20 PM 'Gavin Mogan' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> Okay, making it official. If nobody else speaks up as wanting to take
>>> over as lead before end of week (Friday night pacific time) I'll take over
>>> and make sure hosting requests get moving.
>>>
>>> I think i've fixed my irc client so I should stay in the channels now.
>>> Can I get invited to the hosting github teams as well?
>>>
>>> Is there anything else that might be needed for transition?
>>>
>>> Gavin
>>>
>>> On Wed, Aug 25, 2021 at 8:07 AM wfoll...@cloudbees.com <
>>> wfollon...@cloudbees.com> wrote:
>>>
>>>> Thank you very much Alex for the effort you invested on this area. This
>>>> is a really important piece of the process for the security perspective.
>>>> The fact that you did the preliminary security checks and if something was
>>>> weird, to ask the security team to make a more complete audit, was of a
>>>> great help for us.
>>>>
>>>> I cannot ask you Gavin to do more than what you are proposing to do as
>>>> if you are not proposing this it will be mainly nothing being done, so
>>>> anything is better than nothing :-) In the case where you are not sure
>>>> about a plugin, if you are seeing something weird, do not hesitate to ping
>>>> Daniel Beck and me in the HOSTING ticket, requesting an audit from us.
>>>>
>>>> Wadeck
>>>>
>>>> On Wednesday, August 25, 2021 at 5:58:20 AM UTC+2 ga...@gavinmogan.com
>>>> wrote:
>>>>
>>>>> If nobody else is able to step up, I can take it, but I won't be code
>>>>> reviewing and as quickly as possible switch it from jira+irc to
>>>>> https://github.com/jenkins-infra/repository-permissions-updater +
>>>>> issue bot
>>>>> All i'll be doing is "Is there another plugin that sounds similar?
>>>>> Does it pass the checks? approved"
>>>>>
>>>>>
>>>>> On Tue, Aug 24, 2021 at 8:21 PM Slide  wrote:
>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> I sent the group an email a while back about not having time for
>>>>>> managing hosting requests and was looking for someone to step up and take
>>>>>> it over. That hasn't really happened and I am at a point now where I can 
>>>>>> no
>>>>>> longer do it at all. Someone from the community will need to step up and
>>>>>> take this over ASAP. I am willing to walk someone through stuff, but I
>>>>>> can't monitor the hosting Jira and do the checks and code reviews 
>>>>>> anymore.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> --
>>>>>> 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-de...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcc_XM8KO7XAxE7bBgvxeH3b6McLD-fVMi0AV9dCRvKOQ%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcc_XM8KO7XAxE7bBgvxeH3b6McLD-fVMi0AV9dCRvKOQ%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
>>&g

Re: Hosting

[Slide]

Those are the basics, just the bot checker (jenkins-admin: check
HOSTING-) in the jenkins-hosting channel.

On Wed, Aug 25, 2021 at 12:20 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Okay, making it official. If nobody else speaks up as wanting to take over
> as lead before end of week (Friday night pacific time) I'll take over and
> make sure hosting requests get moving.
>
> I think i've fixed my irc client so I should stay in the channels now.
> Can I get invited to the hosting github teams as well?
>
> Is there anything else that might be needed for transition?
>
> Gavin
>
> On Wed, Aug 25, 2021 at 8:07 AM wfoll...@cloudbees.com <
> wfollon...@cloudbees.com> wrote:
>
>> Thank you very much Alex for the effort you invested on this area. This
>> is a really important piece of the process for the security perspective.
>> The fact that you did the preliminary security checks and if something was
>> weird, to ask the security team to make a more complete audit, was of a
>> great help for us.
>>
>> I cannot ask you Gavin to do more than what you are proposing to do as if
>> you are not proposing this it will be mainly nothing being done, so
>> anything is better than nothing :-) In the case where you are not sure
>> about a plugin, if you are seeing something weird, do not hesitate to ping
>> Daniel Beck and me in the HOSTING ticket, requesting an audit from us.
>>
>> Wadeck
>>
>> On Wednesday, August 25, 2021 at 5:58:20 AM UTC+2 ga...@gavinmogan.com
>> wrote:
>>
>>> If nobody else is able to step up, I can take it, but I won't be code
>>> reviewing and as quickly as possible switch it from jira+irc to
>>> https://github.com/jenkins-infra/repository-permissions-updater + issue
>>> bot
>>> All i'll be doing is "Is there another plugin that sounds similar? Does
>>> it pass the checks? approved"
>>>
>>>
>>> On Tue, Aug 24, 2021 at 8:21 PM Slide  wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I sent the group an email a while back about not having time for
>>>> managing hosting requests and was looking for someone to step up and take
>>>> it over. That hasn't really happened and I am at a point now where I can no
>>>> longer do it at all. Someone from the community will need to step up and
>>>> take this over ASAP. I am willing to walk someone through stuff, but I
>>>> can't monitor the hosting Jira and do the checks and code reviews anymore.
>>>>
>>>> Regards,
>>>>
>>>> Alex
>>>>
>>>> --
>>>> 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-de...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcc_XM8KO7XAxE7bBgvxeH3b6McLD-fVMi0AV9dCRvKOQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcc_XM8KO7XAxE7bBgvxeH3b6McLD-fVMi0AV9dCRvKOQ%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/9b9ee1d8-2f3a-41b3-8107-ee6add773ca7n%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/9b9ee1d8-2f3a-41b3-8107-ee6add773ca7n%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/CAG%3D_DutKi%2Bazg5WS%3DW6%2BBZ5zH0fox1AhHUXbJn93H0KtJEWgbw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutKi%2Bazg5WS%3DW6%2BBZ5zH0fox1AhHUXbJn93H0KtJEWgbw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Hosting

[Slide]

Hi Everyone,

I sent the group an email a while back about not having time for managing
hosting requests and was looking for someone to step up and take it over.
That hasn't really happened and I am at a point now where I can no longer
do it at all. Someone from the community will need to step up and take this
over ASAP. I am willing to walk someone through stuff, but I can't monitor
the hosting Jira and do the checks and code reviews anymore.

Regards,

Alex

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

Re: Using JDK 11 instead of JDK 8 in default docker images

[Slide]

We aren't using Oracle's JDK in the images, we are using the Adoptium
project's JDK.

On Wed, Aug 4, 2021 at 11:04 AM the.n...@gmail.com 
wrote:

> I'm sorry I missed this meeting - other obligations. We are stuck on JDK 8
> for a variety of reasons, including Oracle's JDK 11 license terms, which
> are significantly different from JDK 8, and also that JDK 11 is not
> available on our ia64 platform. How long will JDK 8 builds continue to be
> available and is there a link I can include for my community for both
> Docker and standard locations?
>
> Thanks,
> Randall
>
> On Tuesday, August 3, 2021 at 10:43:28 p.m. UTC-4 Mark Waite wrote:
>
>> I've submitted the Jenkins Enhancement Proposal that proposes to switch
>> from JDK 8 to JDK 11 for the Jenkins 2.302.1 LTS release on Aug 25, 2021.
>>
>> Pull request is https://github.com/jenkinsci/jep/pull/374/files
>>
>> File content view is:
>>
>>
>> https://github.com/jenkinsci/jep/blob/401af5fa324867d30fac61dce91418fdc4a3caa5/jep//README.adoc
>> is the
>>
>> On Friday, July 2, 2021 at 7:51:22 AM UTC-6 Mark Waite wrote:
>>
>>> I believe that the plan from the Contributor Summit aligns with Oleg's
>>> vote that he cast in advance.  The Platform SIG will meet today and has
>>> Java 11 on the agenda for further discussion.
>>>
>>> Contributor summit notes are recorded in a Google Doc
>>> .
>>> The YouTube video  of the session is also
>>> available.
>>>
>>> My summary of the proposed plan from the Contributor Summit is:
>>>
>>> Weekly release
>>>
>>>- Jenkins Docker controller images for weekly releases switch to
>>>Java 11 4-6 weeks before the September LTS release.  That includes
>>>jenkins/jenkins:latest, jenkins/jenkins:alpine, jenkins/jenkins:centos7,
>>>and more.
>>>- Jenkins Docker controller images for weekly releases add a Java 8
>>>tag 4-6 weeks before the September LTS release as an escape hatch for 
>>> users
>>>that require Java 8.  That would be jenkins/jenkins:latest-jdk8,
>>>jenkins/jenkins:alpine-jdk8, and jenkins/jenkins:centos7-jdk8
>>>
>>> LTS release
>>>
>>>- Jenkins Docker controller images for LTS releases switch to Java
>>>11 with the September LTS release.  That includes jenkins/jenkins:lts,
>>>jenkins/jenkins:lts-alpine, jenkins/jenkins:centos7, and more
>>>- Jenkins Docker controller images for LTS releases add a Java 8 tag
>>>with the September LTS release   as an escape hatch for users that 
>>> require
>>>Java 8.  That would be jenkins/jenkins:lts-jdk8,
>>>jenkins/jenkins:lts-alpine-jdk8, and jenkins/jenkins:lts-centos7-jdk8
>>>
>>> A blog post will be provided for the weekly change and an additional
>>> blog post and an upgrade guide entry will be provided for the LTS change.
>>>
>>> A JEP will be submitted that details the proposed transition plan so
>>> that we can review the transition plan in greater detail.
>>>
>>> We'll discuss further and in more detail in the Platform SIG meeting
>>> later today.
>>>
>>> Mark Waite
>>>
>>> On Monday, June 28, 2021 at 9:51:42 PM UTC-6 Oleg Nenashev wrote:
>>>
 Hi all,

 Looking forward to see the discussion from the contributor summit
 summarized here. Sadly I missed it due to having another session, but I've
 heard it was a great discussion that resulted in a proposal. Thanks to Mike
 Cirioli and Mark Waite for driving this topic at the summit, and thanks to
 all contributors. Just posting the links shared by Mike and Runxia in the
 Google Doc:


- Slides:

 https://docs.google.com/presentation/d/1i1gkUQ0Ha-CRgFvRRpRWUDjbpPr383D0DSywLGAFN-Y/edit?usp=sharing
- Meeting notes:

 https://docs.google.com/document/d/1BwllcgX3rmsvwRKIFkmE24g7zHGo8kufcimL0BnWaWE/edit?usp=sharing

 I might be unavailable when the decision making happens, so I would
 like to cast my votes in advance. Note that I have not fully went through
 the notes, and might be misaligned. I am happy to support whatever decision
 made by the community. My votes are:

- +1 for making Java 11 a default in all Jenkins distributions
starting from September LTS. It applies to Jenkins controller and agent
Docker images. It also applies to Helm chart, Jenkins Operator and 
 whatever
other packaging that happens to include Java. Jenkinsfile Runner already
ships Java 11 by default FTR.
- +1 for allowing Java 11 only plugins starting from the September
LTS. We have tooling embedded into the Jenkins core and Jenkins update
centers starting from LTS releases in 2018 (2.164.x IIRC), so all modern
Jenkins versions will be able to properly notify users in the UI Plugin
manager. https://github.com/jenkinsci/plugin-pom/pull/133 should be
finalized to make it possible in 

Re: Forked repositories in GitHub

[Slide]

It would be super ideal to do transferring if we could figure out a good
process for it, we lose GitHub Issues and some other things when we fork as
is.

On Wed, Jul 28, 2021 at 8:33 AM Tim Jacomb  wrote:

> Wouldn't creating a repo and pushing the code instead of forking work
> during the hosting process?
>
>
> On Wed, 28 Jul 2021 at 15:02, Jesse Glick  wrote:
>
>> On Wed, Jul 28, 2021 at 2:48 AM timja...@gmail.com 
>> wrote:
>>
>>> Seem's like GitHub won't break the fork relationship anymore without
>>> both sides agreeing to it?
>>>
>>
>> This could be a real problem for us. We still have a bunch of repos with
>> misleading fork status, like https://github.com/jenkinsci/plugin-pom
>> rather prominently. There should be some provision by which a “fork” which
>> has way more activity than the “origin” can unilaterally break the
>> relationship. Of course you can delete and recreate the repo with Git
>> history intact but you will lose all PR history, which is intolerable.
>>
>> --
>> 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/SkKoCccPrOc/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/CANfRfr1XZbUvJER_5-LMFd8i1d1RTaFy6JPLhwq9pG9uLE_ZVg%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-3Bie4r6MsTyNum4R57DSe3eMO7yNSVt1qbndVZviE%3D57Eug%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVf5HMgWmy%2BrQbnTH1p02Ngo9dXfqtR19SG%3DcxR_NLyWxw%40mail.gmail.com.

Re: Forked repositories in GitHub

[Slide]

Transfers are much less automatable. There are APIs, but they have to be
initiated by the person who is transferring the repo and then ack'd by the
org receiving the transfer. So, the bot would not be able to do everything
anymore.

On Tue, Jul 27, 2021, 23:48 timja...@gmail.com  wrote:

>
> Seem's like GitHub won't break the fork relationship anymore without both
> sides agreeing to it?
> They've done it in the past for me but wouldn't do it yesterday.
>
> GH> In the two scenarios you have:
>
> DB>> It is possible to invert the fork relationship. This requires
> approval from both repo owners (i.e. jenkinsci and whoever we forked from).
>
> GH> This is correct.
>
> DB> It is possible to cut the fork relationship. This requires approval
> from the forked repo owner (i.e. jenkinsci).
>
> GH>>This would only be the case of the fork network is private. However,
> the fork network in question is public, so we'll need the repository owner
> to contact us and approve this request.
>
> GH>>I hope this helps clarify.
>
>
> Thanks
>
> Tim
> On Thursday, 20 August 2020 at 08:39:22 UTC+1 bma...@gmail.com wrote:
>
>> +1. All for it.
>>
>> Le mar. 18 août 2020 à 13:38, Daniel Beck  a écrit :
>>
>>> Hi everyone,
>>>
>>> I'd like to propose a cleanup of 'fork' relationships of the
>>> repositories in the jenkinsci GitHub organization.
>>>
>>> Background:
>>> For many years, the plugin hosting process has forked existing
>>> repositories. The expectation was always that the new repo in jenkinsci was
>>> the canonical 'main' repository, but that wasn't enforced. For the past
>>> year or two, we've even asked maintainers to delete their repository after
>>> forking unless there were useful PRs and issues in there already, so that
>>> the jenkinsci repo became the 'main' repo (with occasional mishaps if
>>> someone else had forked before us).
>>>
>>> Some people enjoy the "branding" effect that having the source
>>> repository creates. But this comes with downsides: Sometimes GitHub code
>>> search doesn't work, depending on the popularity of the repository. Links
>>> to create pull requests sometimes don't work quite right, and INFRA-2697
>>> notes that the GitHub CLI cannot really handle networks where a fork is the
>>> "main" repo, probably for the same reason. Having a different repo than
>>> what we consider canonical as the "root" repository confuses users trying
>>> to file pull requests or issues on GitHub. It'll get worse once GitHub adds
>>> repo-level discussions[1]. Basically, the more stuff is attached to a
>>> repository that isn't trivially cloned/mirrored to forks, the worse it gets.
>>>
>>> In terms of security, GitHub for quite some time did not support
>>> security warnings for forks. LGTM.com / GitHub Security Labs still does not
>>> recognize forked repositories. Earlier this year a security researcher
>>> recently used its CodeQL functionality to identify and submit fixes to
>>> pom.xml files referencing plain HTTP Maven repositories, but couldn't do
>>> that for forked repos. In many cases, the source repositories are much less
>>> active than the repo in jenkinsci, or the maintainers have moved on
>>> entirely, making this feature unavailable to (other) current maintainers,
>>> or the Jenkins security team.
>>>
>>> The way we create forks is simply not a well-supported use case.
>>>
>>> My proposal therefore is to "unfork" plugin and similar repositories in
>>> the jenkinsci organization. Only repositories that clearly are forks (e.g.
>>> some libraries not maintained by us) would remain forks.
>>>
>>> After checking with GitHub support, the following options exist:
>>>
>>> 1. It is possible to invert the fork relationship. This requires
>>> approval from both repo owners (i.e. jenkinsci and whoever we forked from).
>>> 2. It is possible to cut the fork relationship. This requires approval
>>> from the forked repo owner (i.e. jenkinsci).
>>>
>>> And while it is technically possible to re-attach repos to a network /
>>> merge networks, GH support would rather not do that.
>>>
>>> Therefore I propose we implement the following steps:
>>>
>>> 1. We try to contact, wherever possible, whoever we forked from, and ask
>>> them to contact GitHub support. I'll grant blanket permission on behalf of
>>> jenkinsci and will tell everyone the support ticket number to reference so
>>> this goes as smoothly as possible.
>>> 2. We wait a while while folks ask GH support for an inversion of the
>>> fork relationship.
>>> 3. We ask GitHub support to cut the fork relationship of everything
>>> that's left over.
>>>
>>> Additionally, we should change the hosting process to work with repo
>>> transfers, or creation of repos without the fork relationship. That can be
>>> done at any time though; as even now we don't really want that fork
>>> relationship we create to exist.
>>>
>>> To understand the scope of this, I've written a script that periodically
>>> updates a list of forked repositories in jenkinsci, you can see 

Re: ASM in core

[Slide]

It originally used regex/hand parsing, but some of the requests for
features were not super easy to implement using that method. I can look at
it again if we want to remove the ASM dependency for sure.

On Tue, Jun 15, 2021 at 8:55 AM Jesse Glick  wrote:

> On Mon, Jun 14, 2021 at 10:47 PM Slide  wrote:
>
>> ASM is a dependency of the parser used (parboiled).
>>
>
> What is what I gathered. Probably the fairly simple syntax used by this
> plugin could be handled with a hand-written parser (regexp?) with some
> effort. But it seems to also be used by some JSONPath system?
>
> --
> You received this message because you 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/CANfRfr1acCBAzdOGx_NzQHx3VpP62pd%3Dp%2BuuEK0Ajxo5_kpdtQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1acCBAzdOGx_NzQHx3VpP62pd%3Dp%2BuuEK0Ajxo5_kpdtQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Re: ASM in core

[Slide]

ASM is a dependency of the parser used (parboiled). People still use token
macro a lot even in pipeline even if there are other ways of doing what it
does.

On Mon, Jun 14, 2021 at 7:36 PM Jesse Glick  wrote:

> We should also take a step back and see if these problematic deps really
> need to exist at all. Most uses of ASM should be deleted if at all
> possible. I was able to remove Digester and thus, I guess, ASM from the
> Subversion plugin without much difficulty. I do not understand Token Macro
> well enough to understand whether it fundamentally needs ASM there (nor do
> I intend to spend time on that plugin given that Pipeline rendered it
> obsolete). The Stapler dep on ASM turned out to be just an overengineered
> way of solving a problem which can be addressed by adding a single flag to
> javac (though we need to update the parent POMs of plugins to avoid needing
> ASM at runtime for them).
>
> JNR may be a similar story. I see all of two usages in core—both disabled
> unless you set a system property. Just deleting it all may be easier than
> having subtle debates about class loader behavior and compatibility policy.
>
> --
> You received this message because you 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/CANfRfr3NPD3b%2BQ2TiQGLyqicuA2-gEby-%2BCJgLGtViXOw1Uh_w%40mail.gmail.com
> 
> .
>


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

Re: Using JDK 11 instead of JDK 8 in default docker images

[Slide]

I think Mark was looking at doing the migration in September if I remember
correctly.

On Mon, Jun 14, 2021 at 6:20 AM 'Olblak' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> What the current state here?
> Looks like the docker image still use java 8 by default but the helm chart
> switched to java 11
>
> Should we talk about switching to java11 by default during the contributor
> summit?
>
> On Monday, 10 May 2021 at 15:47:41 UTC+2 timja...@gmail.com wrote:
>
>> What metric would people consider?
>>
>> 0? Few new issues? From personal experience on Java 11 I have never hit
>> the above issues (apart from illegal reflective access log messages)
>>
>> Query I used to look:
>>
>> https://issues.jenkins.io/browse/JENKINS-64831?filter=22940=labels%20in%20(java11-compatibility)%20and%20resolution%20is%20EMPTY
>>
>> On Mon, 10 May 2021 at 13:31, Jesse Glick  wrote:
>>
>>> On Sun, May 9, 2021 at 4:10 AM Tim Jacomb  wrote:
>>>
 encourage existing users to migrate

>>>
>>> Feels a bit premature when the list of `java11-compatibility` issues
>>> still includes bugs in core and widely used plugins.
>>>
>>> (The only ones I have personal experience with are JENKINS-61212
>>> , which should only
>>> affect users terminating TLS in Jenkins, rather than a reverse
>>> proxy/ingress which I suppose is more customary; and JENKINS-57139
>>>  which affects the GUI
>>> agent installers that would be lightly deprecated in JEP-230 but for now
>>> remain in core.)
>>>
>>> --
>>>
>> You received this message because you 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/CANfRfr0w-YsTD3odTAJouMGG2QZLRpq85Q6ynp8pzFEk0vJgzg%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/b61e8db2-0c93-4e7f-9147-6ce662c1acfcn%40googlegroups.com
> 
> .
>


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

Plugin Hosting

[slide]

Hi All,

Hope you are all doing well! There are currently 6 plugin hosting requests 
that I am not able to move along. At this point, they are waiting for code 
reviews looking for common security issues and so forth. Does anyone have 
any time they could put in to doing some of these reviews?

https://issues.jenkins.io/projects/HOSTING/issues/HOSTING-?filter=allopenissues

Thanks,

Alex

-- 
You received this message because you 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/6885ba62-1a94-4645-a36e-99074982293cn%40googlegroups.com.

Re: Discourse as the default communication channel?

[Slide]

I would like access please. Just a question, as I am very unfamiliar with
Discourse. Is it a real time communication medium, a la IRC, or something
more akin to a forum?

On Thu, May 27, 2021 at 11:57 AM 'Olblak' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> For whoever is interested to participate to the Discourse project,
> we started discussing over there as a way to test it and get more familiar
> with the tool.
> -> https://community.jenkins.io/t/discussion-about-categories/27/12
>
> Feel free to request an access as I didn't have the time yet to really
> investigate the consequences of the different authentication methods.
>
> On Tue, May 25, 2021, at 8:46 PM, 'Olblak' via Jenkins Developers wrote:
> > Hi Bruce,
> >
> > Thank you for stepping up, you already provided a lot of information
> > here.
> > And let's not assume we all know everything about discourse as we
> > definitely don't.
> > As you are interested to help with this project, I'll send you an
> > invite to "community.jenkins.io".
> >
> > As long as we don't have an agreement on the authentication mechanism,
> > I'll work on invite-only.
> >
> > Regarding identifying what we expected from Discourse, Bruce made a
> > good statement that discourse is what we want it to be, so here what I
> > would like it to solve.
> > I would like to easily identify and participate in discussion about
> > topics that interested me across different sub-project. So as an
> > initial step, Oleg suggestion seems right to me.
> >
> > On my side, I'll investigate the different authentication options.
> > Today during the infrastructure Oleg made a good remark,  we would like
> > to ideally move away from maintaining our Ldap service and we would
> > like to offer more alternatives than just using a Github account so
> > maybe using Linux foundation accounts would be better.
> >
> >
> > On Tue, May 25, 2021, at 7:16 PM, Matt Sicker wrote:
> > > Ha, so I was. Oops!
> > >
> > > On Tue, 25 May 2021 at 10:32, 'Gavin Mogan' via Jenkins Developers
> > >  wrote:
> > > >
> > > > Matt. It's often a confusion point. Discourse is more like a
> form/mailing list type thing. Discord is realtime communication. Sounds
> like your describing discord.
> > > >
> > > > On Tue., May 25, 2021, 6:52 a.m. Matt Sicker, 
> wrote:
> > > >>
> > > >> I’ve never used Discourse outside of video games, but it seems
> easier to set up public communities on than Slack or other things we’ve
> tried here so far. While in theory I’d prefer something open like Matrix, I
> do agree that we should try to minimize the number of services to maintain
> ourselves.
> > > >>
> > > >> On Tue, May 25, 2021 at 07:45 Oleg Nenashev 
> wrote:
> > > >>>
> > > >>> Hi all,
> > > >>>
> > > >>> Thanks to Olivier for starting this discussion and for confirming
> sponsorship for Discourse. This is definitely something we could use to
> address the current sprawl of Jenkins communication channels. Many channels
> like User Mailing list, some SIG mailing lists and many Gitter channels
> could be replaced by discourse. So I am +1 for starting evaluation.
> > > >>>
> > > >>>
> > > >>> > 2) Configure the right level of Categories, as a first iteration
> I would like to focus on Jenkins users but we could extend it to Jenkins
> contributors as well.
> > > >>>
> > > >>> As Bruce said above, setting up a proper structure and moderation
> process is essential to the success of Discourse. Before we make it
> official, we should try it out and see how to better structure the
> communication channels. IMHO any interested contributor with Discourse
> expertise is welcome to participate in this effort. And thanks for stepping
> up Bruce!
> > > >>>
> > > >>> My notes:
> > > >>>
> > > >>> I would recommend creating categories for SIGs, sub-projects and
> outreach programs right away.
> > > >>> It would be great to create generic categories like "Jenkins
> Pipeline" or "Jenkins on Kubernetes". Plugins structure should be secondary
> there
> > > >>> Some plugins and components may need sub-categories. Likely these
> would be tool integration plugins (e.g. "Git plugins")
> > > >>> TBD: Creating a Governance category? It is feasible, but I am not
> sure how dit aligns with the current open governance approach through this
> mailing list and meetings
> > > >>>
> > > >>> I am happy to be a guinea pig for some of the categories if needed.
> > > >>>
> > > >>>
> > > >>> > 1) Delegating authentication to a third service, Github,
> keycloak, LDAP, etc...  My preferred approach would be to rely on Github
> SSO to authenticate with the tool. But we could still use our Jenkins
> account.
> > > >>>
> > > >>> I am -1 for using the Jenkins account. Last year we agreed that we
> want to move away from running our own user identity, and I believe it was
> a right decision. One of the interesting options would be using the Linux
> Foundation SSO so that the forum is aligned with the Linux Foundation
> identities. If technically 

Re: Hosting Team

[slide]

The meeting is at 4PM UTC, my mistake.

On Tuesday, May 4, 2021 at 1:14:53 PM UTC-7 slide wrote:

> Hi Everyone,
>
> If you have been looking for a way to help out Jenkins, there is an 
> opportunity that we are having a kickoff meeting tomorrow. The Hosting team 
> needs more people to be involved in helping with onboarding for new 
> plugins. We will be going over what goes on during the hosting process and 
> how you can be involved tomorrow (May 5) at 3:00PM UTC. The zoom link is 
> https://zoom.us/j/92062641880. The hosting process is vital to getting 
> new plugins into the update center. It is not a lot of work, but many hands 
> make light work and having more eyes will help to improve the plugins that 
> get into the Jenkins infrastructure.
>
> Thanks!
>
> Alex
>

-- 
You received this message because you 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/0ba304d8-0495-42df-84b7-4c76f3959233n%40googlegroups.com.

Hosting Team

[slide]

Hi Everyone,

If you have been looking for a way to help out Jenkins, there is an 
opportunity that we are having a kickoff meeting tomorrow. The Hosting team 
needs more people to be involved in helping with onboarding for new 
plugins. We will be going over what goes on during the hosting process and 
how you can be involved tomorrow (May 5) at 3:00PM UTC. The zoom link is 
https://zoom.us/j/92062641880. The hosting process is vital to getting new 
plugins into the update center. It is not a lot of work, but many hands 
make light work and having more eyes will help to improve the plugins that 
get into the Jenkins infrastructure.

Thanks!

Alex

-- 
You received this message because you 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/fdb38343-c6b8-4579-830d-f5b11e225ff0n%40googlegroups.com.

Re: Using JDK 11 instead of JDK 8 in default docker images

[Slide]

I agree with dropping java 8. There are some nice features in 11 that would
be good to use.

On Tue, Apr 27, 2021 at 9:11 AM Tim Jacomb  wrote:

> We’ve been using it for over a year on java 11 and never hit an issue...
>
> I would rather drop java 8 as well
>
> On Tue, 27 Apr 2021 at 15:48, Jesse Glick  wrote:
>
>> My opinion remains that if we believe Java 11 support is solid enough to
>> be the default, then we may as well keep things simple and drop Java 8
>> support: start building core and important plugins with `java.level=11`,
>> and take advantage of its features. Building and testing primarily against
>> 8 while pushing users to run 11, and forcing developers to consider both
>> platforms in every situation, seems like the worst decision.
>>
>> --
>> You received this message because you 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/CANfRfr2hjuPWgK7XqzwezcT8eP1i1_ZZd_iMNreg%3D7K7FTzH8Q%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-3BifVe04fx-7vx6Dp-jkLmTvepCDGHXqRDLEWdHyNN8TG%3Dw%40mail.gmail.com
> 
> .
>


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

Re: Plugin Hosting Requests

[Slide]

Hi Aditya,

I'll tag you on some of the upcoming issues so you can see the process. We
use the irc bot to do some initial checking on the repository and Jira
issue to make sure the developer provides the necessary information. You
can join the #jenkins-hosting channel on Freenode to see the process.
Thanks for being willing to help out!

Regards,

Alex

On Fri, Apr 2, 2021 at 4:18 AM Aditya Srivastava <
adityasrivastava301...@gmail.com> wrote:

>
> Hey Alex,
> I am a newbie here, so I am not sure if I am eligible, but I sure
> am interested in helping out.
> I'd love to learn more about the screening part and I've done code reviews
> before for my _small_ open-source org, so I guess that experience would
> come in handy.
> I am excited to learn more about this and get involved.
>
> Thanks and Regards,
> Aditya Srivastava
>
>
> On Fri, Apr 2, 2021 at 10:22 AM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> I'm not sure its a good idea for me to take on more tasks, but I can help
>> out more if needed. That being said, the dev list is full of people
>> contributing, it might be worth asking on the users mailing list to see if
>> there's anyone new interested in helping out, at least the first round of
>> screening new hosting requests.
>>
>> On Thu, Apr 1, 2021 at 8:06 PM Slide  wrote:
>>
>>> Hi Everyone,
>>>
>>> As I brought up last year, I am having less time to work on Jenkins
>>> because of work responsibilities. It's time for me to reduce my time on
>>> Jenkins again sadly. I have been handling many of the plugin hosting
>>> requests that come in, running the checker and doing code reviews on the
>>> plugins prior to them being accepted into the jenkinsci org on GitHub. I
>>> will no longer have time to do that in the near future and would like to
>>> help migrate that work to someone else who is interested in helping out the
>>> project. Is anyone interested in learning about this and becoming involved?
>>>
>>> Regards,
>>>
>>> Alex
>>>
>>>
>>>
>>> --
>>> 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/CAPiUgVfAFnGYSLe3gUC-qGzPYwEHBfKYTRnd%3DUUYH%2BtpGF8pMQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVfAFnGYSLe3gUC-qGzPYwEHBfKYTRnd%3DUUYH%2BtpGF8pMQ%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/CAG%3D_DuueuU1%3DUM4wTiEnQFWf2C9BuTRsipGT67qhP%3DyocSe_Cw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuueuU1%3DUM4wTiEnQFWf2C9BuTRsipGT67qhP%3DyocSe_Cw%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/CAJMT-dHwr1yEvtWnbx9tQk_o%3DfG8GnGsta9%2B2Xobfz3ish4y_A%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAJMT-dHwr1yEvtWnbx9tQk_o%3DfG8GnGsta9%2B2Xobfz3ish4y_A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Plugin Hosting Requests

[Slide]

Hi Everyone,

As I brought up last year, I am having less time to work on Jenkins because
of work responsibilities. It's time for me to reduce my time on Jenkins
again sadly. I have been handling many of the plugin hosting requests that
come in, running the checker and doing code reviews on the plugins prior to
them being accepted into the jenkinsci org on GitHub. I will no longer have
time to do that in the near future and would like to help migrate that work
to someone else who is interested in helping out the project. Is anyone
interested in learning about this and becoming involved?

Regards,

Alex



-- 
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/CAPiUgVfAFnGYSLe3gUC-qGzPYwEHBfKYTRnd%3DUUYH%2BtpGF8pMQ%40mail.gmail.com.

Re: Unpublishing build artifacts

[Slide]

You could add an Action to the Run (
https://javadoc.jenkins-ci.org/hudson/model/Run.html#addAction-hudson.model.Action-)
to store information about the artifact location on the server. Then when
you are getting a delete, you could look for the Action and pull the
necessary information from there.


On Wed, Mar 31, 2021 at 4:20 PM Tim Van Holder 
wrote:

> Hi,
>
> I'm looking at adding support for unpublishing build artifacts.
>
> Basically, our .NET-based jobs create NuGet packages which are added as
> artifacts for the run but also pushed to a package server.
>
> For our non-release CI jobs, I want to look at automating cleanup so that
> when the job is deleted, the packages are also removed from the package
> server.
> This would ensure that a retention policy is only needed in Jenkins, not
> also in the package server.
>
> I'm running into two problems:
> - reacting to the job delete using RunListener works, and I can see the
> package artifacts in
>   order to determine which package(s) need unpublishing.
>   - However, I don't immediately see a means for storing information on
> the Run when doing the
> push (like the server used) that can be picked up on the delete.
> - it's also possible to delete the artifacts without deleting the entire
> run; however, there does not
>   seem to be a way to react to that at all.
>   - I also assume (but have not tested) that deleting the artifacts
> deletes the whole artifact, not just
> the file data, so I would not be able to see that there used to be a
> package there when the job
> is deleted.
>
> Any suggestions/ideas?
>
> --
> You received this message because you 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/CAKMi--DddQ2LjR-f9qWbYBdOVAb-BBSdnUCPvw8EAowA%3DJH6cw%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVdV_2m-8BytR50nZiT-3tuaLu6gc3eU6sKBGTNiXeZegw%40mail.gmail.com.

Re: Hosting requests for similar projects

[Slide]

Any other feedback for this?

On Tue, Dec 22, 2020 at 12:01 PM Tim Jacomb  wrote:

> agree would be great if they could be merged
>
> and also the jenkins core (and winstone) CLI enhanced with a more modern
> CLI library
>
> On Tue, 22 Dec 2020 at 18:13, Slide  wrote:
>
>> Hi Everyone,
>>
>> Currently we have two hosting requests open (
>> https://issues.jenkins.io/projects/HOSTING/issues/HOSTING-1048 and
>> https://issues.jenkins.io/projects/HOSTING/issues/HOSTING-1046) for CLI
>> tools that interact with Jenkins. I would like to get some feedback on
>> ideas on how to move forward on these requests. They were filed nearly the
>> same day and from my understanding provide similar features. I am not
>> against hosting both, but would really rather have people work on one
>> solution to make it better.
>>
>> Let me know what you think.
>>
>> Regards,
>>
>> Alex
>>
>> --
>> 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/CAPiUgVcy%3D75a2vRdK6Vv_NVfp%2Bn%2BhoHg8LykhxvKXZ-XVNySNQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcy%3D75a2vRdK6Vv_NVfp%2Bn%2BhoHg8LykhxvKXZ-XVNySNQ%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/CAH-3Biei4Dh4aii0m7KPDtAQ9B8rmuFzVDpsGW3JqLQBoQed%2BA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Biei4Dh4aii0m7KPDtAQ9B8rmuFzVDpsGW3JqLQBoQed%2BA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVePJo5CNLhd1HJbd71GvOXxsUHQ_K0WKeET-C%2BfdHD70g%40mail.gmail.com.

Hosting requests for similar projects

[Slide]

Hi Everyone,

Currently we have two hosting requests open (
https://issues.jenkins.io/projects/HOSTING/issues/HOSTING-1048 and
https://issues.jenkins.io/projects/HOSTING/issues/HOSTING-1046) for CLI
tools that interact with Jenkins. I would like to get some feedback on
ideas on how to move forward on these requests. They were filed nearly the
same day and from my understanding provide similar features. I am not
against hosting both, but would really rather have people work on one
solution to make it better.

Let me know what you think.

Regards,

Alex

-- 
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/CAPiUgVcy%3D75a2vRdK6Vv_NVfp%2Bn%2BhoHg8LykhxvKXZ-XVNySNQ%40mail.gmail.com.

Re: Discussion - Plugins reporting issue trackers

[Slide]

ssing issues
> [MISSING] workplace-notifier is missing issues
> [MISSING] zapper is missing issues
>
> On Sun, Dec 20, 2020 at 10:26 PM Gavin Mogan  wrote:
>
>> I love the idea but I'll put changing the directory structure to those in
>> charge of infra it doesn't break anything
>>
>> However adding new fields won't break things so I'm dusting off some
>> groovy skills to make a POC
>>
>> On Sat., Dec. 19, 2020, 3:52 p.m. Tim Van Holder, <
>> tim.vanhol...@gmail.com> wrote:
>>
>>> If tweaking and renaming RPU, maybe also tweak the directory structure?
>>>
>>> For example, changing
>>> permissions/plugin-groovy-events-listener-plugin-master.yml to
>>> permissions/plugin/g/groovy-events-listener-plugin-master.yml
>>>
>>> This would make it a lot easier to browse on GH, which now truncates to
>>> 1000 items.
>>>
>>>
>>> On Fri, 18 Dec 2020 at 23:28, slide  wrote:
>>>
>>>> I think adding this information to the permissions files would be
>>>> really nice. I'd need to update the bot for the hosting process, so just
>>>> let me know what the syntax will be and I can get it place.
>>>>
>>>> On Thursday, December 17, 2020 at 3:20:47 PM UTC-7 Daniel Beck wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 17. Dec 2020, at 23:01, 'Gavin Mogan' via Jenkins Developers <
>>>>> jenkin...@googlegroups.com> wrote:
>>>>> >
>>>>> > If a repo has github issues enabled, assume it uses that.
>>>>> > else If the plugin name has a jira component, assume it uses that.
>>>>> > else no issues link
>>>>>
>>>>> The beauty of the one time mass definition of issue trackers is that
>>>>> it can be arbitrarily sophisticated (read: convoluted and manual), since 
>>>>> we
>>>>> don't need to re-run it once every 4 minutes on trusted.ci.
>>>>>
>>>>> Component name in Jira doesn't *exactly* match the plugin ID? No
>>>>> problem if I can match them up in a giant table. GH issues is enabled but
>>>>> has 0 total issues ever reported? Probably not relevant (and could even be
>>>>> disabled). Same with Jira components that could be deleted if 0 issues
>>>>> exist. But not both though. Plus we can purge Jira components without a
>>>>> corresponding published plugin (I already know these exist, it's great…).
>>>>>
>>>>> My desire to get this right, and a lack of spare time over the last
>>>>> 1-2 months has delayed this however :-/ Perhaps over the upcoming 
>>>>> vacation.
>>>>>
>>>>> If others are willing to help with this, I can set something up for us
>>>>> to collaborate.
>>>>>
>>>>> > or to daniel's point (might be on the github draft PR), do we want
>>>>> to make it a hash style to support plugins that do both? Its not likely
>>>>> that a plugin will want two, but during a transitory period, it might be
>>>>> worth listing both
>>>>>
>>>>> FTR I wrote about that in
>>>>> https://github.com/jenkins-infra/plugin-site-api/pull/97#discussion_r544167455
>>>>> and
>>>>> https://github.com/jenkins-infra/plugin-site-api/pull/97#issuecomment-747316256
>>>>> -- some plugins do this deliberately. We also need to distinguish issue
>>>>> tracker references for reporting new issues (one tracker is likely
>>>>> preferred / enough to reference) and issue tracker references for existing
>>>>> issues (probably everything with open issues should be included, or even
>>>>> closed issues, depending on how it's used).
>>>>>
>>>>> While the vast majority of plugins will have a single tracker and
>>>>> that's it, GH issues seems to become more popular as well, and since that
>>>>> genie's out of the bottle by now, we should have proper support for folks
>>>>> wanting to switch over.
>>>>>
>>>>> > As a side note, it would be super easy to use that data to also fix
>>>>> SCM, so that things like the blueocean sub modules would have the right 
>>>>> scm
>>>>> links since its already part of the metadata -
>>>>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-antisamy-markup-

Re: Discussion - Plugins reporting issue trackers

[slide]

I think adding this information to the permissions files would be really 
nice. I'd need to update the bot for the hosting process, so just let me 
know what the syntax will be and I can get it place.

On Thursday, December 17, 2020 at 3:20:47 PM UTC-7 Daniel Beck wrote:

>
>
> > On 17. Dec 2020, at 23:01, 'Gavin Mogan' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
> > 
> > If a repo has github issues enabled, assume it uses that.
> > else If the plugin name has a jira component, assume it uses that.
> > else no issues link
>
> The beauty of the one time mass definition of issue trackers is that it 
> can be arbitrarily sophisticated (read: convoluted and manual), since we 
> don't need to re-run it once every 4 minutes on trusted.ci.
>
> Component name in Jira doesn't *exactly* match the plugin ID? No problem 
> if I can match them up in a giant table. GH issues is enabled but has 0 
> total issues ever reported? Probably not relevant (and could even be 
> disabled). Same with Jira components that could be deleted if 0 issues 
> exist. But not both though. Plus we can purge Jira components without a 
> corresponding published plugin (I already know these exist, it's great…).
>
> My desire to get this right, and a lack of spare time over the last 1-2 
> months has delayed this however :-/ Perhaps over the upcoming vacation.
>
> If others are willing to help with this, I can set something up for us to 
> collaborate.
>
> > or to daniel's point (might be on the github draft PR), do we want to 
> make it a hash style to support plugins that do both? Its not likely that a 
> plugin will want two, but during a transitory period, it might be worth 
> listing both
>
> FTR I wrote about that in 
> https://github.com/jenkins-infra/plugin-site-api/pull/97#discussion_r544167455
>  
> and 
> https://github.com/jenkins-infra/plugin-site-api/pull/97#issuecomment-747316256
>  
> -- some plugins do this deliberately. We also need to distinguish issue 
> tracker references for reporting new issues (one tracker is likely 
> preferred / enough to reference) and issue tracker references for existing 
> issues (probably everything with open issues should be included, or even 
> closed issues, depending on how it's used).
>
> While the vast majority of plugins will have a single tracker and that's 
> it, GH issues seems to become more popular as well, and since that genie's 
> out of the bottle by now, we should have proper support for folks wanting 
> to switch over.
>
> > As a side note, it would be super easy to use that data to also fix SCM, 
> so that things like the blueocean sub modules would have the right scm 
> links since its already part of the metadata - 
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-antisamy-markup-formatter.yml#L3
>
> That's a great point. Correct; right now, update-center2 does not use RPU 
> metadata at all, but would need it anyway once we define the issue tracker 
> location there, so this should be a straightforward change on top.
>
> (Once we do this it's probably time to rename RPU to 'component-metadata' 
> or similar, and move the permissions script out of it. IIUC we already have 
> incrementals relying on it as well, that's what the 'github' field is for. 
> What blocked this so far is the terrible file format that badly needs an 
> overhaul as well to also better support the idea of a "plugin" 
> semantically. So much to do, so little time :-( )
>
>

-- 
You received this message because you 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/048d3dab-7389-48d5-957e-7945dbb4a7c4n%40googlegroups.com.

Re: Jenkins 3.x

[Slide]

I would also prefer some date based release numbering a la IntelliJ rather
than semantic versioning, for all the reasons that Jesse has spelled out.

On Mon, Nov 30, 2020 at 2:45 PM Jesse Glick  wrote:

> I do not think switching to a 3.x version number accomplishes much of
> anything (even if we had done so several weeks ago, when the big
> changes were landing). I would much rather see Jenkins switch to
> either a date-based scheme, or just some opaque incrementing number
> like we have but without the meaningless `2.` prefix. Jenkins releases
> break compatibility for someone, somehow, all the time; a number tells
> you nothing about whether _you_ will be affected. We need to publish
> clear, concise upgrade guides; encourage users to make backups or use
> a config-as-code workflow; and of course try as hard as we can to not
> break compatibility to begin with! In the case of JEP-227 & JEP-228
> there have already been extensive plugin fixes released and few users
> should actually be affected. Tables-to-divs has apparently caused more
> regressions, but these should all be fixable long before the LTS.
>
> In theory SemVer could be useful for libraries. In practice it seems
> like a false promise to me. It is your tests which will tell you if an
> upgrade is compatible, not some upstream maintainer’s fantasy.
> Dependabot actually _keeps score_ and tells you whether a given update
> broke CI for other people, which seems like far more valuable
> information.
>
> --
> You received this message because you 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/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com
> .
>


-- 
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/CAPiUgVfmdhs-_yOpiWAwsgeocz_Mu6U1xD8xuq0m1m-7XBEO8g%40mail.gmail.com.

Re: Jenkins Governance Meeting, Nov 18, 2020

[Slide]

Hi Oleg,

First, my sincere apologies for not being at the meeting and making you
stay at the office away from your family. Family is super important to me
and that time is very important and I am sorry I didn't respond to let you
know that I wouldn't be at the meeting. After the recent daylight saving
time change, I have a work meeting conflict every week now. I have updated
my availability for the rest of the meetings that I will not be able to
attend.

Regards,

Alex

On Thu, Nov 19, 2020 at 1:37 AM Tim Jacomb  wrote:

> The time also means I cant attend, so +1 for reviewing another time
>
> On Thu, 19 Nov 2020 at 08:18, Oleg Nenashev 
> wrote:
>
>> As discussed a few months ago, we will revise the meeting time once the
>> 2020 elections are over
>> Since we have candidates from APAC, the meeting approach may require
>> significant changes, not just choosing the least worst timeslot for everyone
>>
>> On Thu, Nov 19, 2020 at 9:14 AM 'Olblak' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> Hi  Oleg,
>>>
>>> I am sorry to hear about that, that time is definitely really bad for me
>>> as well.
>>>
>>> On Wed, Nov 18, 2020, at 7:15 PM, Oleg Nenashev wrote:
>>>
>>> The meeting did not happen, because it was only me on the call. I kindly
>>> ask board members and officers to reject the meeting invitations in their
>>> calendars if they do not plan to attend. The timing for these meeting is
>>> quite bad for me, and it puts pressure on my family obligations. If I know
>>> that nobody plans to join in advance, I won't be staying in the office for
>>> a few extra hours, and spend them with my family instead. Thanks for
>>> understanding.
>>>
>>> On Wednesday, November 18, 2020 at 6:10:33 PM UTC+1 Oleg Nenashev wrote:
>>>
>>> Hi all,
>>>
>>> In 1 hour we will have a regular Jenkins Governance Meeting (starts at
>>> 6PM UTC). Everyone is welcome to join us and to participate in the
>>> discussion. Meeting link:
>>> https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09
>>>
>>> Draft agenda:
>>>
>>>- News!
>>>- Jenkins elections status update
>>>- LTS schedule update
>>>- Google Summer of Code 2021
>>>- Jenkins K8s Operator updates
>>>
>>> If you would like to add more topics, please suggest changes here
>>> 
>>> .
>>>
>>> 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/18072109-74c2-4cd6-9faf-15c04700826bn%40googlegroups.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/4v01zfG5moM/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/d6468cf2-40c4-47b5-94a1-24f1e1e42b74%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/CAPfivLBcjSGSsUaipgGNeAW25XteH%2BnPrx-MDc2j0GU6AZN6Og%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-3BiecZ0S-s2RXZaZtVEL6RrA8eY-Bi--t-ipzFi%2BaGcebHA%40mail.gmail.com
> 
> .
>


-- 
Website: http://earl-of-code.com

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

Re: New Jenkins Operator for kubernetes: repository request creation: simple-jenkins-operator

[Slide]

Do we want them to go through the normal hosting process?

On Wed, Nov 11, 2020, 16:32 Victor Martinez 
wrote:

> +1 That's brilliant!
>
> On Wednesday, 11 November 2020 at 22:20:41 UTC Oleg Nenashev wrote:
>
>> I will create the new repository tomorrow if there is no negative
>> feedback in this thread
>>
>> On Wed, Nov 11, 2020 at 10:23 PM slide  wrote:
>>
>>> +1
>>>
>>> On Wednesday, November 11, 2020 at 1:52:11 PM UTC-7 ullrich...@gmail.com
>>> wrote:
>>>
>>>> +1 from me as well
>>>>
>>>> Am 11.11.2020 um 21:41 schrieb Mark Waite :
>>>>
>>>> +1 from me.
>>>>
>>>> On Wed, Nov 11, 2020 at 1:38 PM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Hi all, any additional feedback about the hosting request?
>>>>>
>>>>> Thanks in advance,
>>>>> Oleg
>>>>>
>>>>> On Wednesday, November 11, 2020 at 8:18:43 AM UTC+1 Oleg Nenashev
>>>>> wrote:
>>>>>
>>>>>> It is me who asked for a developer mailing list thread. There is no
>>>>>> problem with the hosting itself, I can create repos when there is a
>>>>>> consensus. I asked for a more public process (not so many contributors
>>>>>> watch HOSTING), because it is a follow-up to the Jenkins Kubernetes
>>>>>> Operator: Open Governance Proposal
>>>>>> <https://groups.google.com/g/jenkinsci-dev/c/OA5nb_SAgh0/m/q8SSKE1UAwAJ> 
>>>>>> that
>>>>>> got stuck due to the lack of public response from Virtus Lab. As 
>>>>>> discussed
>>>>>> at the governance board meetings in August and October, hosting a new
>>>>>> operator is an alternative to getting the upstream
>>>>>> https://github.com/jenkinsci/kubernetes-operator unblocked. So this
>>>>>> request basically applies an alternate plan.
>>>>>>
>>>>>> I am +1 for hosting a new operator, because I see no clear way for
>>>>>> unblocking https://github.com/jenkinsci/kubernetes-operator. We got
>>>>>> some private response from Virtus Lab to the Jenkins Board on Oct 16, 
>>>>>> but I
>>>>>> have no permission to share it. Although this response is somewhat
>>>>>> promising, it does not immediately unblocks contributions to the
>>>>>> repository. There is no public response from Virtus Lab as they intended 
>>>>>> to
>>>>>> do, and there is little activity in the repository. Although there is a
>>>>>> declared intent to introduce changes in November, I am not sure it is .
>>>>>> Having an alternate repository is how we could unblock contributors while
>>>>>> we keep communicating with Virtus Lab and trying to unlock the upstream.
>>>>>>
>>>>>> No strong opinion about naming
>>>>>>
>>>>>> Best regards,
>>>>>> Oleg
>>>>>>
>>>>>> On Tuesday, November 10, 2020 at 6:44:15 PM UTC+1
>>>>>> ga...@gavinmogan.com wrote:
>>>>>>
>>>>>>> You need to open a hosting jira ticket.
>>>>>>>
>>>>>>> https://www.jenkins.io/doc/developer/publishing/requesting-hosting/
>>>>>>>
>>>>>>> And that'll create everything for you (repo, team, etc)
>>>>>>>
>>>>>>>
>>>>>>> On Tue., Nov. 10, 2020, 9:33 a.m. Akram Ben Aissi, <
>>>>>>> aben...@redhat.com> wrote:
>>>>>>>
>>>>>>>> Hi Jenkins Devs,
>>>>>>>>
>>>>>>>> I am delighted to announce the creation of a new Jenkins Operator
>>>>>>>> for kubernetes under the name "Simple Jenkins Operator".
>>>>>>>>
>>>>>>>> A kubernetes operator is kubernetes native component that is able
>>>>>>>> to install, manage and operate applications running in kubernetes.
>>>>>>>>
>>>>>>>> Hence, the Simple Jenkins Operator will provide a simple and
>>>>>>>> straightforward experience to allow installation, management, upgrade 
>>>>>>>> and
>>>>>>>> backup of Jenkins when it is running in kubernetes.

Re: New Jenkins Operator for kubernetes: repository request creation: simple-jenkins-operator

[slide]

+1

On Wednesday, November 11, 2020 at 1:52:11 PM UTC-7 ullrich...@gmail.com 
wrote:

> +1 from me as well
>
> Am 11.11.2020 um 21:41 schrieb Mark Waite :
>
> +1 from me.
>
> On Wed, Nov 11, 2020 at 1:38 PM Oleg Nenashev  wrote:
>
>> Hi all, any additional feedback about the hosting request?
>>
>> Thanks in advance,
>> Oleg
>>
>> On Wednesday, November 11, 2020 at 8:18:43 AM UTC+1 Oleg Nenashev wrote:
>>
>>> It is me who asked for a developer mailing list thread. There is no 
>>> problem with the hosting itself, I can create repos when there is a 
>>> consensus. I asked for a more public process (not so many contributors 
>>> watch HOSTING), because it is a follow-up to the Jenkins Kubernetes 
>>> Operator: Open Governance Proposal 
>>>  
>>> that 
>>> got stuck due to the lack of public response from Virtus Lab. As discussed 
>>> at the governance board meetings in August and October, hosting a new 
>>> operator is an alternative to getting the upstream 
>>> https://github.com/jenkinsci/kubernetes-operator unblocked. So this 
>>> request basically applies an alternate plan.
>>>  
>>> I am +1 for hosting a new operator, because I see no clear way for 
>>> unblocking https://github.com/jenkinsci/kubernetes-operator. We got 
>>> some private response from Virtus Lab to the Jenkins Board on Oct 16, but I 
>>> have no permission to share it. Although this response is somewhat 
>>> promising, it does not immediately unblocks contributions to the 
>>> repository. There is no public response from Virtus Lab as they intended to 
>>> do, and there is little activity in the repository. Although there is a 
>>> declared intent to introduce changes in November, I am not sure it is . 
>>> Having an alternate repository is how we could unblock contributors while 
>>> we keep communicating with Virtus Lab and trying to unlock the upstream.
>>>
>>> No strong opinion about naming
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Tuesday, November 10, 2020 at 6:44:15 PM UTC+1 ga...@gavinmogan.com 
>>> wrote:
>>>
 You need to open a hosting jira ticket.

 https://www.jenkins.io/doc/developer/publishing/requesting-hosting/

 And that'll create everything for you (repo, team, etc)


 On Tue., Nov. 10, 2020, 9:33 a.m. Akram Ben Aissi,  
 wrote:

> Hi Jenkins Devs,
>
> I am delighted to announce the creation of a new Jenkins Operator for 
> kubernetes under the name "Simple Jenkins Operator".
>  
> A kubernetes operator is kubernetes native component that is able to 
> install, manage and operate applications running in kubernetes.
>
> Hence, the Simple Jenkins Operator will provide a simple and 
> straightforward experience to allow installation, management, upgrade and 
> backup of Jenkins when it is running in kubernetes.
>
> This projects comes into an alternative to the first Jenkins Operator 
> namely jenkinsci/kubernetes-operator and aims to provide a simpler user 
> experience by using more kubernetes native component.
>
> Our first version will be 0.7.0 and will be compatible with 
> operator-sdk 1.0.1 .
> Please, jenkins board member, could you please create a repository 
> named (jenkinsci/simple-jenkins-operator) so we can push our existing 
> code 
> base there.
>
> Of course, contributions are welcome, and we really want an open 
> govervnance for the very start, so any individual or enterprise 
> contributor 
> is welcome.
>
> greetings
>
>
>
>
>
> -- 
>
> AKRAM BEN AISSI
>
> PRINCIPAL SOFTWARE ENGINEER
>
>  
>
> M: +33.6.31.57.08.60T: @akrambenaissi 
> 
>
> E: aben...@redhat.com#: Akram  
>
>
>
> -- 
> You received this message because you 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/CAFkVfmPwBguuhsjAsbAOYKRtn287Zf%2BKjT4oFwd6NTQ-wTb%3DBA%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-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/3b769e3f-e17f-41c3-838c-9ffed782e1b4n%40googlegroups.com
>>  
>> 

Re: Request to be added as Twitter admin

[Slide]

Big +1

On Wed, Oct 21, 2020 at 11:06 AM Arnaud Héritier 
wrote:

> +1
>
> Le mer. 21 oct. 2020 à 19:48, Marky Jackson  a
> écrit :
>
>> +1 from me
>>
>>
>> On Oct 21, 2020, at 10:47 AM, Alyssa Tong  wrote:
>>
>> Hello,
>>
>> I'd like to request to be added as admin for Twitter so I may help with
>> tweets.  I am currently the Events officer for the project and driving the
>> Jenkins is the Way initiative.
>>
>> Thank you,
>> 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/CAC9wNazqRzr2O-jFtXV7b6KGOnDk3kPVnysnQJH60XrMotODhA%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/18210F7C-E9F9-4181-B6F1-6CFBA01A87C1%40gmail.com
>> 
>> .
>>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9PZpYa44dr5voNi-addBfxiBKnmLvMiFQ%2Bw4RzGn5G_g%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVeLW04B8UyeZvV1c4AOXw153v8OEqiB7WO%3DEYg5CcK%3Dbg%40mail.gmail.com.

Plugins up for adoption

[Slide]

Hi Everyone,

As part of my stepping back from Jenkins a bit, I am no longer going to be
maintaining the following plugins. I have put the "adopt-this-plugin" on
the repos. Please CC me in a request for permissions and I will be glad to
hand them over if someone is interested in taking over maintenance.

https://github.com/jenkinsci/mailmap-resolver-plugin
https://github.com/jenkinsci/validating-string-parameter-plugin
https://github.com/jenkinsci/webhook-step-plugin
https://github.com/jenkinsci/email-ext-plugin
https://github.com/jenkinsci/change-assembly-version-plugin
https://github.com/jenkinsci/emailext-template-plugin

I will still maintain the figlet-buildstep and token-macro plugins

Regards,

Alex

-- 
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/CAPiUgVduky5Xb2BwjtNwEMM4zH0yU7qdNS06UX7ifoXs%3D%2BHTbA%40mail.gmail.com.

Re: Jenkins Operator (aka kubernetes-operator) Community Project's Governance: Request for Revision

[slide]

FYI, I made contact with some folks at VirtusLabs. They are hoping to 
respond to this discussion thread in the next little while. I will keep on 
top of it an communicate with to keep the ball rolling. 

On Thursday, August 27, 2020 at 7:56:36 AM UTC-7 aben...@redhat.com wrote:

> *Background*
>
> In mid-october 2019, Jenkins on OpenShift developers team from Red Hat 
> started to engage in the jenkinsci/kubernetes-operator 
>  (aka Jenkins Operator) 
> as contributors and committers. The initiators of the project are 
> contributors from VirtusLab company.
>
>  After a few commits related to documentation and minor bug fixes, the 
> team, backed by product management, expressed their wish to engage more in 
> the community and the project.
>
>  To facilitate communication and collaboration, several rituals has been 
> put in place by Red Hat team members:
>
>- 
>
>Subscribing to the slack channel on virtuslab's instance and providing 
>best effort community support to the users who were asking.
>- 
>
>Scheduling a developer call each week to discuss developer related 
>issues and ways to improve the software. Several additional stakeholders 
>from Red Hat, who were strongly interested in extending Jenkins features 
>were able to join (to name a few, J.F, R. Crisp, S. Bose, )
>- 
>
>A weekly community call to allow users to talk about their use of the 
>plugin and features they would like to see. If not enough users were 
>joining, which was often the case, this call was used to discuss 
>architecture and development topics.
>
>  After months, discrepancies arose, especially regarding architecture and 
> design. At the same time, contributing features was harder both for 
> technical reasons (monolithic operator) and for governance reasons (Red Hat 
> developers didn't have commit permissions).
>
> Despite these difficulties, Red Hat management insisted in remaining 
> engaged in a community based operator and to continue the contributions, 
> and also engage in larger refactoring tasks. Red Hat committers asked 
> several times to have commit permissions. Initially, these requests have 
> been rejected by invoking the will to keep control on the code quality. 
> After several months of discussions, and difficult collaboration, Red Hat 
> team members engagement was constant but commit permissions were still 
> refused.
>
>  Then, during a period of around 2 months and related to personal reasons, 
> the main committer was not able to validate PRs, nor letting the other 
> contributors be able to do it. The project was and is almost frozen.
>
>  Red Hat is escalating the discussion to the Jenkins CI board to see how 
> to solve this issue. As it was discussed as there is no existing process in 
> place for transferring permissions when a component maintainer explicitly 
> rejects that. Red Hat is asking to set up a governance that complies with 
> the Jenkins Code of Conduct and allows Open Source friendly collaboration.
>
>
> *Governance revision proposal*
>
> The proposed governance has a main objective  to ensure permanently that a 
> distribution of the commit rights across the active stakeholders of the 
> project always exists. The definition of "active stakeholder" can be 
> defined more accurately by the project board. But, as an initial proposal, 
> an active stakeholder can be defined as:
>
> "An entity contributing to the project in any form within the last 3 
> months would be by submitting code, committing code, proposing PRs and 
> documentation or participating actively on a regular basis in the community 
> calls".
>
> We can add to this group any active user who can submit a minimum amount 
> of documented and reproducible issues.
>
>
> Initial working group leaders are defined using the following requirements:
>
>- 
>
>Initial leadership group consists of 3 or 5 members
>- 
>
>Founding parties: Virtus Lab, Red Hat, Jenkins Governance Board
>- 
>
>Each party nominates a representative
>- 
>
>Domination prevention: there should be no party having more than 50% 
>of working group members.
>
>  
>
> The governance charter needs to define a few engagements and entities:
>
>- 
>
>Scope of rights and responsibilities explicitly held by the committee
>- 
>
>Committee structure that meets the requirements above
>- 
>
>Election process, including:
>- 
>   
>   special elections in the case someone resigns or is impeached
>   - 
>   
>   who is eligible to nominate candidates and how
>   - 
>   
>   who is eligible to run as a candidate
>   - 
>   
>   Voter registration and requirements
>   - 
>   
>   election mechanics such as
>   - 
>  
>  committee company representation quotas
>  - 
>  
> 

Re: Trademark sublicense request: TechMatrix Jenkins Support

[Slide]

Agreed on the approval and possible recommendations. It would be good to
start following the Linux FDN for these things.

On Tue, Oct 13, 2020 at 2:22 PM Oleg Nenashev 
wrote:

> Hello,
>
> It worth mentioning that the "CompanyName Jenkins Support" naming pattern
> has been approved a few years ago for CloudBees Jenkins Support:
> https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage . Based
> on this precedent, I am +1 for approving the current trademark request for
> "TechMatrix Jenkins Support".
>
> My personal preference would be to follow the Linux Foundation trademark
> usage patterns ,. In
> such case the name would be "TechMatrix Support for Jenkins", "TechMatrix
> Enterprise Support for Jenkins" or something like that.
>
> Best regards,
> Oleg Nenashev
>
> On Friday, October 9, 2020 at 4:51:06 PM UTC+2 mind.the...@gmail.com
> wrote:
>
>> This is Yuji from TechMatrix, a distributor of CloudBees products in Japan
>>
>>
>>
>> I'd like to request the permission to use the following name that uses
>> "Jenkins" in it:
>>
>> "TechMatrix Jenkins Support"
>>
>>
>>
>> The following is the brief introduction of what we are trying to launch
>> is; TechMatrix Jenkins Support is a technical support service for Jenkins
>> by our certified Jenkins engineers(CCJE).
>>
>> We provide technical support as below via email to our customers who have
>> challenges to use Jenkins.
>>
>> - teaching how to use/manage Jenkins
>>
>> - helping their trouble shooting
>>
>>
>>
>> If you need more detailed information, please let me know.
>>
>>
>>
>> FYI, 2 years ago, Mr. Kohsuke Kawaguchi posted the following on behalf of
>> us and we got approval to use "TechMatrix Jenkins Platform Package for X"
>>
>> https://groups.google.com/g/jenkinsci-dev/c/VysVavIJCnc/discussion
>>
>>
>>
>> Best Regards,
>>
>> Yuji Tachibana
>>
>> TechMatrix Corp.
>>
> --
> You received this message because you 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/8603bc82-d2a0-490f-a916-976fdd990427n%40googlegroups.com
> 
> .
>


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

Re: [PROPOSAL] Unforking XStream

[Slide]

This would be awesome, +1!

On Mon, Oct 12, 2020 at 2:08 PM Jesse Glick  wrote:

> See https://github.com/jenkinsci/jep/pull/309 for details. The core PR
> has been prepared, along with PRs to a number of plugins which require
> modification to be compatible. (All of those PRs can and should be
> merged & released in advance of the core change.) I am hoping to get
> this merged after the next LTS baseline has been cut, if there are no
> objections.
>
> --
> You received this message because you 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/CANfRfr1P2izJbsRE%2BCyA8NQgWkdTFPyaBZsXTTywKpeSNBafLw%40mail.gmail.com
> .
>


-- 
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/CAPiUgVfw-g%3DJBNGeUtP5kVA9GVqL3SuZ2u185K4MFvNdDoCk6g%40mail.gmail.com.

Re: How to use TokenMacro with key/value pairs

[Slide]

Are you just wanting token-macro to expand tokens in a string, or is there
more to what you want to do?

On Fri, Oct 2, 2020 at 11:37 AM Andrew Grimberg <
agrimb...@linuxfoundation.org> wrote:

> I'm trying to extend the config-file-provider in support of
> https://issues.jenkins-ci.org/browse/JENKINS-43204
>
> My thoughts are to utilize the token-macro plugin to do the expansion,
> especially since it's already a dependency of the config-file-provider
>
> Unfortunately, I'm not a strong Java developer. I work mostly in Perl
> and a little bit of Python so I feel I'm failing to figure out how to do
> this correctly. I see no way to instantiate a TokenMacro (or
> DataBoundTokenMacro) object with a key / value pair such that I can
> create a List to pass to TokenMacro.expand to do the actual
> work.
>
> My intent is to either extend the custom file type itself to support
> defined credentials that get automatically expanded in the configuration
> file, or a brand new file type that does this.
>
> At this point, I've basically cloned the properties file type which
> allows me to define tokenized credentials and just write them back out
> to the file when the file gets rendered to disk. Now I'm trying to take
> the next step and actually convert those into something that TokenMacro
> can then expand for me in the defined file but as I said, I'm failing to
> figure out how instantiate the object.
>
> If I'm going about this all wrong, I would love to know that too, but
> this seems like it should be fairly straight forward to me to leverage
> this.
>
> -Andy-
>
> --
> You received this message because you 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/40f71460-348d-2cca-17a1-96f10a325020%40linuxfoundation.org
> .
>


-- 
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/CAPiUgVe2Kzx5mNBH0PVgVJ%2B2Sb0wdP4EDtP8JE%2BcBaMjEKPYaQ%40mail.gmail.com.

Re: Proposal: Hosting Jenkinsfile Runner "Image packs" in jenkinsci

[Slide]

Hi Oleg,

I think it would be gre a t to host it in the jenkinsci org. I think the
name is fine as well.

Regards,

Alex

On Fri, Oct 2, 2020, 05:50 Oleg Nenashev  wrote:

> Hi all,
>
> I am currently working on Jenkinsfile Runner
>  and finalizing the key
> feature requests towards the 1.0 release. One of the common use-cases is
> having community-provided images which would support common pipelines, e.g.
> building Java projects with Maven (issue #344
> ). We already
> have similar images for inbound agents (jenkinsci/jnlp-agents
> ). Jenkins X 1.x also included
> multiple images for Jenkinsfile Runner in jenkins-x/jenkins-x-serverless
> .
>
> I have created a first image for Maven/JDK8 in
> oleg-nenashev/jenkinsfile-runner-image-packs
> . It is
> based on ci.jenkins.io-runner, but without Jenkins-specific magic. Would
> appreciate feedback and contributions. A few questions to others:
>
>- *Hosting.* I would like to move this repository to the jenkinsci
>GitHub organization so that the repo could be accessible to users and
>contributors there. Would othersbe fine with that?
>- *Terminology*. I currently use the "Image Pack" terminology. Similar
>repositories use "Buildpacks" in Jenkins X and K8s, "Convenience Images"
>from CircleCI. I do not want to use "buildpacks" to avoid
>possible confusion with https://buildpacks.io/ . If anyone has ideas
>about better naming, would appreciate them.
>
> Any other feedback will be also appreciated.
>
> Thanks for your time,
> 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/CAPfivLAa5pC8rMBwLPM8LHtWzUC_y1W2R6O1p1CFwJC9HM8RHQ%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/CAPiUgVf%3DC-3otZWPVkq23JRroGE6p%2BwycxC3PTf1_2buTv3RpQ%40mail.gmail.com.

Re: Governance Board

[Slide]

Please note, this does not mean that I won't be helping out and submitting
PR's and stuff. I'll still be around :-)

On Wed, Sep 30, 2020 at 11:55 PM 'Olblak' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hi Alex,
>
> Congratulation on your new role change and thanks for all the things you
> did.
> I really enjoyed working with you.
>
> Mmmmh I'll better find a windows expert to protect my mental health :D
>
>
> First of all, thanks a lot for all your contributions to the Jenkins
> project! You've been doing A LOT for the community as a governance board
> member, and it is much appreciated. I totally understand your decision,
> and I am looking forward to continue working with you on other areas of the
> Jenkins community . I will do my best to assist with whatever transition
> steps required for the board member role and other roles if you decide to
> step down from them.
>
> Best wishes to you in the new role!
>
> Best regards.,
> Oleg
> On Monday, September 28, 2020 at 8:07:25 PM UTC+2 slide wrote:
>
> Thanks Marky!
>
>
> On Mon, Sep 28, 2020 at 10:36 AM Marky Jackson 
> wrote:
>
> I want to thank you for all that you have given to this community while
> being on the board Alex. Your commitment is so valued and I am personally
> so thankful for you.
>
> On Monday, September 28, 2020 at 10:31:24 AM UTC-7 slide wrote:
>
> Hi Everyone,
>
> Just wanted to send out an email announcing that I will be resigning from
> the Jenkins Governance Board after a one year term (instead of two years).
> This will open up two spots for Governance Board members during the
> elections this year. My role at work is changing and I will not have the
> time to work on Jenkins as much as I would like. I feel that other people
> who do have the time would be more of a benefit to the project and
> community.
>
> Thanks!
>
> Alex Earl
>
> --
> 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-de...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/18afcc45-edd6-4ee8-ad54-fd94f54fbb44n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/18afcc45-edd6-4ee8-ad54-fd94f54fbb44n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>
> --
> 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/f0c87d20-e7b6-4f2e-9b1c-74f0a7fd8865n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/f0c87d20-e7b6-4f2e-9b1c-74f0a7fd8865n%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/8a22bff2-7943-48c7-8adc-63ec2ca58654%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/8a22bff2-7943-48c7-8adc-63ec2ca58654%40www.fastmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVdDLq2C_ScP5ZDU3JevpaknCXPDSdzbwuXN03y%2B98gXQQ%40mail.gmail.com.

Re: Governance Board

[Slide]

Thanks Marky!

On Mon, Sep 28, 2020 at 10:36 AM Marky Jackson 
wrote:

> I want to thank you for all that you have given to this community while
> being on the board Alex. Your commitment is so valued and I am personally
> so thankful for you.
>
> On Monday, September 28, 2020 at 10:31:24 AM UTC-7 slide wrote:
>
>> Hi Everyone,
>>
>> Just wanted to send out an email announcing that I will be resigning from
>> the Jenkins Governance Board after a one year term (instead of two years).
>> This will open up two spots for Governance Board members during the
>> elections this year. My role at work is changing and I will not have the
>> time to work on Jenkins as much as I would like. I feel that other people
>> who do have the time would be more of a benefit to the project and
>> community.
>>
>> Thanks!
>>
>> Alex Earl
>>
>> --
>> 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/18afcc45-edd6-4ee8-ad54-fd94f54fbb44n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/18afcc45-edd6-4ee8-ad54-fd94f54fbb44n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVc3DGd%3DKrJ204A8MRJynnM-WSQxvqfFpTBSO8XAnBX%3D_g%40mail.gmail.com.

Governance Board

[Slide]

Hi Everyone,

Just wanted to send out an email announcing that I will be resigning from
the Jenkins Governance Board after a one year term (instead of two years).
This will open up two spots for Governance Board members during the
elections this year. My role at work is changing and I will not have the
time to work on Jenkins as much as I would like. I feel that other people
who do have the time would be more of a benefit to the project and
community.

Thanks!

Alex Earl

-- 
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/CAPiUgVfOFbWFOaXZuXOkMbtPzOHLTD-EBzF%2BDj5xCO3cmzK0YQ%40mail.gmail.com.

Re: Jenkins 2020 Board and Officer elections - process changes discussion

[Slide]

+1 from me for sure

On Tue, Sep 22, 2020 at 3:16 AM Oleg Nenashev 
wrote:

> I have started working on the announcements. Does everyone agree with the
> suggested dates?
>
> On Friday, September 18, 2020 at 2:58:12 PM UTC+2 Oleg Nenashev wrote:
>
>> As agreed at the Sep 16 governance meeting (meeting notes
>> 
>> , video ), the suggested changed
>> are approved in principle, but there are some changes which might be
>> requied during the final process documentation review. Any feedback will be
>> appreciated : https://github.com/jenkins-infra/jenkins.io/pull/3712  .
>>
>> This pull request also includes the suggested dates:
>>
>>- Sep 24 - Nominations open, Voting sign-up begins
>>- Oct 15 - Nominations deadline
>>   - After the deadline, the election committee will process
>>   nominations and reach out to candidates in order
>>- Oct 22: Election candidates are published, including personal
>>statements
>>- Nov 02: Voting sign-up is over
>>   - After this date, the election committee will verify the sign-up
>>   and prepare the final list of voters
>>- Nov 10: Voting begins
>>   - Email is distributed to all registered voters through Condorcet
>>   Internet Voting Service 
>>- Nov 27: Voting ends, 11PM UTC
>>- Dec 03: Election results are announced and take effect.
>>
>> Best regards,
>> Oleg
>> On Tuesday, September 15, 2020 at 2:52:59 PM UTC+2 Oleg Nenashev wrote:
>>
>>> Thanks to everyone for the feedback!
>>> I will keep working on the proposal and incorporating suggestions this
>>> week, and I also suggest to have a discussion at the tomorrow's governance
>>> meeting
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>> On Tuesday, August 25, 2020 at 5:49:02 PM UTC+2, Oleg Nenashev wrote:

 Hi all,

 As discussed at the previous governance meeting, I would like to
 follow-up on the election process ahead of the 2020 elections this autumn
 (November). After the 2019 elections we had a retrospective
 
  where
 we discussed the major pains we experienced during the elections, including
 the sign-up procedure (caused almost a 4+ weeks dela), eligibility issues
 and lack of transparency.

 I suggest that we follow-up on these issues and improve the process for
 the incoming 2020 elections.In order to kick-off the discussion, I have
 assembled an initial proposal about how the issues could be addressed.
 Google doc with the proposal is here
 
 .

 Any feedback and suggestions would be appreciated!

 Thanks for your time,
 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/1d7eaa17-99ca-42db-9760-3c4f34342c83n%40googlegroups.com
> 
> .
>


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

Re: Jenkins Elections Process Question

[Slide]

Just to clarify, the two options are

1) Use Google Forms built-in method for collecting email addresses, this
requires a Google Account
2) Use a short text input in the Google Form to collection email addresses,
this does NOT require a Google Account

On Mon, Sep 21, 2020 at 8:17 AM Marky Jackson 
wrote:

> I am +1 for google form
>
> On Sep 21, 2020, at 8:15 AM, Slide  wrote:
>
> Hi Everyone,
>
> The Jenkins Governance Board Elections Committee is currently implementing
> the process which has been defined for Governance Board and Officer
> Elections. As part of this, we are creating the form that will be used for
> signing up to participate in the elections. We need to collect email
> addresses as part of the process. We are using a Google Form for the
> sign-up and it provides a mechanism to collect email addresses, but it
> requires users to login to a Google account when using the Google Forms
> mechanism. It does allow us to reduce the possibility of duplicate voting.
> We will not keep the data after the voting. Another option would be to just
> have a short text input that accepts an email address and we would collect
> it that way. We would like the opinions of those on this list to determine
> whether this is acceptable or not. We need the email addresses in order to
> communicate if there are issues in the contribution information as well as
> to add the folks to the Condorcet vote.
>
> Please let us know ASAP your thoughts on this.
>
> Regards,
>
> Alex Earl
>
>
> --
> 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/CAPiUgVer2x2iug%2BCFNoJkyQDmPoQt_BZyTukijGTnSjezJp2eA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVer2x2iug%2BCFNoJkyQDmPoQt_BZyTukijGTnSjezJp2eA%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/2657FEA1-B54B-4B77-9B8D-2DCCA9F3BCC8%40gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/2657FEA1-B54B-4B77-9B8D-2DCCA9F3BCC8%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVeQH8-k_1pLEh47Dy_B%3DhK3k_wYSu-AFx81ntN2zeMrkw%40mail.gmail.com.

Jenkins Elections Process Question

[Slide]

Hi Everyone,

The Jenkins Governance Board Elections Committee is currently implementing
the process which has been defined for Governance Board and Officer
Elections. As part of this, we are creating the form that will be used for
signing up to participate in the elections. We need to collect email
addresses as part of the process. We are using a Google Form for the
sign-up and it provides a mechanism to collect email addresses, but it
requires users to login to a Google account when using the Google Forms
mechanism. It does allow us to reduce the possibility of duplicate voting.
We will not keep the data after the voting. Another option would be to just
have a short text input that accepts an email address and we would collect
it that way. We would like the opinions of those on this list to determine
whether this is acceptable or not. We need the email addresses in order to
communicate if there are issues in the contribution information as well as
to add the folks to the Condorcet vote.

Please let us know ASAP your thoughts on this.

Regards,

Alex Earl


-- 
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/CAPiUgVer2x2iug%2BCFNoJkyQDmPoQt_BZyTukijGTnSjezJp2eA%40mail.gmail.com.

Re: Multiple plugin adoption

[Slide]

I merged the PR for emailext-template, I am not sure why I wasn't notified
about your PR. I will add you to the committers list for the plugin.

On Wed, Sep 2, 2020 at 2:24 PM br...@hashvault.io 
wrote:

> Hello Jenkins Developers,
>
> I've been using Jenkins since the Hudson days and have recently started to
> contribute back to the project since I have the time.  I opened a couple of
> PRs on the repositories below that deal with the documentation migration
> from the wiki.  I was able to merge one that Arnaud Heritier helped me with
> for the pipeline-maven-plugin he has adopted.
>
> These PRs have been sitting out here for a few weeks and I noticed that
> the projects have 1 or fewer commits combined total in the past year.
>
> I know the emailext-template-plugin and extended-choice-parameter-plugin
> pretty well.  The built-on-column plugin looks really simple to maintain.
> The only one I'm hesitant to touch is the authorize-project-plugin since
> that looks pretty sensitive in nature.
>
> If I am unable to adopt multiple plugins at the same time (or any for that
> matter), I'd at least like to get the ball rolling on a discussion for who
> should adopt these plugins.
>
> Plugin commit history over the past year:
>
> -
> https://github.com/jenkinsci/emailext-template-plugin/graphs/commit-activity
> -
> https://github.com/jenkinsci/built-on-column-plugin/graphs/commit-activity
> -
> https://github.com/jenkinsci/extended-choice-parameter-plugin/graphs/commit-activity
> -
> https://github.com/jenkinsci/authorize-project-plugin/graphs/commit-activity
>
> Thank you,
> Brian
>
> --
> You received this message because you 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/2cdc7ae2-ad14-44db-a33c-1651acda3e02n%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVdvOfyq1ovQs1aXWq5eXajYxU-JDM_7PeQ9_v7e%3Dd%3DPsg%40mail.gmail.com.

Re: Unable to upload plugin to Jenkins center 401, Unauthorized

[Slide]

The pull request has been merged.

On Wed, Sep 2, 2020 at 12:37 AM Anna Rozin <
anna.ro...@whitesourcesoftware.com> wrote:

> Please help me with this pull request
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1660
>
> On Tuesday, September 1, 2020 at 7:57:31 PM UTC+3 Anna Rozin wrote:
>
>> Sorry for the misunderstanding, already submitted.
>>
>>
>> On Tue, 1 Sep 2020, 19:27 Anna Rozin, 
>> wrote:
>>
>>> Hi,
>>> I'm a contributor in our Jenkins plugin in git and have a user in
>>> artifactoryy, the other two people are not working in the company any more,
>>> what can I do?
>>>
>>> Thank you
>>>
>>> On Tue, 1 Sep 2020, 19:16 'Gavin Mogan' via Jenkins Developers, <
>>> jenkin...@googlegroups.com> wrote:
>>>
 That's just a diff. You'll actually have to hit submit on that page and
 get someone who currently has access to approve it for security and safety
 reasons

 On Tue., Sep. 1, 2020, 6:26 a.m. Anna Rozin, <
 anna@whitesourcesoftware.com> wrote:

> Hi,
> Please see this PR
>
> https://github.com/jenkins-infra/repository-permissions-updater/compare/master...annarozin:patch-1
>
> Thanks
>
> On Tuesday, September 1, 2020 at 4:15:51 PM UTC+3 db...@cloudbees.com
> wrote:
>
>> Please see
>> https://www.jenkins.io/doc/developer/publishing/releasing/#the-upload-to-the-maven-repository-fails-with-401-unauthorized
>> for possible causes.
>>
>> See
>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-whitesource.yml
>> for who should have upload permissions, and file a PR to add or remove
>> users. Read the entire readme of the repo for more details.
>>
>> On Tue, Sep 1, 2020 at 3:10 PM Anna Rozin <
>> anna@whitesourcesoftware.com> wrote:
>>
>>> Hi  Team,
>>> We have a plugin in
>>> WhiteSource, we created a fix for the issue that we had and tried to 
>>> upload
>>> it to the Jenkins center and got the following error (an image is 
>>> attached):
>>>
>>>  "*Failed to transfer file*:
>>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/whitesource/20.8.1.15/whitesource-20.8.1.15.hpi.
>>> *Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1*]"
>>>
>>> I do have access to* https://repo.jenkins-ci.org/
>>>  *but I think that I don't have admin
>>> permissions to upload to this repo see the attached image "
>>> *permissions-jenkins-ci-repo.PNG*"
>>>
>>> Can you please help me with this?
>>>
>>> Thank you,
>>> Anna Rozin
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you 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/cce35080-626c-45b3-9e8f-335950a38a36n%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-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/b8447344-e775-4571-951b-b838b6c75a19n%40googlegroups.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/tZpRX9JZAd0/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutKsu1-4RfYWe9t1a3BJh38WBDS6iBk50L2g8GXpwK9sA%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
> 

Re: Terminology Updates

[slide]

Hi everyone,

To follow up on the Governance Meeting (
https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.10x94wjx4rlj).
 
We took the input from the community poll and discussed the options. We 
voted to change from the term "master' to the term "controller" in 
referring to the "Jenkins Application". We will be doing some additional 
work to understand the internationalization aspects as people start to make 
PR's to change terms in non-english languages. I will be creating a page 
that will contain recommendations for each language for various terms as 
the various language discussions occur during PR's. 

Thanks for all those who participated in the poll and the discussion.

Regards,

Alex

On Wednesday, August 12, 2020 at 10:55:07 AM UTC-7 Oleg Nenashev wrote:

> Hi all,
>
> Just a reminder, we will be selecting a final term at the governance 
> meeting in 5 minutes.
> Everybody is welcome to participate: 
> https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09
>
> Best regards,
> Oleg
>
>
> On Thursday, July 30, 2020 at 7:21:19 PM UTC+2, slide wrote:
>>
>> Hi Everyone,
>>
>> Just wanted to update on the current status of this effort. We discussed 
>> this in the Governance Meeting yesterday. The poll closed yesterday, you 
>> can see the results at: 
>> https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1bd92a17371a1ca5. 
>> They are also shown below:
>>
>> Result
>> 1. *Controller*  (Condorcet winner: wins contests with all other choices)
>> 2. Manager  loses to Controller by 95–35
>> 3. Coordinator  loses to Controller by 98–37, loses to Manager by 69–59
>> 4. Primary  loses to Controller by 90–44, loses to Coordinator by 66–63
>> 5. Main  loses to Controller by 97–36, loses to Primary by 68–47
>> 6. Director  loses to Controller by 110–21, loses to Main by 70–56
>> 7. Leader  loses to Controller by 106–24, loses to Director by 71–46
>> 8. Executive  loses to Controller by 116–15, loses to Leader by 65–34
>>
>> Our plan now is to take the terms from the poll and run them through some 
>> checks with native speakers and Google Translate to check the 
>> internationalization aspects of the options. We will make a final decision 
>> in the next Governance Meeting and make announcements here on the 
>> Developers Mailing List as well as providing context and information via 
>> blog posts.
>>
>> Just as a reminder, this effort is to replace the "Jenkins application" 
>> term, for what used to be termed the "Jenkins Master." In addition to this 
>> usage of "master" we also have the concept of the "master" node that can 
>> exist in the Jenkins Application. We will determine next steps on replacing 
>> that term (for that node) in the future (because the terms in the list 
>> below do not necessarily match the requirements in the context of nodes). 
>>
>> We want to thank everyone who participated in the poll. We are working 
>> hard to get these changes going on this important effort.
>>
>> Regards,
>>
>> Alex Earl
>>
>> On Wednesday, July 29, 2020 at 10:38:24 AM UTC-7 Oleg Nenashev wrote:
>>
>>> Thanks to everyone who voted for the options! We will review of the 
>>> voting results to the Governance meeting agenda: 
>>> https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.cgd8zbewht8o
>>>
>>> The meeting will start in 20 minutes, everyone is welcome to join: 
>>> https://zoom.us/j/99217163913?pwd=TldwZWZTQzNNc3ZGaThFOThlckFGQT09
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Thursday, July 23, 2020 at 8:35:15 PM UTC+2, Mark Waite wrote:
>>>
>>>> Unfortunately, new terms can't be included in the the votiing.  The 
>>>> voting is already in progress at  
>>>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_1bd92a17371a1ca5=f82b79a50f54ad87
>>>>  .  
>>>> The governance board is using the voting as input for the final decision 
>>>> on 
>>>> the term to be used.
>>>>
>>>> On Thu, Jul 23, 2020 at 7:15 AM Steve Carter  wrote:
>>>>
>>> Hi all,
>>>>>
>>>>> I showed up late to the party, so I'll accept a snub gracefully, but I 
>>>>> was intrigued by the problem of replacing the term "master" and have one 
>>>>> further term I would like to put in the poll if at all possible.
>>>>>
>>>>> Dispatcher.
>>>>>

Re: Terminology Updates

[slide]

Hi Everyone,

Just wanted to update on the current status of this effort. We discussed 
this in the Governance Meeting yesterday. The poll closed yesterday, you 
can see the results at: 
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1bd92a17371a1ca5. They 
are also shown below:

Result
1. *Controller*  (Condorcet winner: wins contests with all other choices)
2. Manager  loses to Controller by 95–35
3. Coordinator  loses to Controller by 98–37, loses to Manager by 69–59
4. Primary  loses to Controller by 90–44, loses to Coordinator by 66–63
5. Main  loses to Controller by 97–36, loses to Primary by 68–47
6. Director  loses to Controller by 110–21, loses to Main by 70–56
7. Leader  loses to Controller by 106–24, loses to Director by 71–46
8. Executive  loses to Controller by 116–15, loses to Leader by 65–34

Our plan now is to take the terms from the poll and run them through some 
checks with native speakers and Google Translate to check the 
internationalization aspects of the options. We will make a final decision 
in the next Governance Meeting and make announcements here on the 
Developers Mailing List as well as providing context and information via 
blog posts.

Just as a reminder, this effort is to replace the "Jenkins application" 
term, for what used to be termed the "Jenkins Master." In addition to this 
usage of "master" we also have the concept of the "master" node that can 
exist in the Jenkins Application. We will determine next steps on replacing 
that term (for that node) in the future (because the terms in the list 
below do not necessarily match the requirements in the context of nodes). 

We want to thank everyone who participated in the poll. We are working hard 
to get these changes going on this important effort.

Regards,

Alex Earl

On Wednesday, July 29, 2020 at 10:38:24 AM UTC-7 Oleg Nenashev wrote:

> Thanks to everyone who voted for the options! We will review of the voting 
> results to the Governance meeting agenda: 
> https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.cgd8zbewht8o
>
> The meeting will start in 20 minutes, everyone is welcome to join: 
> https://zoom.us/j/99217163913?pwd=TldwZWZTQzNNc3ZGaThFOThlckFGQT09
>
> Best regards,
> Oleg
>
>
> On Thursday, July 23, 2020 at 8:35:15 PM UTC+2, Mark Waite wrote:
>
>> Unfortunately, new terms can't be included in the the votiing.  The 
>> voting is already in progress at  
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_1bd92a17371a1ca5=f82b79a50f54ad87
>>  .  
>> The governance board is using the voting as input for the final decision on 
>> the term to be used.
>>
>> On Thu, Jul 23, 2020 at 7:15 AM Steve Carter  wrote:
>>
> Hi all,
>>>
>>> I showed up late to the party, so I'll accept a snub gracefully, but I 
>>> was intrigued by the problem of replacing the term "master" and have one 
>>> further term I would like to put in the poll if at all possible.
>>>
>>> Dispatcher.
>>>
>>> This would most correctly apply to the function of taking jobs off the 
>>> queue and handing them to nodes. What we today know as master would 
>>> therefore consist of dispatcher and zero-or-one agents.
>>>
>>> What I think distinguishes this suggestion is that it connotes a service 
>>> provided to agents in collaboration rather than a hierarchical power 
>>> relationship.
>>>
>>> -- 
>>> You received this message because you 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/b8487054-6383-4dec-be3e-29103215cc09o%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/16dd80db-6686-451a-9e77-9f009833bafen%40googlegroups.com.

Re: PageDecorator

[Slide]

Yes, I do mean `Run`, thanks. I'll look into that.

On Wed, Jul 29, 2020 at 2:40 PM Jesse Glick  wrote:

> On Wed, Jul 29, 2020 at 5:32 PM Slide  wrote:
> > I've been looking for a way to add some code to job status pages […]
> information about the build
>
> Assuming you mean `Run`, not `Job`, I would suggest
> `TransientActionFactory` and then define a `summary` view.
>
> --
> You received this message because you 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/CANfRfr3Aj3H%3D4BkwChh1TB0onrXvPi2dSD8FX_nkhQcuKWUpiA%40mail.gmail.com
> .
>


-- 
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/CAPiUgVd8O7nR8gxsasuCHRrV9fpbwT74JcdiO%2B3uBeNRk0vtPQ%40mail.gmail.com.

PageDecorator

[Slide]

Hi everyone,

I've been looking for a way to add some code to job status pages from my
plugin. PageDecorator looks like a possibility, but I am unsure if I can
get access to information about the build via a page decorator. Is this the
correct ExtensionPoint, or is there some better option?

Regards,

Alex

-- 
You received this message because you 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/CAPiUgVd91aHDNQob40Z7C%2BhG57w_0vLrREYXQGSaEoanVzDTpA%40mail.gmail.com.

Re: Script Security check during descriptor load

[Slide]

Hi Basil,


Thanks so much for your help! I'll review those items and see what I can
do. The Jenkins community is great!

Regards,

Alex

On Mon, Jul 27, 2020, 17:48 Basil Crow  wrote:

> Hey Alex,
>
> Coincidentally, I ran across a very similar circular dependency issue
> recently in the Copy Artifact plugin (JENKINS-62267
> ). On further
> examination, I also found a similar circular dependency issue in the
> Folders plugin (JENKINS-60393
> ). The Copy Artifact
> plugin maintainer based his fix for JENKINS-62267 on the fix for
> JENKINS-60393. You might find some inspiration  reading those bugs and PRs.
>
> Basil
>
> --
> You received this message because you 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/CAFwNDjqrNtwf9_87Xw6fi2VUAvdvn0KjTDN7z1FeaLcL3QzpYQ%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/CAPiUgVcEZ9VSbey%3Ds0wKo_FMyZEwTF39tjpWWK6bPAwKRGCoQw%40mail.gmail.com.

Script Security check during descriptor load

[Slide]

I am looking into  https://issues.jenkins-ci.org/browse/JENKINS-60002 for
email-ext. The issue arises when a pre-send script is configured and
Jenkins is starting up. This particular code is something that was
implemented while I was not the maintainer of the plugin, so I am not as
well versed in the history as other code in the plugin.

The constructor

is
calling load() and then calling some methods to setup parts of the plugin.
One of the things it does is call setDefaultPresendScript
so
that a check is done on the approval status for the script security plugin.
The check looks like this:

this.defaultPresendScript = ScriptApproval.get().configuring(((script ==
null) ?  ""  : script), GroovyLanguage.get(), ApprovalContext.create().
withCurrentUser());
  The ApprovalContext.create().withCurrentUser() seems to be the problem
because during Jenkins startup, there is no user (it is null). So, this
causes the issue in the bug. How do I make sure the script security stuff
is setup correctly for the pre-send script while fixing this issue?

Here is the full stack trace from the error:

 0.682 [id=78] WARNING
h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to
instantiate
Key[type=hudson.plugins.emailext.ExtendedEmailPublisherDescriptor,
annotation=[none]]; skipping this component
com.google.inject.ProvisionException: Unable to provision, see the
following errors:

1) Tried proxying hudson.plugins.emailext.ExtendedEmailPublisherDescriptor
to support a circular dependency, but it is not an interface.

1 error
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at
hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:440)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:402)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:393)
at
hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:335)
at hudson.ExtensionList.load(ExtensionList.java:380)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:318)
at hudson.ExtensionList.getComponents(ExtensionList.java:183)
at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:193)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:318)
at hudson.ExtensionList.iterator(ExtensionList.java:172)
at hudson.model.User.allocateDefaultPropertyInstancesAsNeeded(User.java:209)
at hudson.model.User.load(User.java:198)
at hudson.model.User.(User.java:191)
at hudson.model.User.getOrCreateById(User.java:523)
at hudson.model.User.getById(User.java:619)
at hudson.model.User.get(User.java:603)
at hudson.model.User.current(User.java:586)
at
org.jenkinsci.plugins.scriptsecurity.scripts.ApprovalContext.withCurrentUser(ApprovalContext.java:72)
at
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.setDefaultPostsendScript(ExtendedEmailPublisherDescriptor.java:580)
at
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.(ExtendedEmailPublisherDescriptor.java:196)
at
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor$$FastClassByGuice$$5dfa54d0.newInstance()
at
com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
at
com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
at
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
at
com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
at
com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
hudson.ExtensionFinder$GuiceFinder$SezpozModule.onProvision(ExtensionFinder.java:567)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
at
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at

Re: timja would like to join Jenkins Infra's Hosting team

[Slide]

+1

On Thu, Jul 23, 2020 at 8:16 AM Xiong Kezhi  wrote:

> +1 from me :)
>
> 在2020年7月23日星期四 UTC+8 下午11:10:29 写道：
>
>> +1
>>
>>
>> On Thu, Jul 23, 2020 at 5:02 PM Oleg Nenashev 
>> wrote:
>>
>>> +1 from me
>>>
>>> On Thu, Jul 23, 2020 at 4:55 PM Tim Jacomb  wrote:
>>>
 Hi

 I would like to join the hosting team (
 https://www.jenkins.io/project/teams/hosting/#requesting-membership)
 I believe I meet all the requirements, and have been helping with it
 already in IRC / PRs

 Thanks
 Tim

 On Thu, 23 Jul 2020 at 15:36, Oleg Nenashev 
 wrote:

> +1 from me, maybe needs a mirror message to the dev list
>
> On Thu, Jul 23, 2020 at 4:33 PM Jenkins Infra 
> wrote:
>
>> timja has requested to join Jenkins Infra’s Hosting team.
>>
>> You may approve or deny this request here:
>>
>> https://github.com/orgs/jenkins-infra/teams/hosting/members
>>
> --
>>> You received this message because you 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/CAPfivLDQhtJ_g9-jTow0fiRhkmzcwRhf4TyHNaRjORDOY1_HNQ%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/3be188d8-e266-45a6-b34d-cf490f686015n%40googlegroups.com
> 
> .
>


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

Re: Proposal Hosting the Jenkinsfile Runner Docker images in the jenkins DockerHub org

[Slide]

+1

On Thu, Jul 23, 2020 at 3:19 AM Tim Jacomb  wrote:

> +1
>
> On Thu, 23 Jul 2020 at 11:00, Oleg Nenashev 
> wrote:
>
>> Hi all,
>>
>> I have recently added
>> a number of
>> new Docker images to Jenkinsfile Runner, including images for Alpine JRE8
>> and Java 11. Currently the images are published to the
>> jenkins4eval DockerHub organization, because the project is still in the
>> experimental stage.
>>
>> I am working on stabilizing the Jenkinsfile Runner bits towards a 1.0
>> release, and I would like to move the images to the official "jenkins"
>> DockerHub organization. It would help to prepare the CI/CD Pipelines and
>> update the documentation.
>>
>> What do you think about moving the project to the official DockerHub org?
>>
>> Thanks in advance,
>> Oleg
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCJzzjyB7U%3Dgc7%3Dxtf9%3DG_%3D1YJnezi7KxVFAUR%2BmYR8tg%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-3BidmQLjW6hjri340EGx-b1zDryt%2BeELgfXN3AvpZYxK7eA%40mail.gmail.com
> 
> .
>


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

Re: Terminology Updates

[Slide]

Just a reminder, this is the last day that we will be accepting
suggestions. If you have an opinion on terms, please comment.

On Tue, Jun 30, 2020 at 8:25 AM Ian W  wrote:

> There is heightened sensitivity to the naming of things, the meaning
> behind them and the meaning read into them. I applaud the Jenkins community
> work to address these matters. I first encountered the master / slave
> terminology when I first tried to configure an IDE drive on a IBM PC clone.
> Then the context was "Master Controller" and "Slave Controller". Perhaps my
> youthful naiveté did not associate the full qualified terms  with racial
> imagery to which the lone words are ascribed. When I first saw the plain
> "Master / Slave" usage in Jenkins, I definitely made that negative
> association. If there exists more neutral terminology, I am all for it.
>
>
>
> The same goes for BlackList / WhiteList. Absolutely support the AllowList
> / DenyList pairing in its place.
>
>
>
> The transition to node/agent works well, and it is the executors that do
> the work.
>
> So, what for "the master" ? Some disliked Orchestrator, Controller, Host,
> Server, all for legitimate reasons.
>
>
>
> I see "the master" as having two contexts. There is the Administrative
> context (configuration, plugins etc.), that determine focus, capability,
> delegation. Then there's the context of those tasks that are necessary to
> execute "on the master".
>
>
>
> An elegant parallel for the first would be "Executive". That's our Org's
> (or Jenkins') " Leadership" capability. That's how it works in my Org, with
> an Executive (at HQ), multiple satellite offices (Nodes/Agents) and then
> the workers (executors).
>
>
>
> What about the tasks run on master? It's still executors doing the work,
> but its sounds like the job for a "Concierge" to coordinate and satisfy the
> needs of the clients and delegate as necessary. Our Org has a "Concierge"
> that functions similar to a Concierge at a hotel that most people would be
> familiar with, but in an office setting
>
>
>
> My recommendation: refer to the "Host/Server" context as the "Executive",
>  replace the "master" usage context with "Concierge".
>
>
> The terms and roles are well defined, should translate reasonably well or
> are understood as-is, have neutral connotations and are not used in other
> tools in the CI space that I am aware of.
>
>
>
> Ian
>
>
> On Thursday, 25 June 2020 15:36:05 UTC-7, Jeff Thompson wrote:
>>
>> "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. 

Re: Terminology Updates

[Slide]

Hi All,

We had a discussion about this in the Governance Meeting last week and came
to the following decisions to move forward.

We have had several recommendations/ideas for replacing the term "master"
with another term. Ideas such as host, server, controller and others. We
could not come to a consensus in the Governance Meeting, so we propose that
we set a deadline for suggestions from this thread, then the Governance
Board will select 10 of the suggestions for a Condorcet Internet Voting
Service vote (Mark Waite will be the technical lead on setting this up).
The poll will be used as input for the Governance Board to make the final
decision. I propose that we keep suggestions going in this thread until
July 1st after which the Governance Board can select the 10 suggestions
that will go into the vote.

We also realize that one term doesn't always meet the needs of the scope of
the usage of the term. We are starting a discussion to update the glossary (
https://www.jenkins.io/doc/book/glossary/) with recommended terms for
different use cases (e.g., Jenkins Web Interface, Jenkins Server
Application).

The discussion around "blacklist/whitelist" resulted in consensus that we
definitely need to deprecate and replace these terms. The context in which
these terms appear can require different replacements than just one
specific set. Simple replacements for "blacklist/whitelist" would be
"denylist/allowlist", but since context matters, we are not requiring one
specific set of terms be used for replacement, just that
"blacklist/whitelist" be replaced with acceptable terms. If you have
questions about the acceptability of replacement terms, please ask in the
developer mailing list.

Once we decide on a term replacement for "master" we would like to focus on
user facing places first like docs, web interface, etc., but the goal is to
replace everything over time. The same priorities exist for
"blacklist/whitelist".

If you have not made suggestions and would like to, please reply to this
email and I will collect the suggestions in the Google Doc (
https://docs.google.com/document/d/1-8myIWOZZktR0HNtbFIiNA0RfDCvkfKKuNI0C3wcvbo/edit?ts=5eea6706#)
that Oleg created.

Thanks!

Alex
Jenkins Governance Board Member

On Mon, Jun 22, 2020 at 2:18 AM Tony Noble  wrote:

> Another vote for allowlist/denylist (or blocklist).
>
> Controller/Agent is a sensible replacement for the master/slave paradigm
> and has the benefit of being self-describing.  I don't see that there
> should be any confusion between Jenkins controller and Kubernetes
> controller any more than there would be with any other type of controller.
> "Server" should apply to the host, IMO.
>
> Tony
>
> On Wed, Jun 17, 2020 at 3:30 PM Oleg Nenashev 
> wrote:
>
>> I started a Google Doc to capture proposals and votes
>>
>> https://docs.google.com/document/d/1-8myIWOZZktR0HNtbFIiNA0RfDCvkfKKuNI0C3wcvbo/edit?usp=sharing
>>
>>
>> On Wednesday, June 17, 2020 at 12:30:47 AM UTC+2, Tammy Fox wrote:
>>>
>>> +1 for allowlist/denylist to be consistent with what other communities
>>> are using.
>>>
>>> I have 3 suggestions to replace Master:
>>>
>>> 1. Director
>>> 2. Expeditor
>>> 3. Coordinator
>>>
>>> Thoughts? I was thinking about what a Master does, and it seems similar
>>> to the Expeditor in a restaurant kitchen. The Master getting build requests
>>> and sending it to the individual build agents is similar to an Expeditor
>>> sending different items to the different food stations in a restaurant.
>>>
>>> On Tuesday, June 16, 2020 at 4:05:58 PM UTC-4 Tracy Miranda wrote:
>>>
 Good discussion on 'master' replacement - listening and learning

 On the other terminology I vote allowlist/denylist.
 This is also consistent with other projects communities e.g.
 Rails/Kubernetes
 https://github.com/rails/rails/issues/33677
 https://github.com/kubernetes/website/pull/21591

 Tracy


 On Tue, Jun 16, 2020 at 1:30 PM Justin Harringa 
 wrote:

> Conductor is a cool suggestion!
>
> On Mon, Jun 15, 2020, 2:49 PM Adrien Lecharpentier <
> adrien.lec...@gmail.com> wrote:
>
>> I have to say that the music parallel from Angelique seems nice and
>> has a lot of sense in my opinion.
>> And the Jenkins butler is not that far from a music orchestrator as
>> well.
>>
>> Le lun. 15 juin 2020 à 22:47, Daniel Beck  a
>> écrit :
>>
>>>
>>>
>>> > On 15. Jun 2020, at 22:39, Markus Winter  wrote:
>>> >
>>> > Second the server is also just plain agent (more or less). For
>>> this we
>>> > could use the term "main"  as the default label.
>>>
>>> That's what I proposed earlier in the thread as well.
>>>
>>> 'main' seems reasonable, but still has the connotation that it's
>>> actually a good idea to use this node, when it rarely is.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups 

Re: Contributing documentation from other sources

[Slide]

I concur with all of Oleg's statements. I think this sounds great, but we
need to make sure the content is not copyrighted in such a way that would
cause the Jenkins project issues.

On Wed, Jun 24, 2020 at 4:00 AM Oleg Nenashev 
wrote:

> Hi Mark,
>
> Thanks a lot for starting this discussion. I see no problem with such
> initiative in general. If someone is willing to donate the documentation
> content, it is always appreciated. There are many vendors and users who
> created their own documentation for Jenkins, and it would be great to see
> some of this documentation going to upstream and becoming available to all
> Jenkins users.
>
> Some notes about the implementation
>
>- We should ensure that contributors are not at risk of
>unintentionally violating the copyright. IMO all source content referenced
>in the created issues should have explicit Creative Commons license defined
>by the copyright owner. It applies to the text, screenshots and other
>media. It is not OK to require contributors to apply the new copyright
>during the transition
>- I do not think the migration will be just about "phrasing
>adjustments". The issues should be triaged before they become available for
>grabs (e.g. "needs-triage" label). An experienced documentation contributor
>(or a group of contributors) needs to take a look at the content to
>identify the migration feasibility and a correct migration destination. It
>is not just moving a page to another location, it will likely require a lot
>of content de-duplication. Also, some recommendations for CloudBees
>products may not directly apply to Jenkins which is more diverse in terms
>of the plugin/component ecosystem and supported use-cases
>- We have no standard way to put attributions to third parties in our
>documentation. Indeed we should do it according to the Creative Commons SA
>license. IMHO somebody needs to implement attribution support for pages and
>sections before such migration starts (metadata and some HAML patches?)
>
>
> I believe the same process could be used by any company that delivers
>> products based on Jenkins.
>>
> +1. Any contributions are welcome, including documentation content
> donations
>
>  Is that type of process within the bounds of the www.jenkins.io
>>  licensing?
>
> IMO Yes
>
> Does this need a JEP or is it sufficient to discuss on the developers list?
>
> I do not see a strict need in a JEP. Email discussion, dry-run, and
> creating "Content Donation Guidelines" in
> https://github.com/jenkins-infra/jenkins.io/blob/master/CONTRIBUTING.adoc 
> would
> be enough IMHO. Note that a similar process may apply to a donated plugin
> documentation. If you find having a process JEP helpful, +1 for having it.
> No need in extra overhead otherwise.
>
> Are there any special approvals required for this type of content?
>>
> It would be great to have at least one approval from a contributor not
> affiliated with a company donating documentation.
> IMHO we need a careful triage process, not a special review process here
>
> Best regards,
> Oleg
>
> On Wednesday, June 24, 2020 at 10:02:21 AM UTC+2, Tim Jacomb wrote:
>>
>> Hi Mark
>>
>> Have you got any examples of documentation that would be good to migrate?
>>
>> Sounds great though
>>
>> Thanks
>> Tim
>>
>> On Tue, 23 Jun 2020 at 22:39, Mark Waite  wrote:
>>
>>> The documentation team at CloudBees has asked if the community would be
>>> interested in reworking or adjusting documentation that CloudBees has
>>> created for their product to describe similar use cases on
>>> www.jenkins.io.   The documentation team at CloudBees does not have the
>>> capacity to perform the transformation themselves, but would be happy to
>>> allow others to use their material, validate that it works with the most
>>> recent Jenkins LTS, update the screenshots to use Jenkins rather than the
>>> CloudBees product, and submit it as a pull request to the Jenkins
>>> documentation.
>>>
>>> I envision that the process would be similar to our Wiki migration
>>> process.  I think it would work something like this:
>>>
>>>- A CloudBees documentation team member creates a GitHub issue for
>>>content that could be reworked or reused on www.jenkins.io.  The
>>>GitHub issue provides the source text and images for reference or 
>>> provides
>>>a link to a publicly accessible location that includes the source text 
>>> and
>>>images
>>>- A Jenkins contributor adds a comment to the GitHub issue that
>>>says, "I'm working on this"
>>>- The Jenkins contributor uses the CloudBees ASCIIDOC, adjusts the
>>>phrasing as needed to apply to Jenkins, confirms that it works with
>>>Jenkins, and updates any screenshots to use Jenkins
>>>- The Jenkins contributor adds an attribution to CloudBees (per the
>>>Creative Commons SA 4.0 license) to the bottom of the page submitted for
>>>www.jenkins.io
>>>- The Jenkins 

Re: Plugin adoption request: publish-over-cifs

[Slide]

You should be good to go on permissions to the repo and with release
permissions. Welcome aboard!

On Fri, Jun 19, 2020 at 11:06 AM Slide  wrote:

> +1 from me as the most recent maintainer. One thing to note is that
> po-cifs relies heavily on the po plugin (it's the basis for multiple po
> plugins), so you may need to maintain that one as well.
>
> On Fri, Jun 19, 2020 at 11:04 AM Patrick Wilkerson 
> wrote:
>
>> Hello,
>>
>> I would like to adopt publish-over-cifs plugin.
>>
>> I am wanting to submit a fix for JENKINS-18242. I have submitted a pull 
>> request 14 days ago and have had no response (also plugin is marked for 
>> adoption).
>>
>> * Link to a plugin you want to adopt: 
>> https://github.com/jenkinsci/publish-over-cifs-plugin
>> * Link(s) to pull requests you want to deliver: 
>> https://github.com/jenkinsci/publish-over-cifs-plugin/pull/11
>> * Your GitHub username/id: blakmajk
>> * Your Jenkins infrastructure account id: patrickw
>>
>> * Permission update pull request 
>> https://github.com/jenkins-infra/repository-permissions-updater/pull/1586
>>
>>
>> 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/fa1d1e68-aa09-4fd2-80aa-743fbce441e5o%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/fa1d1e68-aa09-4fd2-80aa-743fbce441e5o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Website: http://earl-of-code.com
>


-- 
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/CAPiUgVeY5bFeZvEQhL4OowGMt2Suo-UjaDCd38Z%3DB4-CUJt4hA%40mail.gmail.com.

Re: Plugin adoption request: publish-over-cifs

[Slide]

+1 from me as the most recent maintainer. One thing to note is that po-cifs
relies heavily on the po plugin (it's the basis for multiple po plugins),
so you may need to maintain that one as well.

On Fri, Jun 19, 2020 at 11:04 AM Patrick Wilkerson 
wrote:

> Hello,
>
> I would like to adopt publish-over-cifs plugin.
>
> I am wanting to submit a fix for JENKINS-18242. I have submitted a pull 
> request 14 days ago and have had no response (also plugin is marked for 
> adoption).
>
> * Link to a plugin you want to adopt: 
> https://github.com/jenkinsci/publish-over-cifs-plugin
> * Link(s) to pull requests you want to deliver: 
> https://github.com/jenkinsci/publish-over-cifs-plugin/pull/11
> * Your GitHub username/id: blakmajk
> * Your Jenkins infrastructure account id: patrickw
>
> * Permission update pull request 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1586
>
>
> 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/fa1d1e68-aa09-4fd2-80aa-743fbce441e5o%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVdvJ2taCE%2Bscera-JkZ%3D3Sabi6vSJKoq_iCH4N3ZdDY7Q%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Slide]

Agreed, I think we need to have this as a topic in that meeting.

I think there are two parts of this topic:

   1. Do we want to allow both Jira and Github issues to coexist in the
   Jenkins infrastructure?
  1. This is _somewhat_ moot at this point because we already have a
  large number of repos that have Github Issues enabled already.
  2. If we want to allow both, do we need to clean up the Jira
  components of those plugins that are using Github Issues by
providing a way
  to migrate issues from Jira to Github Issues and then removing the
  component? Also, the opposite, if the plugin developers want to use Jira
  but Github Issues was enabled on their repository without them wanting it
  enabled (this could have happened for many reasons), do we need
to cleanup
  the Github Issues and provide a way to migrate issues from
Github Issues to
  Jira?
   2. Do we want to adjust the hosting process to allow selection of the
   issue tracking (Github Issues or Jira)?
  1. This would mean that the hosting bot would check that field and
  either:
 1. Create a component in Jira and disable GitHub issues for the
 repo (this does not preclude the plugin developers team members from
 re-enabling GitHub Issues after the fact)
 2. No creation of a component in Jira and GitHub issues are NOT
 disabled


Am I missing anything from this thread?

On Thu, Jun 18, 2020 at 11:12 AM Ullrich Hafner 
wrote:

>
> > Am 18.06.2020 um 19:48 schrieb 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com>:
> >
> > > Puh, that is a lot. That means we already cerated a mess for our users
> by providing two different tools for the same thing :-(
> >
> > Which is why I want to know what and how we want to support things
> officially so I can add it to the plugin site.
> >
>
> Wouldn’t it then make sense that the people who want officially support
> GitHub as a second issue tracker would make that an agenda topic for the
> next governance meeting?
> So we can finally come to an official statement? Otherwise this thread
> will continue indefinitely.
>
> --
> You received this message because you 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/EFE72EBF-2AD3-4F12-9879-8A3864CD643D%40gmail.com
> .
>


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

Re: GitHub issues option in HOSTING

[Slide]

>
> >
> > About consistency, I fully agree, but we are already past that point as
> the plugins are already mixed up between Jira and GH.
>
> I don’t think that we are past the point yet, just because a couple of
> plugins managed it to enable GitHub issues. From my understanding the
> hosting process creates a Jira component and GitHub Issues is disabled for
> the repository.
>

People added to the develop group for the plugin have admin access to the
repo, so enabling GitHub Issues is pretty easy. This is how some repos
currently have GitHub Issues enabled now.

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

Re: Bug Triage "Team"

[Slide]

I'm definitely still interested in this. There wasn't a lot of interest
back in the day, so I kind of let it slide.

On Tue, Jun 16, 2020 at 1:29 PM Sladyn Nunes 
wrote:

> I would love to be able to help in bug triaging, I do not have a lot of
> experience, but would be interested in participating.
>
> On Wed, Jun 17, 2020, 1:56 AM Marky Jackson 
> wrote:
>
>> I would like to be a part of this. I have some operational knowledge of
>> bug-triage from the Kubernetes community that may be of some help here.
>>
>> > On Jun 16, 2020, at 1:22 PM, Oleg Nenashev 
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/B2F5F599-8636-4551-9F0F-EE1D24B581EA%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/CAC-Leqsk-AJKXTSu1e%2BoU%2BVKC5jGJGnCVNZ-KZ1CN7XhDjgPfw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqsk-AJKXTSu1e%2BoU%2BVKC5jGJGnCVNZ-KZ1CN7XhDjgPfw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVd1KjF2vBz8qqNK6-%2BcudkyyfoxMj1ovn1%3Dnr5LP%3DMv9w%40mail.gmail.com.

Re: Terminology Updates

[Slide]

Jenkins Server makes sense to me as well. I'll add as a topic for the next
Governance meeting. Please also make sure and weigh in on
AllowList/DenyList and it's other derivatives.

On Fri, Jun 12, 2020, 10:43 Marky Jackson  wrote:

> I like Jenkins Server too
>
> > On Jun 12, 2020, at 10:41 AM, Matt Sicker  wrote:
> >
> > I also like Jenkins Server as a simple name.
> >
> > Other ideas: JenkinsD (like SystemD or any daemon), Jenkins Principal
> > (matches the principal/agent paradigm of agents executing code on
> > behalf of the principal).
> >
> > On Fri, Jun 12, 2020 at 12:37 PM Vlad Silverman 
> wrote:
> >>
> >> I agree, “Jenkins Server” reflects primary functionality and definitely
> makes sense.
> >>
> >> Thx, Vlad
> >>
> >> On Jun 12, 2020, at 10:21 AM, Mark Waite 
> wrote:
> >>
> >> My favorite is Jenkins server.  I'll use whatever term is ultimately
> selected, but "Jenkins server" is easier for me than "Control Plane".
> >>
> >> On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson 
> wrote:
> >>>
> >>> 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, website and on 3rd
> party resources.
> >>>
> >>> 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
> .
> >>>
> >>> --
> >>> You received this message because you 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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%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/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.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 

Terminology Updates

[Slide]

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.

Re: GitHub issues option in HOSTING

[Slide]

The issue with the cloud version is that it is not compatible with our LDAP
(at least that is what I believe Olivier said last time).

On Thu, Jun 11, 2020 at 2:28 PM James Nord  wrote:

> I agree with Ulli's statements.
>
> There seems to be comments that our hosted Jira is sluggish or hard to
> maintain.  I've asked before but why can,t the cloud version be an option?
> we should be able to spin up a stateless SAML to LDAP integration for Jira
> Cloud with much less effort than continuing to patch/maintain our own Jira
> (and pay for the infra)?
> maybe it's a license thing, in which case could we approach atlassian and
> ask?
> I think many project are not wanting to use GH issues and so it seems that
> improving Jira would make things better for everyone even if it is not what
> some would desire in the end.
>
> --
> You received this message because you 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/b9896b3e-89c6-4391-850c-68437d8820a4o%40googlegroups.com
> .
>


-- 
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/CAPiUgVeJvRM5LrrPwwS93pyiO38iSWpkYEDHna3_1E%2BaB1JNRw%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Slide]

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.

On Wed, Jun 10, 2020, 19:49 Brian Thompson  wrote:

> I agree.  I'd love to see Jenkins migrate from Jira to GH.  As a user, if
> I want to submit an issue to Jenkins, it's a bit cumbersome to create an
> additional account for Atlassian just so that I can create a ticket.
> However, it's highly likely that I already have a GH account and have even
> browsed the codebase a bit or cloned the repo myself from GH.  So having
> the issues right where I am makes my life easier.
>
> On Wed, Jun 10, 2020 at 7:57 PM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> personally, as someone who replies to emails/tickets on my phone a lot,
>> I'd love to see everything migrated from self hosted jira to github, and
>> have one less item that the infra team needs to manage. Plus easier for
>> people to report bugs since they don't need to make an ldap account first
>>
>> On Wed, Jun 10, 2020 at 7:06 AM Radosław Antoniuk <
>> radek.anton...@gmail.com> wrote:
>>
>>> Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <
 radek.anton...@gmail.com>:

 Not sure I got the question right, but IMO it's each plugin's
 maintainer responsibility to transfer the issues from Jira to GH (with a
 pre-prepared solution I mentioned long ago).


 I think we are still one step before: should we as project allow a
 diversity for issue tracking or should all maintainers use Jira? Until we
 have no such decision we should not discuss on how to actually do a
 migration.


>>> From standarisation and a common approach standpoint, forcing all
>>> plugins to use Jira would be reasonable if not for:
>>> - stability problems
>>> - maintenance problems (it is not updated frequently enough imo)
>>> - lack of common process (I don't like for instance that we cannot use
>>> fixVersion in the workflow)
>>>
>>> All of those could be probably addressed but OTOH, we are also too late
>>> with forcing to use Jira as a lot of plugins are already using GH issues
>>> and frankly as we discsussed before, I concur with GH Issues being closer
>>> to code/repository and easier for maintainers.
>>> So, if each repository/plugin has it's own maintainer and noone from the
>>> umbrella organisation, then it should be up to the plugin maintainers to
>>> decide what they use - and we already see the tendency here.
>>>
>>> --
>>> You received this message because you 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/CAPe2pWgd9JNaTuy%3DAPsojvGKp9%3Da0zS4cE7LSN0dq%2BEizzRHBQ%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/CAG%3D_Dus4DK%3DiaKZnR6gKGg4Avw1cgm%3D%2Be2gLT4LnC%3DrFbN46eg%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Best regards,
>
> Brian
>
> --
> You received this message because you 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/CAHY5bT_R%3DMUhFuSjQTMcLiK%2B46tnLXKx%3DV8i40TRC-%2BncRJi%3Dw%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 

Re: Proposal: Public community-driven roadmap for the Jenkins project

[Slide]

I think this sounds great, thanks for all of your efforts in this area!

On Wed, Jun 10, 2020 at 12:15 PM Oleg Nenashev 
wrote:

> Hi all,
>
> Just to provide some updates, we have had a few roadmap reviews at the
> Jenkins Governance meetings, and we have also collected roadmap feedback
> from all special interest groups and sub-projects. We have been less
> successful with plugin maintainer communications, but I hope to address it
> in the coming week by hosting an online meetup and, maybe, reaching out to
> maintainers through the Jenkins contributor newsletter which I would like
> to establish.Current roadmap can be found here:
> https://www.jenkins.io/project/roadmap/
>
> I would like to suggest a few changes there based on the experience:
>
>1. Introduce a new "Preview" status. We have any initiatives which are
>stuck in Current but which are available to users for preview, e.g.
>WebSockets support (JEP-223), new Windows Installer, and so on. Moving it
>to a new category would allow to highlight the preview status and,
>hopefully, to facilitate feedback
>   - I created https://github.com/jenkins-infra/jenkins.io/pull/3444 for
>   review
>2. Introduce labels of initiatives (e.g. "feature", "documentation",
>"service", "outreach-program", etc.)
>   - Each initiative will be able to have multiple categories. There
>   will be a JavaScript-powered filter which will allow filtering 
> categories
>   - "Documentation" and "Outreach Programs" sections would be largely
>   merged into user-focused categories on the roadmap.
>  - For example, Jenkins UI/UX Hackfest would be in the "User
>  Experience" group while having an "outreach-program" label
>
> Would appreciate your feedback about these proposals.
>
> Thanks in advance,
> Oleg
>
>
> On Monday, April 6, 2020 at 8:10:34 PM UTC+2, Jon Brohauge wrote:
>>
>> Totally love the roadmap. Sincerely missed in most software.
>>
>> Rgds
>> Jon
>>
> --
> You received this message because you 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/46eca5da-9ef2-454e-a83c-198234f20603o%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVeiqG4d4JX4Zb0_UKBGsDogrxheY6Yr6P8CF%2BO4%2BqAmMQ%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Slide]

We could remove the component from Kira for the plugin. It wouldn't stop
someone from opening one and assigning it to the wrong component, but
people assign to the wrong component all the time anyway.

On Wed, Jun 10, 2020, 02:47 Radosław Antoniuk 
wrote:

> Not sure I got the question right, but IMO it's each plugin's maintainer
> responsibility to transfer the issues from Jira to GH (with a pre-prepared
> solution I mentioned long ago).
> The question is how to prevent opening new issues in Jira afterwards, but
> this actually could be automated via a simple JQL looking for open issues
> in Jira that would be auto-closed with a message: "please report on
> plugin's github issues".
>
> --
> You received this message because you 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/CAPe2pWju%3DbHwSqCRUVo%3DzpgS%3DsTpEu9oorxAN_37nW_tG8QBhw%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/CAPiUgVdPecBxcKbUHwbh9kPSCRL6Eh3%2Ba6Z%2BoM7CabRqcSDLhA%40mail.gmail.com.

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Slide]

True, but I am not super sure that double the memory (e.g., m5a.large over
t2.medium) would make a big enough difference for almost double the cost. I
could be wrong though, I am definitely not an expert in java optimization,
etc.

On Fri, Jun 5, 2020 at 3:43 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Remember with more resources the tests can often run faster which reduces
> how much time the instance is needed for.
>
> It's never straight simple math
>
> On Fri., Jun. 5, 2020, 3:40 p.m. Slide,  wrote:
>
>> Just for reference...
>>
>> [image: image.png]
>> [image: image.png]
>> [image: image.png]
>>
>> t2.medium may be the way to go
>>
>> On Fri, Jun 5, 2020 at 2:32 PM Matt Sicker  wrote:
>>
>>> Looks like m5a are AMD and t2 are Intel (and burstable). If they cost
>>> similar, m5a sounds better.
>>>
>>> On Fri, Jun 5, 2020 at 4:19 PM Vlad Silverman 
>>> wrote:
>>> >
>>> > I don't know what the cost difference is between the t2 and m5a
>>> instances.
>>> >
>>> >
>>> > I guess it depends on the region.
>>> > More details are at https://aws.amazon.com/ec2/pricing/on-demand/
>>> >
>>> > On Jun 5, 2020, at 2:02 PM, Slide  wrote:
>>> >
>>> > We are currently using t2.small instances on EC2 for the non-high
>>> memory instances
>>> >
>>> > 
>>> >
>>> > Going from t2.small to t2.medium would double the CPU Credits / hour,
>>> though it also doubles vCPU count and Mem.
>>> >
>>> > The high mem instances are using m5.adxlarge:
>>> >
>>> > 
>>> >
>>> > I don't know what the cost difference is between the t2 and m5a
>>> instances.
>>> >
>>> > On Fri, Jun 5, 2020 at 1:40 PM Basil Crow  wrote:
>>> >>
>>> >> On Fri, Jun 5, 2020 at 1:24 PM Jesse Glick 
>>> wrote:
>>> >> > The next step would be PRs to infrastructure repositories.
>>> >>
>>> >> I agree. Unfortunately I have spent too much time on this issue
>>> already and
>>> >> cannot volunteer to become an infrastructure developer at present.
>>> >>
>>> >> > 256Mb seems low for a Surefire JVM—this needs to run Jenkins and all
>>> >> > plugins plus whatever your test code is doing.
>>> >>
>>> >> I agree, which is why I said "I worked around the problem" rather
>>> than "I
>>> >> solved the problem." Changing the JVM settings for Surefire and the
>>> agent
>>> >> launched by my tests was easy because both those JVMs were completely
>>> within
>>> >> my control. I agree that a long-term solution would involve setting
>>> -Xmx and
>>> >> -Xms on all agent and Maven JVMs as well as possibly increasing the
>>> EC2
>>> >> instance size for these nodes.
>>> >>
>>> >> --
>>> >> You received this message because you 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/CAFwNDjrjW2aA74pqoFMhca%2BD0YqL%3DWvNe46g7G1aM3Bmx5LrWQ%40mail.gmail.com
>>> .
>>> >
>>> >
>>> >
>>> > --
>>> > 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/CAPiUgVfTTqU65LN7iDo%2BMw5xPnCKFJfiTqq7kgcCtfXVMsN42w%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 

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Slide]

Just for reference...

[image: image.png]
[image: image.png]
[image: image.png]

t2.medium may be the way to go

On Fri, Jun 5, 2020 at 2:32 PM Matt Sicker  wrote:

> Looks like m5a are AMD and t2 are Intel (and burstable). If they cost
> similar, m5a sounds better.
>
> On Fri, Jun 5, 2020 at 4:19 PM Vlad Silverman 
> wrote:
> >
> > I don't know what the cost difference is between the t2 and m5a
> instances.
> >
> >
> > I guess it depends on the region.
> > More details are at https://aws.amazon.com/ec2/pricing/on-demand/
> >
> > On Jun 5, 2020, at 2:02 PM, Slide  wrote:
> >
> > We are currently using t2.small instances on EC2 for the non-high memory
> instances
> >
> > 
> >
> > Going from t2.small to t2.medium would double the CPU Credits / hour,
> though it also doubles vCPU count and Mem.
> >
> > The high mem instances are using m5.adxlarge:
> >
> > 
> >
> > I don't know what the cost difference is between the t2 and m5a
> instances.
> >
> > On Fri, Jun 5, 2020 at 1:40 PM Basil Crow  wrote:
> >>
> >> On Fri, Jun 5, 2020 at 1:24 PM Jesse Glick 
> wrote:
> >> > The next step would be PRs to infrastructure repositories.
> >>
> >> I agree. Unfortunately I have spent too much time on this issue already
> and
> >> cannot volunteer to become an infrastructure developer at present.
> >>
> >> > 256Mb seems low for a Surefire JVM—this needs to run Jenkins and all
> >> > plugins plus whatever your test code is doing.
> >>
> >> I agree, which is why I said "I worked around the problem" rather than
> "I
> >> solved the problem." Changing the JVM settings for Surefire and the
> agent
> >> launched by my tests was easy because both those JVMs were completely
> within
> >> my control. I agree that a long-term solution would involve setting
> -Xmx and
> >> -Xms on all agent and Maven JVMs as well as possibly increasing the EC2
> >> instance size for these nodes.
> >>
> >> --
> >> You received this message because you 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/CAFwNDjrjW2aA74pqoFMhca%2BD0YqL%3DWvNe46g7G1aM3Bmx5LrWQ%40mail.gmail.com
> .
> >
> >
> >
> > --
> > 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/CAPiUgVfTTqU65LN7iDo%2BMw5xPnCKFJfiTqq7kgcCtfXVMsN42w%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/FCEB4838-4FF8-410F-AEB3-6FACBDF98D80%40gmail.com
> .
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox0q94X6DA-iyhNwoEXXwZk98E5qN1da0ngO6XWCre2Vw%40mail.gmail.com
> .
>


-- 
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/CAPiUgVdB%2B1Yde21oead4b_BdfZS79C0af61__bMKC%2BtiXsNTLQ%40mail.gmail.com.

Re: Changing a plugin parameter type

[Slide]

Yes, definitely use a @DataBoundSetter, it will get called automatically
when the configuration is saved after the @DataBoundConstructor is called.

On Thu, Jun 4, 2020 at 3:00 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> You should be able to make @DataBoundSetter and make a setter
>
> I think I remember people saying that you need to at least leave the old
> constructor in place for legacy freestyle jobs. I know that's why I prefer
> setters.
>
> On Thu., Jun. 4, 2020, 1:43 p.m. John Westcott, <
> john.westcott...@redhat.com> wrote:
>
>> In the Jenkins Ansible Tower plugin I had a checkbox for importing logs.
>> In order to satisfy a new requirement I would like to change this into a
>> select menu. So I modified my code to switch from a true/false checkbox
>> into a select menu which has values of true, false, full and vars as
>> options.
>> My plugin supported both Freestyle and Pipeline Jenkins jobs.
>> After changing my code all existing freestyle jobs made the conversion
>> seamlessly an old boolean true or false values mapped into the string
>> values “true” and “false” without any issues.
>>
>> However, groovy scripts using the pipeline portion of the plugin are
>> throwing stack exceptions because the grooy scripts specify boolean values
>> like :
>> importTowerLogs = true,
>>
>> These values are not mapping to strings and Jenkins is putting out an
>> exception when running the pipeline:
>>
>> java.lang.ClassCastException: 
>> org.jenkinsci.plugins.ansible_tower.AnsibleTowerStep.importTowerLogs expects 
>> class java.lang.String but received class java.lang.Boolean
>>  at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.coerce(DescribableModel.java:492)
>>  at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.buildArguments(DescribableModel.java:409)
>>
>>  at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.buildArguments(DescribableModel.java:409)
>>
>>   at 
>> org.jenkinsci.plugins.structs.describable.DescribableModel.coerce(DescribableModel.java:492)
>>
>>
>> My old @DataBoundConstructor looked like:
>>
>> @DataBoundConstructor
>> public AnsibleTowerStep(@Nonnull String towerServer, Boolean 
>> importTowerLogs, Boolean param2, ...) {
>>
>>
>> My new constructor needs to be:
>>
>> @DataBoundConstructor
>> public AnsibleTowerStep(
>> @Nonnull String towerServer, String importTowerLogs, Boolean param2, 
>> ...) {
>>
>>
>> I tried having two @DataBoundConstructors, one for the old Boolean and
>> one for the String, but this caused an exception when compiling the plugin:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
>> (default-compile) on project ansible-tower: Compilation failure
>> [ERROR] javax.annotation.processing.FilerException: Attempt to reopen a
>> file for path
>> /Users/jowestco/IdeaProjects/ansible-tower-plugin/target/classes/org/jenkinsci/plugins/ansible_tower/AnsibleTowerStep.stapler
>> [ERROR] at
>> com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:535)
>> [ERROR] at
>> com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:431)
>> [ERROR] at
>> org.kohsuke.stapler.jsr269.AbstractProcessorImpl.createResource(AbstractProcessorImpl.java:81)
>>
>>
>>
>> After that I tried to have a constructor (not decorated with
>> @DataBoundConstructor) that would take a Boolean instead of a String and
>> would call my DataBoundConstructor like:
>>
>> public AnsibleTowerStep(@Nonnull String towerServer, Boolean 
>> importTowerLogs, Boolean param2, ...) { this(towerServer, 
>> importTowerLogs.toString(), param2…); }
>>
>> But the pipelines were unable to find and use this constructor and threw
>> the same stack trace as above.
>>
>> As another solution, I also tried to change the constructor to just an
>> Object like:
>>
>> @DataBoundConstructor
>> public AnsibleTowerStep(@Nonnull String towerServer, Object importTowerLogs, 
>> Boolean param2, ...) {
>>
>> With this the groovy scripts worked and I was able to use
>> importTowerLogs.toString() to get a string for either a boolean or string
>> object. Unfortunately, with this solution, the pipeline syntax generator
>> would raise an exception that it couldn’t convert a string param into an
>> object..
>>
>> Does anyone have any other ideas on how I may be able to achieve what I
>> am trying to do seamlessly (change a boolean field to a string)? Or do I
>> need to tell my users that the new version of my plugin requires changing
>> groovy scripts from 'importTowerLogs = true’ to ‘importTowerLogs = ‘true”’?
>> If making users update groovy scripts is my only solution, what are the
>> recommend way(s) to warn users about this change? Obviously I will put it
>> in the release nodes and spike it out somewhere in my README.md file as
>> well; but is there anything else I can/should do? i.e. can I mark the new
>> version of the plugin as using an 

Re: [EVENT]: Calling for Jenkins submissions

[Slide]

I would also like to help.

Thanks!

On Tue, Jun 2, 2020 at 8:31 AM Marky Jackson 
wrote:

> Good morning. I hope all is well and you and the family are healthy and
> mentally well in these crazy days.
> I too would like to be on the review committee.
> Thank you.
>
> {
> "regards" : {
>  "name" : “marky”,
>  "phone" : "+1 (408) 464 2965 <+1%20(408)%20464%202965>”,
>  "email" : “marky.r.jack...@gmail.com",
>  "team" : “jackson5“,
>  “role” : “software engineer"
>  }
>  }
>
> On Jun 2, 2020, at 8:27 AM, Alyssa Tong  wrote:
>
> 
> Hi Victor,
>
> Thank you so much for volunteering. I'll include your name to the list of
> reviewers. The CFP is closing this Friday, the plan is to begin voting on
> June 8. Standby for more details to come. Thank you again.
>
> BR,
> alyssa
>
> On Tue, Jun 2, 2020 at 7:05 AM Victor Martinez <
> victormartinezru...@gmail.com> wrote:
>
>> Hi Alyssa,
>>
>> Thanks for your heads up, I hope you are doing great, just a quick one: I'd
>> like to volunteer to be a member of review committee for the upcoming
>> DevOps World, who should I ask for permissions?
>>
>> Thanks again :)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/71beb4d8-b64d-4952-ac71-fcb7ba680eed%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/CAMBsfbttQJF%2BT5kLEnF5382R80x5uP-BwDBadqBDF8uhENLGeg%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/AA191397-260C-4763-AB2B-0BF49775BB61%40gmail.com
> 
> .
>


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

Re: Proposal: Windows support policy for Jenkins

[Slide]

It's possible we could test on a Windows 10 VM on Azure/AWS. I could look
into that.

On Thu, May 28, 2020 at 12:46 PM Mark Waite 
wrote:

> +1 from me.  I test Windows 10 more than I test any other Windows
> version.  I'm quite fine with it being Tier 1 or Tier 2.  Either is fine
> with me.
>
> On Thursday, May 28, 2020 at 1:14:55 PM UTC-6, Oleg Nenashev wrote:
>>
>> The policy draft was approved at the last governance meeting. After it
>> there were some changes in the pull request, mostly spelling ones. The only
>> notable change is moving Windows 10 amd-64 support from Tier 1 to Tier 2,
>> because we do not actually test it in our CICD flows.
>>
>> Tier 2 still means "supported", so I think we are fine. Is everyone fine
>> with merging the support policy?
>>
>> Thanks in advance,
>> Oleg
>>
>>
>>
>>
>> On Tuesday, May 19, 2020 at 3:13:10 PM UTC+2, Oleg Nenashev wrote:
>>>
>>> Hi all,
>>>
>>> I have submitted a pull request with a draft policy:
>>> https://github.com/jenkins-infra/jenkins.io/pull/3295 .
>>> I will appreciate any feedback from those who is running Jenkins on
>>> Windows.
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Tuesday, April 14, 2020 at 3:02:04 PM UTC+2, Olblak wrote:

 I like Oleg proposition very much as it clarifies the different levels
 of support, and it solves Daniel concerned.
 We won't run any tests on deprecated infrastructure like XP.

 On Tue, Apr 14, 2020, at 12:41 PM, Oleg Nenashev wrote:

 Taking the feedback, should we introduce support levels like we do with
 the browser support policy?

 * Level 1 - full support. We run automated testing for these platforms
   - amd64 versions of latest Windows and Windows Server versions, with
 the latest GA update pack (we will need to specify editions in the final
 policy)
   - versions in our soon-to-be-official Docker packages (at the moment:
 windowsservercore and nanoserver 1809)
 * Level 2 - generally supported. We do not actively test it, but we
 intend to keep compatibility, and we are happy to accept patches
   - Windows and Windows Server 64bit versions which are generally
 supported by MS
 * Level 3 - Best effort - We will consider patches if they do not put
 Level 1/2 support at risk and if they do not create bug maintenance
 overhead. Support may have limitations and extra requirements. We do not
 test compatibility, and we may drop support if there is a need
   - x86 and other non-amd64 architectures
   - "exotic" windows versions like Windows Embedded
   - Preview releases and updates by Microsoft
   - Windows API emulation systems like Wine or ReactOS
 * Level 4 - Unsupported
   - Platforms and OS versions which are known to be incompatible or
 which have severe limitations

 Best regards,
 Oleg




 On Sat, Apr 11, 2020, 02:05 Daniel Beck  wrote:



 > On 10. Apr 2020, at 14:26, Oleg Nenashev  wrote:
 >
 > I know for sure that there are Jenkins users running on Windows XP

 That's no reason to enable this insanity.

 I would advocate for just going with what's generally supported by
 Microsoft: Extended support would be in, "throwing bags of money at
 Microsoft" support is out, i.e. Windows 7 would have been unsupported since
 January.

 This approach would also address the problem of not having to manually
 keep the policy up to date. As we've seen with the browser support policy,
 nobody will update it.
 Additionally, this has the benefit of being fairly objective criteria,
 and would also save us from having to have this conversation again in two
 years.

 (And TBH I would just ignore Windows Embedded Industry, seems like a
 lot of effort for very few users.)

 Note also that this doesn't mean that Jenkins on these OSes would
 necessarily immediately break. If there's a new enough .NET Framework or
 whatever on Windows 7, and there's no reason to go with something newer,
 then Windows 7 will just continue to work. But users would know that they
 cannot indefinitely rely on it.

 Obviously I'm +1 for whatever makes it easier for you to support these
 components, even if it's just small steps.

 --
 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/oK8pBCzPPpo/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 jenkin...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/C643B021-1451-4E76-921B-CD9543BA2C86%40beckweb.net
 .


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

Re: Unable to perform plugin release to repo.jenkins-ci.org

[Slide]

Great, glad things are working for you. I haven't used the method with
Artifactory, so I didn't know if it worked or not :)

On Tue, May 26, 2020 at 7:32 AM Tyler Camp 
wrote:

> Mez and slide, the password provided by artifactory did end up working. I
> tried the encryption method that you mentioned, slide, and got a password
> significantly different from artifactory that did not work.
>
> Thank you for your suggestion Daniel, after making that change (leftover
> from very old pom) and restarting the release process I was able to deploy
> our release using the encrypted artifactory password.
>
> On Saturday, May 23, 2020 at 3:27:39 AM UTC-4, Daniel Beck wrote:
>>
>> If your plugin overrides the distributionManagement, as in
>>
>>
>> https://github.com/jenkinsci/codedx-plugin/blob/d56180188ae138677f09214f57c1b8d840375477/pom.xml#L70-L75
>>
>> our instructions no longer apply.
>>
>> In this case, it is named 'repo.jenkins-ci.org', not the default '
>> maven.jenkins-ci.org', so the credentials need to be changed to apply to
>> the same server ID.
>>
>> Although the real fix is to rip out this nonsense from the pom.xml.
>>
>>
>> > On 22. May 2020, at 19:21, Tyler Camp  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/7eae5673-f8eb-4bb5-b5f4-442b0dc4b7d6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/7eae5673-f8eb-4bb5-b5f4-442b0dc4b7d6%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVd1N5O-iZ9VLFNq-GPBPpjn3MPioxiDDEhzOd%2Bi65VzBA%40mail.gmail.com.

Re: regarding issues publishing new plugin, but publishing works when publishing a snapshot

[Slide]

According to https://www.jenkins.io/doc/developer/publishing/releasing/ 403
means the permissions are not setup. It's possible you just need to wait a
little bit and try again.

On Fri, May 22, 2020, 18:15 john rowley  wrote:

> Hello,
>
>
>
> I recently went through the process of developing a Jenkins plugin,
> getting it hosted, getting permissions for publishing to artifactory, etc.
> Everything was working correctly until I attempted to release the plugin.
>
>
>
> I was able to release a snapshot of the plugin, and this worked fine. The
> artifacts appear to all have been uploaded successfully, to the following
> URL.
> https://repo.jenkins-ci.org/snapshots/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.1-SNAPSHOT/
>  Upon
> bumping and attempting to release the plugin I encountered 403 errors from
> artifactory.
>
>
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-
> plugin:2.8.2:deploy (default-deploy) on project bitbucket-kubernetes-
> credentials: Failed to deploy artifacts: Could not transfer artifact io.
> jenkins.plugins:bitbucket-kubernetes-credentials:hpi:0.0.3 from/to maven.
> jenkins-ci.org (https://repo.jenkins-ci.org/releases/): Authorization
> failed for
> https://repo.jenkins-ci.org/releases/io/jenkins/plugins/bitbucket-kubernetes-credentials/0.0.3/bitbucket-kubernetes-credentials-0.0.3.hpi
> 403 Forbidden -> [Help 1]
>
>
>
> I did create a pull request and get permissions to release this plugin
> several hours ago, and I believe that the yaml for the
> repository-permissions-updater  is correct, firstly because it was looked
> over during the PR, secondly because I was able to upload to the snapshots
> path, but not the releases path.
> https://github.com/robbert229/repository-permissions-updater/blob/master/permissions/plugin-bitbucket-kubernetes-credentials.yml
>
>
>
> What are the steps I should take to begin debugging this, and what could I
> possibly have done wrong?
>
>
>
> 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/415bea83-484c-4d77-8526-8bf278b0e646%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/CAPiUgVfnC-SV60TTnjzEAmVYx9j%3D9h5Z9-gMyYOzD4oEORujtg%40mail.gmail.com.

Re: Unable to perform plugin release to repo.jenkins-ci.org

[Slide]

I think you need to follow this howto for getting the correct encrypted
password for the settings.xml.
https://www.roytuts.com/encrypt-user-passwords-in-maven-settings/




On Fri, May 22, 2020 at 4:01 PM Tyler Camp 
wrote:

> Yes, I've double-checked everything on that list before posting here. This
> is my first time performing a release.
>
> On Friday, May 22, 2020 at 5:11:17 PM UTC-4, slide wrote:
>>
>> Can you take a quick look at this page and make sure you have everything
>> covered?  https://www.jenkins.io/doc/developer/publishing/releasing/
>> <https://www.jenkins.io/doc/developer/publishing/releasing/#Troubleshooting>.
>> Have you released before?
>>
>> On Fri, May 22, 2020 at 10:30 AM Tyler Camp 
>> wrote:
>>
>>> I’m attempting to release the latest Code Dx plugin (
>>> https://github.com/jenkinsci/codedx-plugin) but am getting HTTP 401
>>> responses when running `mvn release:perform`. Parent POM is latest at 4.2,
>>> and I have my maven settings at `C:/Users/algor/.m2/settings.xml`
>>> containing:
>>>
>>>
>>>
>>> https://maven.apache.org/SETTINGS/1.0.0;
>>>
>>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>>
>>>   xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0
>>>
>>>   https://maven.apache.org/xsd/settings-1.0.0.xsd;>
>>>
>>>
>>>
>>>   
>>>
>>> 
>>>
>>>   maven.jenkins-ci.org
>>>
>>>   tylercamp
>>>
>>>   REDACTED-ENCRYPTED-PASSWORD
>>>
>>> 
>>>
>>>   
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> Encrypted password was pulled from
>>> https://repo.jenkins-ci.org/webapp/#/profile . My account was
>>> registered with `jenkins-infrra/repository-permissions-updater` repo:
>>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-codedx.yml
>>>
>>>
>>>
>>> Relevant log lines:
>>>
>>>
>>>
>>> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
>>> codedx ---
>>>
>>> Uploading to repo.jenkins-ci.org:
>>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.hpi
>>>
>>> Uploading to repo.jenkins-ci.org:
>>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.pom
>>>
>>> [INFO]
>>> 
>>>
>>> [INFO] BUILD FAILURE
>>>
>>> [INFO]
>>> 
>>>
>>> [INFO] Total time:  23.104 s
>>>
>>> [INFO] Finished at: 2020-05-22T13:09:05-04:00
>>>
>>> [INFO]
>>> 
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
>>> on project codedx: Failed to deploy artifacts: Could not transfer artifact
>>> org.jenkins-ci.plugins:codedx:hpi:3.0.0 from/to repo.jenkins-ci.org (
>>> https://repo.jenkins-ci.org/releases): Transfer failed for
>>> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.hpi
>>> 401 Unauthorized -> [Help 1]
>>>
>>> [ERROR]
>>>
>>>
>>>
>>> Let me know if there’s more information I should attach for
>>> troubleshooting this. Any help appreciated.
>>>
>>> --
>>> You received this message because you 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/2166ff20-524a-40ab-9b31-928b407f1f83%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/2166ff20-524a-40ab-9b31-928b407f1f83%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> 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/d9ee0d80-d4c1-41f4-a8f0-be82e4eb05fd%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/d9ee0d80-d4c1-41f4-a8f0-be82e4eb05fd%40googlegroups.com?utm_medium=email_source=footer>
> .
>


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

Re: Unable to perform plugin release to repo.jenkins-ci.org

[Slide]

Can you take a quick look at this page and make sure you have everything
covered?  https://www.jenkins.io/doc/developer/publishing/releasing/
.
Have you released before?

On Fri, May 22, 2020 at 10:30 AM Tyler Camp 
wrote:

> I’m attempting to release the latest Code Dx plugin (
> https://github.com/jenkinsci/codedx-plugin) but am getting HTTP 401
> responses when running `mvn release:perform`. Parent POM is latest at 4.2,
> and I have my maven settings at `C:/Users/algor/.m2/settings.xml`
> containing:
>
>
>
> https://maven.apache.org/SETTINGS/1.0.0;
>
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>
>   xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0
>
>   https://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
>
>   
>
> 
>
>   maven.jenkins-ci.org
>
>   tylercamp
>
>   REDACTED-ENCRYPTED-PASSWORD
>
> 
>
>   
>
>
>
> 
>
>
>
> Encrypted password was pulled from
> https://repo.jenkins-ci.org/webapp/#/profile . My account was registered
> with `jenkins-infrra/repository-permissions-updater` repo:
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-codedx.yml
>
>
>
> Relevant log lines:
>
>
>
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ codedx
> ---
>
> Uploading to repo.jenkins-ci.org:
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.hpi
>
> Uploading to repo.jenkins-ci.org:
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.pom
>
> [INFO]
> 
>
> [INFO] BUILD FAILURE
>
> [INFO]
> 
>
> [INFO] Total time:  23.104 s
>
> [INFO] Finished at: 2020-05-22T13:09:05-04:00
>
> [INFO]
> 
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
> on project codedx: Failed to deploy artifacts: Could not transfer artifact
> org.jenkins-ci.plugins:codedx:hpi:3.0.0 from/to repo.jenkins-ci.org (
> https://repo.jenkins-ci.org/releases): Transfer failed for
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/codedx/3.0.0/codedx-3.0.0.hpi
> 401 Unauthorized -> [Help 1]
>
> [ERROR]
>
>
>
> Let me know if there’s more information I should attach for
> troubleshooting this. Any help appreciated.
>
> --
> You received this message because you 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/2166ff20-524a-40ab-9b31-928b407f1f83%40googlegroups.com
> 
> .
>


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

Re: Jenkins Governance Meeting on May 20, 6PM UTC

[Slide]

I will not be at the meeting, but I have read all the proposals and vote +1
for each of them.

On Wed, May 20, 2020, 07:09 Mark Waite  wrote:

> Zoom is my preferred format for the meeting so that we can see the
> documents live.  I think it would help to show a brief example of the UI/UX
> Hackfest repository in the session.
>
> On Wed, May 20, 2020 at 7:53 AM Oleg Nenashev 
> wrote:
>
>> Hi all,
>>
>> Today we will have a regular Jenkins Governance meeting.
>>
>> Tentative agenda (please feel free to suggest topics here
>> 
>> ):
>>
>>-
>>
>>News!
>>-
>>
>>   Google Season of Docs application results
>>   -
>>
>>  https://www.jenkins.io/sigs/docs/gsod/
>>  -
>>
>>   Cloud Native SIG update
>>   -
>>
>>
>>  https://groups.google.com/forum/#!topic/jenkinsci-dev/nuOedyIwfyw
>>  -
>>
>>   Jenkins UI/UX Hackfest updates
>>   -
>>
>>  https://www.jenkins.io/events/online-hackfest/2020-uiux/
>>  -
>>
>>Approving hosting the repository for UI/UX Hackfest in jenkinsci
>>(Oleg)
>>-
>>
>>   https://groups.google.com/forum/#!topic/jenkinsci-dev/zyDqjWhwzd4
>>   -
>>
>>   https://github.com/oleg-nenashev/jenkins-uiux-hackfest-2020
>>   -
>>
>>Approving the UI Themes Support policy (Oleg)
>>-
>>
>>   https://groups.google.com/forum/#!topic/jenkinsci-dev/NouXPVtrd0c
>>   -
>>
>>   https://github.com/jenkins-infra/jenkins.io/pull/3292
>>   -
>>
>>   Voting: Approving the suggested policy
>>   -
>>
>>Approving the Windows Support policy proposal (Oleg)
>>-
>>
>>
>>   
>> https://groups.google.com/forum/#!msg/jenkinsci-dev/oK8pBCzPPpo/1Ue1DI4TAQAJ
>>   -
>>
>>   https://github.com/jenkins-infra/jenkins.io/pull/3295
>>
>>
>> Also, classic question about IRC or Zoom. Any preferences? :)
>>
>> 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/248253cf-476c-4da5-94cd-8ce36604fc2b%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/CAO49JtF_nLay6KBEyEkTr2H5_FiRoyO8ONc2%2B6zo1QrGCKON2A%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/CAPiUgVeMYZBtKQ76m7_h1%3DOHXRb2ihSAEJcnaXiP7K%3Dq55DHaA%40mail.gmail.com.

Re: Proposal: Making the Hosting team official (and onboarding new members)

[slide]

FYI, there are a couple of hosting requests that could use a review right 
now if anyone wants to take a look. I am going to put up a page on 
jenkins.io for things to look for in the code. I would recommend waiting 
until the automated checker (it shows up as me, Alex Earl) marks things as 
good to go for a human review of the code. Before that happens, the 
developers of the plugin need to have certain things in place and correct 
before we even consider doing a review of the code. I'll try and get that 
doc up on jenkins.io this week.

On Friday, May 15, 2020 at 6:51:33 AM UTC-7, YanJun Shi wrote:
>
> Okay. Thank you for your help, Oleg. I already have done the 4 steps, Is 
> there any other steps I need to do？
>
>
>1. 
>
>Subscribe to the Jenkins Developer Mailing list 
>
>2. 
>
>Subscribe to the HOSTING project 
> in Jenkins Jira
>3. 
>
>Subscribe to the Repository Permission Updater 
>
> repository
>4. 
>
>Subscribe to the Jenkins Update Center 
> repository
>
>
> On Fri, May 15, 2020 at 3:58 AM Oleg Nenashev  
> wrote:
>
>> Hi, thanks for your interest! You are welcome to join and to start 
>> contributing to hosting reviews. No special permissions needed to get 
>> started: 
>> https://www.jenkins.io/project/teams/hosting/#assisting-with-qa-and-request-reviews
>>
>> And thanks for submitting ICLA!
>>
>> On Sun, May 10, 2020, 04:45 YanJun Shi  wrote:
>>
>>> I hope to join this team and contribute my strength
>>>
>>> On Wednesday, April 29, 2020 at 5:09:27 PM UTC+8, Oleg Nenashev wrote:

 Hi all,


 In the Jenkins community we have an unofficial Hosting team which 
 handles various requests related to plugin hosting (forking/transferring 
 plugins, managing permissions and update center blacklists, etc.) There 
 are 
 multiple contributors involved in this activity on a regular basis, and it 
 would be great to document these processes so that we could use these docs 
 as a reference and as guidelines for onboarding new contributors to help 
 with the hosting process. I would propose to create an official team and 
 to 
 introduce an onboarding process:

 Proposal

- Make the "Hosting Team" official, document its roles somewhere on 
jenkins.io. Scope: plugin and component hosting on Jenkins 
resources (GitHub, Update Centers, etc.)
- Grant permissions to active contributors who are interested and 
who already have experience with the hosting process (e.g. Tim Jacomb, 
Wadeck Follonier)
- Create new HOSTING/Mailing list triage guidelines
- Invite interested contributors to help with triage of hosting 
requests as a first onboarding step to get permissions needed for 
 GitHub / 
Update Site and Repository Permission Updater management

 Team Responsibilities. Below there are some current responsibilities 
 related to the hosting process. This list is likely incomplete, please 
 feel 
 free to add more items.

- Triage and processing of new plugin HOSTING requests in Jenkins 
Jira. Currently Alex Earl champions it, and there are only a few 
contributors who help with the requests triage. Such triage is 
 instrumental 
to...
   - Ensuring hosted plugins have proper artifactIds. We cannot 
   easily change them later...
   - Do sanity check of plugins for security issues. Thanks to Alex 
   Earl and the security team for handling it
   - Checking for duplication with existing plugins 
   
 
  
   and offering to contribute there instead of hosting a new plugin 
 (but not 
   blocking hosting)
   - Plugin licenses (see this thread 
   
   )
- Processing plugin release permissions in Repository Permission 
Updater 
. 
There is a @jenkins-infra/hosting 
 team handling 
it (Alex Earl, Baptiste Mathus and me)
- Processing GitHub permission and Plugin adoption 

  
requests in the developer mailing list. There is a number of 
 contributors 
replying to these requests, most of operations can be done via Jenkins 
IRC bot 

Re: doxygen and msbuild plugins up for adoption

[Slide]

I added the topic to both repos.

Regards,

Alex

On Sat, May 16, 2020 at 1:52 AM Lionel Cabasson 
wrote:

> Hello,
>
> I've been maintaining msbuild and doxygen plugins for some months but I
> don't manage to find the time required to keep going unfortunately.
> I would like to set both of these plugins as up for adoption so that
> someone else could take the lead and provide updates more often.
>
> Can someone please help me mark these plugins as up for adoption ?
> I do not have the "Manage topics" link on GitHub repositories.
>
> Thank you
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c079b530-a793-4dca-a840-4135831eb3dc%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVe-6znuRptivx-zZPKSopF6XH1YqDA8U33OOKm%3DE701jw%40mail.gmail.com.

Re: ANN: Agent Docker images renaming on April 12-13

[Slide]

It might be better to start a new thread instead or reusing this one. FYI,
you should be using jenkins/inbound-agent instead of jenkins/jnlp-slave.
The latest will be Java 8, not Java 11.

On Mon, May 11, 2020 at 7:55 AM Jon Brohauge  wrote:

> Hi All,
>
> I've been mulling over my attempt to do a custom jenkins-agent for a few
> days now. Starting out by using the jenkinsci/jnlp-agent, and building
> stuff in on it from there. Creating my docker image is successful. Using
> the custom-agent in my ecs cluster works. Using it in my kubernetes
> cluster, not so much. I can see that the container spins up using "kubectl
> --namespace jenkins describe pods [custom-agent-instance]"
>
> From what I observe my custom-agent gets spun up alongside an obligatory
> "jenkins/jnlp-slave:4.0.1-1". AFAICT trying to do a simple "java -version"
> does not show the version of java that I have inside my own agent-image,
> but the version in the jnlp-slave image. I followed the excellent video
> tutorial by Marky Jackson (https://www.youtube.com/watch?v=h4hKSXjCqyI).
> I have even tried to do the same test "java -vertsion" with the
> jenkins/jnlp-slave:latest, which should show java 11. However same result
> as before. What am I doing wrong? Somehow pipeline does not get handed over
> to "my" image.
>
> Any help is appreciated
>
> Regards,
> Jon
>
> --
> You received this message because you 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/667d4499-09b6-4bab-a8cc-85a3d61e5c46%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVfqYO2Mg0nEb4B_jkHN7U1Qh-4_%3Dz7OHmRjv-LL39WiMA%40mail.gmail.com.

Re: Instability on ci.jenkins.io Ubuntu EC2 agents

[Slide]

Hi Chris,

You can also close and reopen (after about 30 seconds) the PR and it will
build again.

Regards,

Alex

On Thu, May 7, 2020 at 11:18 AM Chris Kilding <
chris+jenk...@chriskilding.com> wrote:

> Hi Mark,
>
> Thanks, that explains it. Off-hand thought - can AWS PrivateLink - or the
> Azure equivalent - do anything to improve connection reliability in our
> multi cloud setup? (I know these services are more intended for on prem to
> cloud links, but maybe it can help here.)
>
> In the meantime my workaround is to push trivial commits when I need it to
> try again. That suffices during PR development, but I can’t do that in
> master for the fun of it.
>
> Chris
>
> On Thu, 7 May 2020, at 4:12 PM, Mark Waite wrote:
>
>
>
> On Thu, May 7, 2020 at 8:27 AM Chris Kilding <
> chris+jenk...@chriskilding.com> wrote:
>
> Hi,
>
> I'm seeing a range of instability on the Ubuntu EC2 build agents on
> ci.jenkins.io over the past week, including tests randomly taking forever
> and timing out, and instances randomly being terminated mid-build.
>
>
> Yes, plenty of ideas, but no solutions yet.  Sorry for the unreliability
> of those build agents.
>
> We were hosting all our build agents in Azure when Microsoft was
> sponsoring the Jenkins project infrastructure.  That sponsorship expired
> late in 2019 so that the Jenkins project was paying the full price of its
> infrastructure hosted on Azure.
>
> AWS became a sponsor in early 2020.  In order to immediately reduce costs,
> we've added AWS EC2 agents using the EC2 plugin.  The Jenkins master and
> the Jenkins containerized agents ("ACI") continue to run on Azure for now,
> while the Ubuntu agents are now provisioned by the EC2 plugin.
>
> Unfortunately, the agents provisioned by the EC2 plugin randomly lose
> their connection to the Jenkins master on Azure.  That loss of connection
> disrupts the job that is running on the agent and causes the types of
> annoying behaviors that you have seen.
>
> We're currently putting first focus on completing the core release
> automation project so that we can deliver Jenkins weekly, LTS, and security
> releases without requiring Kohsuke perform the release.  Jenkins weekly
> releases 2.232, 2.233, and 2.234 were delivered from core release
> automation without requiring Kohsuke take any action.  We're working on the
> automation for long term support releases and for security releases.
>
> Intense focus on the EC2 agent connection failures will have to wait until
> we either have more people to assist with infrastructure or we have
> completed the core release automation project.  Those who would like to
> assist with Jenkins infrastructure are welcome to join the weekly
> infrastructure meetings and to chat on the IRC channel #jenkins-infra.
>
> Thanks,
> Mark Waite
>
>
>
> This didn't used to happen previously when I think the builds were running
> in Azure.
>
> Any ideas?
>
> Chris
>
> --
> You received this message because you 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/cd9d4a3d-fdfb-460a-805b-7bfb12d47d2d%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/CAO49JtGSCj8ZzE1OYJZJRB37S9Kz-6r9eidccN9GFRFg9adphQ%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/5ba67aca-768c-4b63-a80c-79fb00d5eadd%40www.fastmail.com
> 
> .
>


-- 
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/CAPiUgVc0ymy%3DE0%3DEQ0Hmp%2B6GpR-iXVNmSQew%2BiXMrwCpSBbQCQ%40mail.gmail.com.

Re: Jenkins Governance meeting on May 06

[Slide]

I'm good either way, but since Tracy and Alyssa would prefer Zoom, I'll
throw my hat in with them and say let's do Zoom.

On Tue, May 5, 2020 at 1:27 PM Alyssa Tong  wrote:

> +1 for zoom as well
>
> On Tue, May 5, 2020 at 11:00 AM Tracy Miranda 
> wrote:
>
>> Thanks Oleg.
>>
>> +1 for zoom call so we can all see the Jenkins is the way logo &
>> jumbotron proposal
>>
>> Tracy
>>
>> On Tue, May 5, 2020 at 1:21 PM Oleg Nenashev 
>> wrote:
>>
>>> Hi all,
>>>
>>> Tomorrow we will have the next regular Governance meeting in the Jenkins
>>> project.
>>> Current agenda draft:
>>>
>>>-
>>>
>>>News!
>>>-
>>>
>>>   LTS baseline selection and 2.222.3 backporting
>>>   -
>>>
>>>   Roadmap updates (Oleg)
>>>   -
>>>
>>>   GSoC updates (Oleg)
>>>   -
>>>
>>>Jenkins is the Way initiative (Mark Waite & Alyssa Tong)
>>>-
>>>
>>>   Approving the Jenkins is the Way on the Jumbotron
>>>    (Mark
>>>   Waite)
>>>   -
>>>
>>>
>>>  https://groups.google.com/forum/#!topic/jenkinsci-dev/xnloE4x_tgg
>>>  -
>>>
>>>Jenkins Governance Roadmap and documentation items approvals:
>>>-
>>>
>>>   Roadmap items:
>>>   https://github.com/jenkins-infra/jenkins.io/pull/3164
>>>   -
>>>
>>>   Board elections page edits:
>>>   https://github.com/jenkins-infra/jenkins.io/pull/3165
>>>   -
>>>
>>>   Code of Conduct edits:
>>>   https://github.com/jenkins-infra/jenkins.io/pull/3136
>>>   -
>>>
>>>Next meeting
>>>
>>>
>>> If you would like to add any other topics to the agenda, please suggest
>>> them here
>>> 
>>> .
>>>
>>> Also, there is an open question about how we do it: IRC or Zoom video
>>> call (like last time). Feedback from potential participants would be
>>> appreciated!
>>>
>>> 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/f72bbf41-d965-4706-a976-37fb51ad2fdb%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/CACTaz6pdfwABEWjY2nNv052_%2BwCDsavGeURTcPycrVwk%3DSJNrw%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/CAC9wNayAMbgaf8hAEFuZ0GrBndNx2GCAhFrWo2aVuG79rZx3wA%40mail.gmail.com
> 
> .
>


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

Re: Jenkins-Infra pipeline library changes issue

[Slide]

On Mon, May 4, 2020 at 5:53 PM Richard Bywater  wrote:

> On Tue, 5 May 2020 at 01:01, Jesse Glick  wrote:
>
>> > I've got the build to work again by removing recommendedConfigurations
>> and switching to explicitly building the minimum version of Jenkins that is
>> referenced in the pom.xml
>>
>> This makes no sense. If you _only_ want to build the version
>> referenced in `pom.xml`, just
>>
>> buildPlugin()
>>
>> The point of `configurations` is to build against _newer_ versions as
>> well.
>>
>
> Thanks - I didn't realise that. After reading the README
> https://github.com/jenkins-infra/pipeline-library I wasn't clear on what
> the default behaviour was if you didn't specify any of the optional
> arguments. I'm also confused by the statement "Gradle support in
> buildPlugin() is deprecated and will be eventually removed. Please use
> buildPluginWithGradle()". Is that actually accurate? Should we be using
> Gradle builds by default now?
>
>

This just means that if you use Gradle to build your plugin, you should not
be using buildPlugin() anymore, you should use buildPluginWithGradle()
instead. Maven builds are still the normal and most supported method for
building Jenkins plugins.

-- 
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/CAPiUgVd%2BvoxjEASVCO30C9iobk2aDGp2fwZNWjvSj4P1X-uLyQ%40mail.gmail.com.

Re: Jenkins Plugin Open Source Group ID

[Slide]

We request using io.jenkins.plugins, but if you already have something for
your company, you are welcome to use that as well. As Jesse mentioned, its
the artifactId that is the most important to get right.

On Mon, May 4, 2020 at 9:47 AM Jesse Glick  wrote:

> The group ID is mostly irrelevant. The artifact ID becomes the plugin
> identifier, which may never be changed once released.
>
> --
> You received this message because you 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/CANfRfr17t2QRor582eFzepPPQSk76tU5Jd%3DO-WG2NWQS8zB0fQ%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVdw7pSqw2HoK1%2BsQpk2kMiQMra67KOu-qF2XOvGUPCpWQ%40mail.gmail.com.

Re: Proposal: Making the Hosting team official (and onboarding new members)

[Slide]

I'm a definite +1 on this. More people looking at the requests and such
would definitely be helpful and more people means more ideas on how to
streamline and improve the process.

On Wed, Apr 29, 2020 at 5:38 AM Oleg Nenashev 
wrote:

> Thanks Tim and Marky,
>
> Any help there will be appreciated, any bandwidth improvements and higher
> bus factor would be great.
> Will wait for feedback from Alex Earl and other contributors before
> touching permissions, working on guidelines.
>
> Everyone is welcome to subscribe to channels (dev mailing list, HOSTING
> project in Jira, reporsitory-permission-updater).
> No special permissions needed to do that and to start contributing and
> helping users there.
>
> BR, Oleg
>
> On Wednesday, April 29, 2020 at 2:06:25 PM UTC+2, Tim Jacomb wrote:
>>
>> +1 to both, although not planning on it being a primary focus, I'll help
>> out where and when I can
>>
>> Thanks
>> Tim
>>
>> On Wed, 29 Apr 2020 at 13:02, Marky Jackson  wrote:
>>
>>> For me it is both. +1 for the proposal and +1 to join
>>>
>>> On Apr 29, 2020, at 5:01 AM, Oleg Nenashev  wrote:
>>>
>>> Hi all. Just to make sure, +1 for the proposal or +1 for joining the
>>> teams? :)
>>>
>>> On Wed, Apr 29, 2020, 13:58 Marky Jackson  wrote:
>>>
 This is a great idea and I am a +1

 On Wednesday, April 29, 2020 at 2:09:27 AM UTC-7, Oleg Nenashev wrote:
>
> Hi all,
>
>
> In the Jenkins community we have an unofficial Hosting team which
> handles various requests related to plugin hosting (forking/transferring
> plugins, managing permissions and update center blacklists, etc.) There 
> are
> multiple contributors involved in this activity on a regular basis, and it
> would be great to document these processes so that we could use these docs
> as a reference and as guidelines for onboarding new contributors to help
> with the hosting process. I would propose to create an official team and 
> to
> introduce an onboarding process:
>
> Proposal
>
>- Make the "Hosting Team" official, document its roles somewhere on
> jenkins.io. Scope: plugin and component hosting on Jenkins
>resources (GitHub, Update Centers, etc.)
>- Grant permissions to active contributors who are interested and
>who already have experience with the hosting process (e.g. Tim Jacomb,
>Wadeck Follonier)
>- Create new HOSTING/Mailing list triage guidelines
>- Invite interested contributors to help with triage of hosting
>requests as a first onboarding step to get permissions needed for 
> GitHub /
>Update Site and Repository Permission Updater management
>
> Team Responsibilities. Below there are some current responsibilities
> related to the hosting process. This list is likely incomplete, please 
> feel
> free to add more items.
>
>- Triage and processing of new plugin HOSTING requests in Jenkins
>Jira. Currently Alex Earl champions it, and there are only a few
>contributors who help with the requests triage. Such triage is 
> instrumental
>to...
>   - Ensuring hosted plugins have proper artifactIds. We cannot
>   easily change them later...
>   - Do sanity check of plugins for security issues. Thanks to
>   Alex Earl and the security team for handling it
>   - Checking for duplication with existing plugins
>   
> 
>and offering to contribute there instead of hosting a new
>   plugin (but not blocking hosting)
>   - Plugin licenses (see this thread
>   
>   )
>- Processing plugin release permissions in Repository Permission
>Updater
>.
>There is a @jenkins-infra/hosting
> team
>handling it (Alex Earl, Baptiste Mathus and me)
>- Processing GitHub permission and Plugin adoption
>
> 
> requests in the developer mailing list. There is a number of
>contributors replying to these requests, most of operations can be 
> done via
>Jenkins IRC bot
>
>- Manual changes in GitHub repositories for some requests, e.g.
>plugin renaming. There is a @jenkinsci/github-admins
> team which
>manages such requests
>- Processing repo transfer requests (when maintainers want to
>transfer plugins instead of forking), via jenkinsci-transfer org or
>directly. There is a 

Re: Plugin: Liquibase Runner

[Slide]

Baptiste closed and reopened which caused another build, it looks good now.

On Tue, Apr 28, 2020 at 6:56 AM Robert Reeves  wrote:

> Hi, team!
>
>
>
> My PR to grant access to my GitHub/Jenkins.io account (they’re the same),
> had an issue with the automated checks. I’m not sure what I can do here to
> fix it:
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1513
>
>
>
> Thanks!
>
>
>
> Robert
>
>
>
> *From:* ga...@gavinmogan.com  * On Behalf Of *'Gavin
> Mogan' via Jenkins Developers
> *Sent:* Monday, April 27, 2020 2:00 PM
> *To:* Jenkins Developers 
> *Cc:* Keith Collison ; Daniel Beck ;
> Nathan Voxland 
> *Subject:* Re: Plugin: Liquibase Runner
>
>
>
> A bunch of us can add GitHub ids to the teams via IRC. We just need to
> know GitHub ids. You can also update the contributors directly inside the
> repo, but the teams and org access is the recommended way.
>
>
>
> If your talking about releases, you need to make a PR to the permission
> updater repo.
> https://github.com/jenkins-infra/repository-permissions-updater
>
> On Mon., Apr. 27, 2020, 9:26 a.m. Robert Reeves,  wrote:
>
> Hi, Team!
>
>
>
> Keith has been great. He’s accepted our PR and added my r2datical GH
> account to the repos at
> https://github.com/jenkinsci/liquibase-runner-plugin.
>
>
>
> However, we still need to add Nathan. How do we add GH account nvoxland to
> the Jenkins CI group so that Keith can add Nathan as a contributor?
>
>
>
> Thanks!
>
>
>
> Robert
>
>
>
>
>
> *From:* jenkinsci-dev@googlegroups.com  *On
> Behalf Of *Robert Reeves
> *Sent:* Thursday, April 23, 2020 1:50 PM
> *To:* Keith Collison 
> *Cc:* jenkinsci-dev@googlegroups.com; Daniel Beck ;
> Nathan Voxland 
> *Subject:* RE: Plugin: Liquibase Runner
>
>
>
> Of course, Keith. We love your work and are beyond appreciative. Thanks!
>
>
>
>
>
> Robert Reeves
>
> CTO | *Datical*
>
> 
>
> *Mobile:* 512 422 2443 <512-422-2443>
>
> *Email:* r...@datical.com
>
> *Website:* www.datical.com
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
>
>
>
> *From:* Keith Collison 
> *Sent:* Thursday, April 23, 2020 1:24 PM
> *To:* Robert Reeves 
> *Cc:* jenkinsci-dev@googlegroups.com; Daniel Beck ;
> Nathan Voxland 
> *Subject:* Re: Plugin: Liquibase Runner
>
>
>
> Sorry I've been out of pocket -- things have been a little crazy on my end
> lately.
>
>
>
> I'll provide feedback before the end of today.
>
>
>
> On Thu, Apr 23, 2020 at 10:40 AM Robert Reeves  wrote:
>
> I’ve emailed him a couple times and messaged him on GitHub. We emailed
> back and forth the first week of March but haven’t gotten a response since
> then. Right now the plugin is in security jail because of JEP-200 and we’re
> trying to bail it out with the PR we’ve submitted.
>
>
>
> We’re very appreciative of his work and a huge fan of his.
>
>
>
>
>
> Robert Reeves
>
> CTO | *Datical*
>
> 
>
> *Mobile:* 512 422 2443 <512-422-2443>
>
> *Email:* r...@datical.com
>
> *Website:* www.datical.com
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
>
>
>
> *From:* jenkinsci-dev@googlegroups.com  *On
> Behalf Of *Tim Jacomb
> *Sent:* Thursday, April 23, 2020 10:53 AM
> *To:* jenkinsci-dev@googlegroups.com
> *Cc:* Daniel Beck ; Keith Collison ;
> Nathan Voxland 
> *Subject:* Re: Plugin: Liquibase Runner
>
>
>
> Has Keith approved this somewhere? Here or in GitHub?
>
>
>
> On Thu, 23 Apr 2020 at 15:28, Robert Reeves  wrote:
>
> Just wanted to check on the adoption status. We have a PR submitted that
> resolves the security issue. We'd like to be able to push to master and do
> a release. 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/CY4PR06MB2949655B53B6CEDF5652411A83D30%40CY4PR06MB2949.namprd06.prod.outlook.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-3Bif-NFff6hBd%3DOgS33nrdWk%2BTLQ2CjyOyo6L6xssN%3DnEkg%40mail.gmail.com
> 

Re: Plugin Licenses

[Slide]

I generally check the license during hosting request review. I could add
something to the automated checker that I use to check the LICENSE and/or
the pom.xml

On Fri, Apr 24, 2020 at 6:26 AM Baptiste Mathus 
wrote:

> Agreed. It's never been clarified enough.
>
> And this is a problem, because contrary to what we can read sometimes, the
> default license is proprietary, not OSS.
>
> On Fri, Apr 24, 2020 at 12:54 PM Oleg Nenashev 
> wrote:
>
>> +1 for immediate depublishing. Usage of non-OSI licenses in plugins
>> potentially causes legal risks for Jenkins users.
>>
>> Maybe we should also start forcing an explicit license specification in
>> pom.xml and LICENSE for future plugin POM versions (5.0?). It has been
>> discussed a few times in the previous years, but IIRC we did not add
>> mandatory checks
>>
>> --
>> You received this message because you 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/f203c1b1-30a8-4cd4-ad90-8577b301e971%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/CAPyTVp0ow20VCaJ7PdAhfBQYMdj4%3DBKz%2Bk-9LN8JdMU1SQMWLw%40mail.gmail.com
> 
> .
>


-- 
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/CAPiUgVfC5OjaFLUL-DqJ6QAWu%3DWtmjfiX2KSS%3DPSNKj3BQqbxg%40mail.gmail.com.

Re: ANN: Agent Docker images renaming on April 12-13

[Slide]

Hi Jon,

I don't see such an image being already published by Jenkins. Can you
specify where you are getting it?

Regards,

Alex

On Wed, Apr 22, 2020, 03:13 Jon Brohauge  wrote:

> Hi Oleg et. al,
>
> Regarding the renaming to jnlp-slave -> inbound-agent, will there be a
> similar jnlp-slave-with-java-build-tools ->
> inbound-agent-with-java-build-tools?
>
> I know that it is possible to do the "with-java-build-tools" part oneself,
> it is IMHO easier to rely on an image that already works out of the box.
>
> Best regards,
>
> Jon Brohauge
>
> --
> You received this message because you 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/4f08e31a-b388-4b9c-83e5-31b94a79a012%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/CAPiUgVc43Pp09ttnVH53EA%2B%2BFmWO48mWhQv31%3Dg4kVcLakA%3Dug%40mail.gmail.com.

Re: Proposal: Windows support policy for Jenkins

[Slide]

>
>
> > does that mean we are testing Jenkins components (master and agent) on
> all of the supported platforms?
>
> I suppose at this point we only really test on 2019, right?
>
>
Yes, we currently only build and test on Windows Server 2019. To be fair
though, we only really test Linux stuff on Ubuntu 18.04 on ci.j.io, so
maybe that is ok.


> --
> You received this message because you 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/CANfRfr3SEsRa%3DOsrd-as%3D82BrS_kDkzbgLznewT%3D8Yw1zh2sBQ%40mail.gmail.com
> .
>


-- 
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/CAPiUgVfLqOnTVoZDX-S2ycRKV4XUCw%2B6s51YMwG9Bd6bQDF%2BKQ%40mail.gmail.com.

Re: plugin not appearing in pluginManager

[Slide]

Just to make sure, did you follow this documentation?

https://jenkins.io/doc/developer/publishing/releasing/

You did the mvn release:prepare release:perform?

If so, did you release a non-beta/alpha version (meaning the version you
selected did not include anything after the version).

For example, if you enter 1.0-anything I believe it will be published to
the experimental update center.

On Fri, Apr 10, 2020 at 8:54 AM Marina Goltseva 
wrote:

> Greetings,
>
>
> Recently, we have developed and published a plugin to the jenkinsci:
> https://github.com/jenkinsci/wallarm-fast-plugin , however we have
> encountered some publication problems and were hoping to get assistance
> with this issue.
>
>
> The wallarm-fast plugin is not appearing in the /pluginmanager area of a
> jenkins instance
>
> So far we've followed the publishing guide (
> https://github.com/jenkins-infra/update-center2#categorizing-plugins) as
> well as the infra guide (
> https://github.com/jenkins-infra/repository-permissions-updater/). Everything
> is seemingly fine, but we fail to reach the end result of seeing our plugin
> in the built-in jenkins search page.
>
> There may be issues due to our plugin being originally ruby and only
> recently being rewritten in java. We have not found any reason this may
> cause problems, but we cannot be sure.
>
> From the source code at (
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/Jenkinsfile#L18[
> )|
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/Jenkinsfile#L18]
>  we
> can see that there may be a period to building and publishing, but it's
> unclear how often this happens (should we just wait a few hours / days /
> months?).
>
> After which step should we expect the plugin to appear?
>
>
> Originally, we tried using the Jenkins Jira page:
> https://issues.jenkins-ci.org/browse/JENKINS-61365 .
>
> Any help in troubleshooting will be greatly appreciated!
>
> --
> You received this message because you 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/7973daa0-ccf9-4549-a2a9-b5b2ae3ed283%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVe-C-2gL5VUihTE88ypR5c5maxobm_EuamW%3DjmnyHKR%2BQ%40mail.gmail.com.

Re: How to perform a plugin release to Jenkins Artifact Repository through Continuous Integration?

[Slide]

Yes, all releases are done manually. There are some ideas floating around
to do the deployment in an automated way, but there are some things to
flush out that haven't been solved yet. It's not a hard process. You run
mvn release:prepare release:perform and follow the prompts.

On Fri, Apr 10, 2020 at 8:23 AM Shihaaz Buhary  wrote:

> Is that how all the plugins do the release to Jenkins Artifact Repo -
> *manually*?
>
> On Thursday, April 9, 2020 at 8:10:17 PM UTC+5:30, slide wrote:
>>
>> buildPlugin just wraps up a bunch of the common stuff for ci.jenkins.io
>> for building and testing plugins for master, PRs and branches. It does not
>> release anything to the update center. You need to do releases manually.
>>
>> On Thu, Apr 9, 2020 at 6:42 AM Shihaaz Buhary  wrote:
>>
>>> Hi All,
>>>
>>> I know how to do a plugin release manually by executing a few commands
>>> as mentioned in the Performing a Plugin Release
>>> <https://jenkins.io/doc/developer/publishing/releasing/> documentation.
>>> I can also see a page for Continuous Integration
>>> <https://jenkins.io/doc/developer/publishing/continuous-integration/> where
>>> it mentions about buildPlugin(configurations:
>>> buildPlugin.recommendedConfigurations()). What this method actually
>>> does? Does it release the plugin to repo through CI? If not, is there a way
>>> that we can achieve both (automate the release) together in the above
>>> pages? Because I can see almost all the plugins are using only the above
>>> buildPlugin(...) method in their Jenkinsfile. Or am I missing something
>>> here? I appreciate your help on this.
>>>
>>> Thanks,
>>> Shihaaz
>>>
>>> --
>>> You received this message because you 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/53933abf-1a36-440a-838b-6defbb733cf2%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/53933abf-1a36-440a-838b-6defbb733cf2%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> 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/8015df3b-5a54-4796-9831-d142a892bff6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/8015df3b-5a54-4796-9831-d142a892bff6%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAPiUgVcS4VLhzE4Q95MzBDwapKqSNLivk4Y-KyCWdzK9Jwks%2Bg%40mail.gmail.com.

Re: Proposal: Windows support policy for Jenkins

[slide]

Hi Oleg,

I think this sounds completely reasonable. If we are supporting these 
versions, does that mean we are testing Jenkins components (master and 
agent) on all of the supported platforms? How do we determine that we are 
maintaining compatibility with those platforms? I assume these types of 
things will be in a support policy document of some sort?

Regards,

Alex

On Friday, April 10, 2020 at 5:26:51 AM UTC-7, Oleg Nenashev wrote:
>
> Dear all,
>
> As you probably know, Jenkins core and some plugins contain native code, 
> and hence they rely on operating systems and platforms. In principle 
> Jenkins can run everywhere where you can run Java 8 or Java 11, but in 
> practice there are some limitations. Notably we use Java Native Access  and 
> Java Native Runtime libraries which provide wide support for platforms, but 
> there are other components. In the case of Windows platforms we use Windows 
> Service Wrapper (WinSW)  and Windows 
> Process Management Library (WinP) , 
> which depend on Windows versions and, in the case of windows services, on 
> .NET Framework.
>
> In the Jenkins Platform SIG  we have 
> an open topic about Windows support policy in Jenkins. Currently we have no 
> documented support policy for Windows, and it becomes an obstacle for 
> maintainers of Windows-focused components and plugins in the 
> Jenkins project. As a maintainer of WinSW and WinP, I have to be very 
> conservative about Windows support. But it comes at a cost to users, not 
> just maintenance overhead. At the end of the day it also blocks us from 
> adopting new Windows features and making Jenkins more stable/maintenable on 
> modern Windows platforms.
>
> I know for sure that there are Jenkins users running on Windows XP, but 
> IMHO it becomes more and more legacy use-case. Last popular industry 
> version had EoL in 2019 (WinXP Exmbedded POSReady 
> ),
>  
> and IMO it is time to drop WinXP support in new Jenkins releases. Same goes 
> to 32bit systems and non-mainstream architectures like Itanium, we could 
> at least reduce the support level there.
>
> I suggest the following policy:
>
>- All installers and service wrappers require Windows 7 / Windows 
>Server 2012 or above (and .NET framework 4.0+). They support 64bit 
>platforms only. Support for other platforms are provided via manual 
>jenkins.war deployment
>- Jenkins master runtime requires Windows 7 / Windows Server 2012 or 
>above. It may work on older versions, but we do not guarantee compatibility
>- Jenkins agent runtime requires Windows 7 / Windows Server 2012 or 
>above. It may work on older versions, but we do not guarantee compatibility
>- For all Windows service installations .NET Framework 4.0 or above is 
>required. It is a default version in Windows versions specified above
>- Jenkins master and agent Docker images are not required to provide 
>images for the supported platforms. They can move ahead as maintainers 
>prefer
>- Plugins can define their own support policy, but they are strongly 
>advised to align their Windows support policy with the Jenkins Core 
>versions.
>   - We have no way to communicate potential Windows support issues 
>   via update center at the moment, so following the Jenkins core 
> requirements 
>   is what we can recommend as the best option
>- Custom Jenkins packaging may have different requirements 
>(Jenkinsfile Runner, WARs built by Custom WAR Packager)
>
> Would appreciate feedback from maintainers and Windows users! Any comments 
> and change suggestions are welcome.
>
> If other Plaftorm SIG folks agree with me, I would suggest to add this 
> area to the Jenkins Roadmap . I also 
> created a JENKINS-61865 
>  EPIC to track 
> changes there. I will create tasks in the EPIC once there is a consensus in 
> this thread.
>
> Best regards,
> Oleg Nenashev
> Platform SIG
>
>
>
>
>
>  
>
>
>
>

-- 
You received this message because you 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/5f5b8d5e-f6c7-4d4b-99d4-fc5c66ec7bb0%40googlegroups.com.

Re: How to perform a plugin release to Jenkins Artifact Repository through Continuous Integration?

[Slide]

buildPlugin just wraps up a bunch of the common stuff for ci.jenkins.io for
building and testing plugins for master, PRs and branches. It does not
release anything to the update center. You need to do releases manually.

On Thu, Apr 9, 2020 at 6:42 AM Shihaaz Buhary  wrote:

> Hi All,
>
> I know how to do a plugin release manually by executing a few commands as
> mentioned in the Performing a Plugin Release
>  documentation. I
> can also see a page for Continuous Integration
>  where
> it mentions about buildPlugin(configurations:
> buildPlugin.recommendedConfigurations()). What this method actually does?
> Does it release the plugin to repo through CI? If not, is there a way that
> we can achieve both (automate the release) together in the above pages?
> Because I can see almost all the plugins are using only the above
> buildPlugin(...) method in their Jenkinsfile. Or am I missing something
> here? I appreciate your help on this.
>
> Thanks,
> Shihaaz
>
> --
> You received this message because you 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/53933abf-1a36-440a-838b-6defbb733cf2%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVeCtR6qPMttogZsBepD5Ga%2Ba7Pd4SQ9kY05%2BRiSYO_rgQ%40mail.gmail.com.

Re: Jenkins Plugin Wiki

[Slide]

When you say updated a build,do you mean you create a new release of the
plugin? Can you point to your pom.xml?

On Mon, Apr 6, 2020 at 8:34 PM selva vignesh 
wrote:

> Hi,
> After adding  value to GitHub repo nothing changed. I have updated a
> build yesterday but still in plugin page showing that Last release was 11
> days ago. can anyone please assist
>
> On Thu, Apr 2, 2020 at 3:23 PM Richard Bywater  wrote:
>
>> Hi
>>
>> The  value in your pom.xml needs to point at your Github
>> repository (i.e. https://github.com/jenkinsci/zohosprints-plugin) for
>> the plugin site to use the README from your Github repo.
>>
>> Richard.
>>
>> On Thu, 2 Apr 2020 at 21:33, selva vignesh 
>> wrote:
>>
>>> Hi,
>>> I have published my plugin and added Wiki in Readme.md in github.
>>> But still i am unable to find wiki in
>>> https://plugins.jenkins.io/zohosprints/
>>> can anyone please assist.
>>>
>>> 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/5537c488-1660-4cff-a496-a3dcaa7949a7%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/CAAy0hwcBGmxXpqxwviNpcZLaTq%3D30A5_NjTRtHrqj5rUmi6Ftg%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/CAOVVkpnFq3_QOCy47UsvJ4dC9FHBtGcqNLi1nPxCDV45am7smA%40mail.gmail.com
> 
> .
>


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

Re: How to Change Plugin Name - Remote File Plugin

[Slide]

Are you only interested in the name that shows up in the Plugin Manager
changing? If so, you should just be able to change the  tag in
your pom.xml to the new name and do a new release. The name would be
updated in the update center from the next release.

On Sat, Mar 28, 2020 at 6:28 AM Aytunc Beken 
wrote:

> Hi,
>
> I would like to change "Remote File Plugin"  to more understandable name
> like "Multibranch Remote Jenkinsfile Plugin".
>
> - It this name okay to use ?
> - How can I do that ?
>
> Thanks.
>
>
> https://issues.jenkins-ci.org/browse/JENKINS-45273?focusedCommentId=387340=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-387340
>
> --
> You received this message because you 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/f83ac688-1328-4345-93ba-98e06695a389%40googlegroups.com
> 
> .
>


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

Re: Automating plugin release process via GitHub Actions

[Slide]

There has been some discussion about automating plugin releases in the
past. I think it would make more sense to do something on ci.jenkins.io,
but you'd run into similar issues with user creds for upload.

On Fri, Mar 27, 2020, 12:16 Radek Antoniuk  wrote:

> I'm thinking about automating the plugin release process using GH Actions:
>
>-
>
> https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets
>- https://github.com/marketplace/actions/maven-release
>-
>https://help.github.com/en/actions/reference/events-that-trigger-workflows
>- https://www.asyncapi.com/blog/automated-releases/
>
> It seems that the process for setting this up for releasing on GH is quite
> straightforward.
> The issue is uploading the new artifact to the Artifactory, for what we
> need the credentials that are managed through:
>
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/
>
> There are two problems here:
> - what user should be used in GH action to push to Artifactory
> - the GH secrets can be only created by GH org owners
>
> Do you think it's a good idea to try this out?
> For me the benefits are:
> - the release process will be done in a standard environment defined by
> the used docker image (obviously could be done locally but that's the point
> not to do have the need to do it in docker locally)
> - the process can be automated, e.g. "do a release at the last day of
> month if there were any new PRs merged" - that would increase transparency
> and predictability on the releases
>
> Cheers,
> Radek
>
> --
> You received this message because you 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/a799d799-6015-4252-8eb6-8d7f06a76609%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/CAPiUgVfRt8oCtOGQCgu8Hp%3Dv8WcdPEECcdyxYCqb_gsz4JL0BQ%40mail.gmail.com.

Re: windows builds of core

[Slide]

Jesse was looking into this recently I believe, but I am not sure where
that ended up. It was to get core building on the ACI agents I believe. If
there is something that needs to be fixed up on the ACI agents, I would be
happy to help get that done.

On Thu, Mar 26, 2020 at 10:19 AM James Nord  wrote:

> I'm trying to test a patch locally and well lets just say it does not look
> like Jenkins is healthy - even on master...
>
> Can we please add a windows stage back into the core CI build?
>
> If you need help with this I am happy to help out.
>
> /James
>
> --
> You received this message because you 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/0e46ecbf-d3ab-428b-8c34-1cab3925512a%40googlegroups.com
> 
> .
>


-- 
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/CAPiUgVfjfPU4EbY5Yp_dtV2%2BZ9ihwj6SP%2BxwKigH40yyerwgdw%40mail.gmail.com.