Re: [Build failure analyzer] Request commit access

[Tim Jacomb]

Would you like help on it?

Thanks
Tim

On Fri, 16 Nov 2018 at 10:48, Robert Sandell  wrote:

> I've been very busy with other things the last few months so I've been
> neglecting my maintainer duties, but I'm slowly coming back and working off
> my code review backlog.
>
> /B
>
> Den tis 13 nov. 2018 kl 21:36 skrev Tim Jacomb :
>
>> CC maintainers
>>
>> On Tue, 13 Nov 2018 at 20:31, Tim Jacomb  wrote:
>>
>>> Hi
>>>
>>> I would like to request commit access for the build failure analyzer
>>> plugin
>>>
>>> I would like to clean it up and do some more development on it
>>>
>>> Github: timja
>>> Jenkins infra: timja
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/9b7b01f8-5252-4af7-ba9f-c303c130209c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/9b7b01f8-5252-4af7-ba9f-c303c130209c%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>
> --
> *Robert Sandell*
> Software Engineer
> CloudBees, Inc.
> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
> E: rsand...@cloudbees.com
> Twitter: robert_sandell
>

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

[Slack plugin] Request commit access

[Tim Jacomb]

Hi

I would like to request commit access for the slack plugin
It has been discussed briefly here:
https://github.com/jenkinsci/slack-plugin/issues/402

Github: timja
Jenkins infra: timja

Thanks
Tim

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

Re: [Slack plugin] Request commit access

[Tim Jacomb]

CC maintainers

On Wed, 14 Nov 2018 at 20:25, Tim Jacomb  wrote:

> Hi
>
> I would like to request commit access for the slack plugin
> It has been discussed briefly here:
> https://github.com/jenkinsci/slack-plugin/issues/402
>
> Github: timja
> Jenkins infra: timja
>
> Thanks
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Slack plugin] Request commit access

[Tim Jacomb]

Hi

I would like to request commit access for the slack plugin
It has been discussed briefly here:
https://github.com/jenkinsci/slack-plugin/issues/402

Github: timja
Jenkins infra: timja

Thanks
Tim

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

Re: [Build failure analyzer] Request commit access

[Tim Jacomb]

CC maintainers

On Tue, 13 Nov 2018 at 20:31, Tim Jacomb  wrote:

> Hi
>
> I would like to request commit access for the build failure analyzer plugin
>
> I would like to clean it up and do some more development on it
>
> Github: timja
> Jenkins infra: timja
>
> Thanks
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/9b7b01f8-5252-4af7-ba9f-c303c130209c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/9b7b01f8-5252-4af7-ba9f-c303c130209c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Build failure analyzer] Request commit access

[Tim Jacomb]

Hi

I would like to request commit access for the build failure analyzer plugin

I would like to clean it up and do some more development on it

Github: timja
Jenkins infra: timja

Thanks
Tim

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

Re: [Slack plugin] Request commit access

[Tim Jacomb]

Thanks Michael

@Kurt Madel  could you please approve the permissions
PR for releasing:
https://github.com/jenkins-infra/repository-permissions-updater/pull/942#issuecomment-442371820



On Wed, 28 Nov 2018 at 07:15, Michael Neale  wrote:

> Hi Tim (missed you on irc, but saw the request).
>
> You should be a committer to it now on github.
>
> If you want to do a release - open a pull request with your jenkins.io
> user info here:
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-slack.yml
> (otherwise it won't let the plugin binary upload).
>
>
> On Wednesday, November 28, 2018 at 9:31:01 AM UTC+11, Tim Jacomb wrote:
>>
>> Hi
>>
>> Its been about two weeks now
>> As detailed here:
>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>
>> May I please take over this plugin?
>>
>> I've tagged on github:
>>
>> On Wed, 14 Nov 2018 at 20:27, Tim Jacomb  wrote:
>>
>>> CC maintainers
>>>
>>> On Wed, 14 Nov 2018 at 20:25, Tim Jacomb  wrote:
>>>
>>>> Hi
>>>>
>>>> I would like to request commit access for the slack plugin
>>>> It has been discussed briefly here:
>>>> https://github.com/jenkinsci/slack-plugin/issues/402
>>>>
>>>> Github: timja
>>>> Jenkins infra: timja
>>>>
>>>> Thanks
>>>> Tim
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkinsci-de...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/0d0a3a28-d000-40b7-a60b-f7eedb73b14f%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/0d0a3a28-d000-40b7-a60b-f7eedb73b14f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [Slack plugin] Request commit access

[Tim Jacomb]

Hi

Its been about two weeks now
As detailed here:
https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin

May I please take over this plugin?

I've tagged on github:

On Wed, 14 Nov 2018 at 20:27, Tim Jacomb  wrote:

> CC maintainers
>
> On Wed, 14 Nov 2018 at 20:25, Tim Jacomb  wrote:
>
>> Hi
>>
>> I would like to request commit access for the slack plugin
>> It has been discussed briefly here:
>> https://github.com/jenkinsci/slack-plugin/issues/402
>>
>> Github: timja
>> Jenkins infra: timja
>>
>> Thanks
>> Tim
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/cf050ffc-34bf-4502-b9c1-681018806fb8%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: Calling a Jenkins plugin from pipeline

[Tim Jacomb]

You need to be in a node block for that to work

node {
  Your step
}

On Fri, 8 Feb 2019 at 07:35, prasad.pofali via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hi,
>
> I have created a simple Jenkins plugin which prints a Hello world on
> Jenkins console. This plugin is working fine when configured through
> traditional approach of enabling it through Post Build jobs. Now I am
> trying to call that plugin through a pipeline code. Below is the code to
> call the plugin:
>
> *step([$class : '* *TestExamplePublisher**', applications:[name:
>> 'Prasad', lastName: 'P']])*
>
>
> But when I build the job, using build now option. It gives an exception :
>
> org.jenkinsci.plugins.workflow.steps.MissingContextVariableException:
>> Required context class hudson.FilePath is missing
>>
>> at
>> org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:260)
>> at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:262)
>> at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178)
>> at
>> org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
>> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
>> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
>> at
>> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
>> at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
>> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
>> at
>> org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
>> at
>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155)
>> at
>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:142)
>> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
>> at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
>> at
>> com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
>> at WorkflowScript.run(WorkflowScript:2)
>> at ___cps.transform___(Native Method)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>> at
>> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
>> at
>> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>> at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
>> at com.cloudbees.groovy.cps.Next.step(Next.java:83)
>> at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
>> at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
>> at
>> 

Appending to build log after complete

[Tim Jacomb]

Hi

I'm looking at fixing JENKINS-54840
 in the
build-failure-analyzer plugin

It has functionality where a user can force another analysis to be run on a
build
This gets the log file on disk, opens a PrintStream to it and appends log
information to it about the scan result
Code:
https://github.com/jenkinsci/build-failure-analyzer-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/bfa/sod/ScanOnDemandTask.java#L110

On recent pipeline versions this is logging exceptions on every call
"WARNING org.jenkinsci.plugins.workflow.job.WorkflowRun getLogFileAvoid
calling getLogFile on TestWorkflow/TestWorkflow #362
java.lang.UnsupportedOperationException"

Is there a supported way to append to a log file after the build is
completed? I see ways to get an InputStream, the log text and writeLogTo
(seems to be for writing a whole log though)

Or should this functionality be re-written?
My guess is that build-failure-analyzer should probably have it's own log
file, which can just be overwritten on every scan.
If this is the approach is there any good example out there that you would
recommend?

Thanks
Tim

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

Re: Proposal - Introducing Global Probot configuration for Release Drafter and other tools

[Tim Jacomb]

Afaik admin role is granted in general now, since the introduction of
danger zone permission protection.

I’m admin on a plugin that was hosted a couple of months ago, without me
asking for it at all...

Thanks
Tim


On Tue, 28 May 2019 at 18:58, Oleg Nenashev  wrote:

> We usually do not grant ADMIN role permissions to maintainers, but some
> plugins indeed use admin. I prefer to focus on a more common case in the
> guidelines
>
> BR, Oleg
>
> On Tue, May 28, 2019, 18:40 Tim Jacomb  wrote:
>
>> I’m pretty sure maintainers can just add the app themselves as it’s
>> approved for the org, assuming they have admin permission on the repo
>>
>> I didn’t need an infra ticket when I set it up on the slack plugin...
>>
>> Thanks
>> Tim
>>
>> On Tue, 28 May 2019 at 15:02, Oleg Nenashev 
>> wrote:
>>
>>> I agree it makes sense to document the steps.
>>>
>>> Basically it is...
>>>
>>>1. Create ./github/release-drafter.yml file
>>>   - Extend the global config there
>>>   - Define your labeling and versioning scheme by overriding fields
>>>   - Examples:
>>>  - Role Strategy plugin:
>>>  
>>> https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
>>>  - ci.jenkins.io-runner:
>>>  https://github.com/jenkinsci/ci.jenkins.io-runner
>>>   2. Create an INFRA ticket with component=github for enabling
>>>Release Drafter in the repo. Assign to Oleg to improve the response time
>>>
>>> Order of steps does not really matter. I enabled Release drafter for
>>> Platform Labeler and Plugin POM
>>>
>>> BR, Oleg
>>>
>>>
>>>
>>> On Tue, May 28, 2019 at 3:37 PM Mark Waite 
>>> wrote:
>>>
>>>> I'd like to try it on the platformlabeler-plugin.
>>>>
>>>> On Sat, May 25, 2019 at 5:29 AM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Since there is a consensus in this thread, I went ahead and
>>>>> implemented this story:
>>>>>
>>>>>- Default configuration:
>>>>>
>>>>> https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml
>>>>>- Pull request which merges the configuration for BlueOcean and
>>>>>Configuration-as-Code plugins:
>>>>>https://github.com/jenkinsci/.github/pull/1
>>>>>- Usage examples:
>>>>>   - Role Strategy plugin:
>>>>>   
>>>>> https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
>>>>>   - ci.jenkins.io-runner:
>>>>>   https://github.com/jenkinsci/ci.jenkins.io-runner
>>>>>
>>>>> Some notes about the current default config:
>>>>>
>>>>>- Default tag template (tag-template)  does not make much sense,
>>>>>because Maven Release plugin in Plugin POM uses the
>>>>>${artifactId}-${version} tag format by default. It needs to be 
>>>>> overridden
>>>>>in repos (see the linked examples)
>>>>>- Jenkins plugins use different versioning format. Release Drafter
>>>>>defaults to semver <https://semver.org/>, but the majority of
>>>>>Jenkins plugins uses the two-digit version number. That;s why I used 
>>>>> it as
>>>>>a default in the global config
>>>>>   - it can be also overridden in repos, see ci.jenkins.io-runner
>>>>>   config
>>>>>   
>>>>> <https://github.com/jenkinsci/ci.jenkins.io-runner/blob/master/.github/release-drafter.yml>
>>>>>- Current replacer regexps target the common "[JENKINS-1234] -
>>>>>Change description" templates only, but we can extend the,
>>>>>
>>>>> Obviously, contributions to the default template (and to other GitHub
>>>>> app templates) are more than welcome. If you want to try out Release
>>>>> Drafter in your repos, let me know. Disclaimer: see the permissions
>>>>> concerns above.
>>>>>
>>>>> Best regards,
>>>>> Oleg
>>>>>
>>>>> On Saturday, May 25, 2019 at 1:26:38 PM UTC+2, Daniel Beck wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> > On 24. May 2019, at 19:23, James N

Re: Proposal - Introducing Global Probot configuration for Release Drafter and other tools

[Tim Jacomb]

I’m pretty sure maintainers can just add the app themselves as it’s
approved for the org, assuming they have admin permission on the repo

I didn’t need an infra ticket when I set it up on the slack plugin...

Thanks
Tim

On Tue, 28 May 2019 at 15:02, Oleg Nenashev  wrote:

> I agree it makes sense to document the steps.
>
> Basically it is...
>
>1. Create ./github/release-drafter.yml file
>   - Extend the global config there
>   - Define your labeling and versioning scheme by overriding fields
>   - Examples:
>  - Role Strategy plugin:
>  
> https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
>  - ci.jenkins.io-runner:
>  https://github.com/jenkinsci/ci.jenkins.io-runner
>   2. Create an INFRA ticket with component=github for enabling
>Release Drafter in the repo. Assign to Oleg to improve the response time
>
> Order of steps does not really matter. I enabled Release drafter for
> Platform Labeler and Plugin POM
>
> BR, Oleg
>
>
>
> On Tue, May 28, 2019 at 3:37 PM Mark Waite 
> wrote:
>
>> I'd like to try it on the platformlabeler-plugin.
>>
>> On Sat, May 25, 2019 at 5:29 AM Oleg Nenashev 
>> wrote:
>>
>>> Since there is a consensus in this thread, I went ahead and implemented
>>> this story:
>>>
>>>- Default configuration:
>>>
>>> https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml
>>>- Pull request which merges the configuration for BlueOcean and
>>>Configuration-as-Code plugins:
>>>https://github.com/jenkinsci/.github/pull/1
>>>- Usage examples:
>>>   - Role Strategy plugin:
>>>   
>>> https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
>>>   - ci.jenkins.io-runner:
>>>   https://github.com/jenkinsci/ci.jenkins.io-runner
>>>
>>> Some notes about the current default config:
>>>
>>>- Default tag template (tag-template)  does not make much sense,
>>>because Maven Release plugin in Plugin POM uses the
>>>${artifactId}-${version} tag format by default. It needs to be overridden
>>>in repos (see the linked examples)
>>>- Jenkins plugins use different versioning format. Release Drafter
>>>defaults to semver , but the majority of
>>>Jenkins plugins uses the two-digit version number. That;s why I used it 
>>> as
>>>a default in the global config
>>>   - it can be also overridden in repos, see ci.jenkins.io-runner
>>>   config
>>>   
>>> 
>>>- Current replacer regexps target the common "[JENKINS-1234] -
>>>Change description" templates only, but we can extend the,
>>>
>>> Obviously, contributions to the default template (and to other GitHub
>>> app templates) are more than welcome. If you want to try out Release
>>> Drafter in your repos, let me know. Disclaimer: see the permissions
>>> concerns above.
>>>
>>> Best regards,
>>> Oleg
>>>
>>> On Saturday, May 25, 2019 at 1:26:38 PM UTC+2, Daniel Beck wrote:



 > On 24. May 2019, at 19:23, James Nord  wrote:
 >
 > If there was a way to release community plugins from our infra then
 you could do this with a simple command without the need to grant any
 permissions to apps.

 I know of a proposal supposed to be landing soon related to that :)

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/6bab3eaa-e979-480e-b8c3-4b5425d600de%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
>> --
>>
> 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/dOs8YRQwQiI/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/CAO49JtFQdkjd972M%3D8Zj3%3Ddf-upAXLV41vM_nGu7Dk1zjNHW6A%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from 

Re: Appending to build log after complete

[Tim Jacomb]

Thanks Jesse
I've created an Action.

https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/106

Any feedback welcomed

Thanks
Tim

On Mon, 3 Jun 2019 at 13:03, Jesse Glick  wrote:

> On Mon, Jun 3, 2019 at 3:51 AM Tim Jacomb  wrote:
> > It has functionality where a user can force another analysis to be run
> on a build
> > This gets the log file on disk, opens a PrintStream to it and appends
> log information to it about the scan result
>
> Should be rewritten to do something else, like attach an `Action` that
> somehow displays an analysis, for example in a box on the build’s
> index page.
>
> > Is there a supported way to append to a log file after the build is
> completed?
>
> No.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3a3pF7prC6Q7Xf0WSQ16fSDf1MsUhgkSqcGgQN8FoOkQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Creating an env variable via API

[Tim Jacomb]

What I do for this is set the SECRETS environment variably and point it to
a directory on the file system which had the secrets in it.
Basically pretending I’m using docker secrets

Thanks
Tim

On Tue, 11 Jun 2019 at 10:27, Parichay Barpanda 
wrote:

> Thanks Gaven. Groovy is cool but we are using JCasC yaml to create
> credentials. I want to populate an environment variable and use it in my
> config.yaml. I want to know if there is a way to do it without using docker
> secrets. For example, when running Jenkins instance inside a VM or using
> jenkins.war file on local machine. Is there a way to do it in these cases
> (without going through UI)?
>
> The config file looks like this:
>
>> credentials:
>>   system:
>> domainCredentials:
>>   - credentials:
>>   - gitlabPersonalAccessToken:
>>   scope: SYSTEM
>>   id: "i<3GitLab"
>>   token: ${GITLAB_PERSONAL_ACCESS_TOKEN}
>>
>>
>
> On Tue, Jun 11, 2019 at 10:04 AM Gavin Mogan  wrote:
>
>> You can unsafely access the script console -
>> https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console
>>
>> then you can create credentials using groovy, example -
>> https://github.com/halkeye-docker/docker-jenkins/blob/22ba8c4408b3a16188dc9fe967293849e8f12468/groovy/0012-add-tokens.groovy#L50-L57
>>
>> On Mon, Jun 10, 2019 at 8:12 PM Parichay Barpanda <
>> parichay.barpa...@gmail.com> wrote:
>>
>>> For example,
>>>
>>> To delete a job, you can make a POST request to Jenkins server as:
>>>
>>> curl -X POST http://localhost:8080/job/my-job-name/doDelete --user
>>> jenkins:f1499cc9852c899d327a1f644e61a64d
>>>
>>> where,
>>> *username*: jenkins
>>> *api token*: f1499cc9852c899d327a1f644e61a64d
>>>
>>> On Tuesday, June 11, 2019 at 8:24:32 AM UTC+5:30, Parichay Barpanda
>>> wrote:

 Hi all,

 I am trying to figure out a way to add an environment variable to
 Jenkins without using the UI. Is there a way to do it via API? The
 intention is to let user add credentials to Jenkins without using UI.
 Please let me know if you have a solution to this.

 Thanks.

 Regards,
 Parichay (baymac)


 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/abc16929-b9e6-4e38-86c9-af7233f2451e%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAAgr96%2B2deU7v64sgJruQ02X0S34D31FYtEFN9ak57zN4Uo2PA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAD0DWANNZbsP%3D-jJ58Va-4t3a%3Dko5A2nWseXA46SXk23WT9%2BHQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

JEP-200? azure-vm-agents PR issue

[Tim Jacomb]

Hi

I'm having an issue adding configuration-as-code support to the 
azure-vm-agents plugin
(On Mac, linux all tests pass, and on windows when run through intellij 
they also pass)
On windows when run on the command line a couple of unit tests fail with:

"Refusing to marshal com.microsoft.azure.vmagent.AzureVMCloud for security 
reasons; see https://jenkins.io/redirect/class-filter/;

Gist with stacktrace:
https://gist.github.com/timja/1bb1976ae2637088ee2f0ed13ef078a7

stack:
Caused by: java.io.IOException: java.lang.RuntimeException: Failed to 
serialize jenkins.model.Jenkins#clouds for class hudson.model.Hudson
at hudson.XmlFile.write(XmlFile.java:200)
at jenkins.model.Jenkins.save(Jenkins.java:3221)
at hudson.BulkChange.commit(BulkChange.java:98)
at 
io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:266)
... 11 more
Caused by: java.lang.RuntimeException: Failed to serialize 
jenkins.model.Jenkins#clouds for class hudson.model.Hudson
at 
hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:256)
at 
hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:224)
at 
com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
at 
hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:209)
at 
hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:150)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at 
com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
at 
com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
at hudson.XmlFile.write(XmlFile.java:193)
... 14 more
Caused by: java.lang.UnsupportedOperationException: Refusing to marshal 
com.microsoft.azure.vmagent.AzureVMCloud for security reasons; see 
https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:546)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at 
com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at 
hudson.util.DescribableList$ConverterImpl.marshal(DescribableList.java:269)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at 
hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at 
hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
... 27 more

Full test output:
https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fazure-vm-agents-plugin/detail/PR-144/13/tests

The PR:
https://github.com/jenkinsci/azure-vm-agents-plugin/pull/144

Anyone got any idea or tips?
I've read through  https://jenkins.io/redirect/class-filter/ but can't see 
what's wrong

The core version and parent pom weren't changed in this PR, some data model 
changes though.

Any help much appreciated
Thanks
Tim

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

Re: JEP-200? azure-vm-agents PR issue

[Tim Jacomb]

Sorted

Jessie pointed me in the right direction (Thanks!)

WARNING o.jvnet.hudson.test.JenkinsRule#before: Jenkins.theInstance
was not cleared by a previous test, doing that now


This commit fixed it:
https://github.com/jenkinsci/azure-vm-agents-plugin/pull/144/commits/9c94fb0dafee9e60a7424345810295a9ad4142c6


Tim

On Mon, 29 Apr 2019 at 16:57, Tim Jacomb  wrote:

> Hi
>
> I'm having an issue adding configuration-as-code support to the
> azure-vm-agents plugin
> (On Mac, linux all tests pass, and on windows when run through intellij
> they also pass)
> On windows when run on the command line a couple of unit tests fail with:
>
> "Refusing to marshal com.microsoft.azure.vmagent.AzureVMCloud for security
> reasons; see https://jenkins.io/redirect/class-filter/;
>
> Gist with stacktrace:
> https://gist.github.com/timja/1bb1976ae2637088ee2f0ed13ef078a7
>
> stack:
> Caused by: java.io.IOException: java.lang.RuntimeException: Failed to
> serialize jenkins.model.Jenkins#clouds for class hudson.model.Hudson
> at hudson.XmlFile.write(XmlFile.java:200)
> at jenkins.model.Jenkins.save(Jenkins.java:3221)
> at hudson.BulkChange.commit(BulkChange.java:98)
> at
> io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:266)
> ... 11 more
> Caused by: java.lang.RuntimeException: Failed to serialize
> jenkins.model.Jenkins#clouds for class hudson.model.Hudson
> at
> hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:256)
> at
> hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:224)
> at
> com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
> at
> hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:209)
> at
> hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:150)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
> at
> com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
> at com.thoughtworks.xstream.XStream.marshal(XStream.java:1026)
> at com.thoughtworks.xstream.XStream.marshal(XStream.java:1015)
> at com.thoughtworks.xstream.XStream.toXML(XStream.java:988)
> at hudson.XmlFile.write(XmlFile.java:193)
> ... 14 more
> Caused by: java.lang.UnsupportedOperationException: Refusing to marshal
> com.microsoft.azure.vmagent.AzureVMCloud for security reasons; see
> https://jenkins.io/redirect/class-filter/
> at
> hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:546)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
> at
> com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
> at
> hudson.util.DescribableList$ConverterImpl.marshal(DescribableList.java:269)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
> at
> hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
> at
> hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
> ... 27 more
>
> Full test output:
>
> https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fazure-vm-agents-plugin/detail/PR-144/13/tests
>
> The PR:
> https://github.com/jenkinsci/azure-vm-agents-plugin/pull/144
>
> Anyone got any idea or tips?
> I've read through  https://jenkins.io/redirect/class-filter/ but can't
> see what's wrong
>
> The core version and parent pom weren't changed in this PR, some data
> model changes though.
>
> Any help much appreciated
> Thanks
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and

Re: Budget request: Community Bridge trial run for a JCasC project

[Tim Jacomb]

+1

It's a great initiative, thanks Oleg for your work in getting this setup.

Cheers
Tim

On Monday, 29 July 2019 10:42:38 UTC+1, Oleg Nenashev wrote:
>
> Dear all,
>
> I would like to request a budget for a new Outreach program we were 
> discussing few times before in Platform, Docs and Advocacy and Outreach 
> SIGs. This program is powered by Community Bridge 
> <https://communitybridge.org/> project. This is a new Outreach service 
> created by Linux Foundation, and we would be interested to use it to 
> accommodate projects which we were unable to run in GSoC/GSoD this year. We 
> had an overview of this program at the Advocacy and Outreach SIG meeting on 
> June 6th (video <https://youtu.be/Zi_IxFySFBg?t=641>, meeting notes 
> <https://docs.google.com/document/d/1K5dTSqe56chFhDSGNfg_MCy-LmseUs_S3ys_tg60sTs/edit#heading=h.vvw54obc99zh>
> ).
>
> We have a student (Sladyn Nunes <https://github.com/Sladyn98>) who is 
> pretty active in the community now. He has already applied to the community 
> bridge project, and he is interested in the Configuration-as-Code project 
> (compatibility, development tools). You can find his proposal 
> <https://docs.google.com/document/d/1aPfkmyMQRCcipVa0htFt-i7X_pkQHSVKfR5qT60HQZ8/edit?usp=sharing>
>  here. 
> he has already done some contributions, and JCasC plugin team is ready to 
> mentor the student (Joseph Petersen and Tim Jacomb would be lead 
> mentors). Focus of the project: JCasC schema validation fixes and IDE 
> integrations.
>
> The plan is to have the student working on the project for few months with 
> 20+ hours per week time dedication.
>
> What I ask for?
>
>- Student grant/stipend - 1500 USD
>- If the project is successful, travel grant to Jenkins World 2019 in 
>Lisbon or a similar event
>   - Our default travel grant policy is 500 USD, but the trip is going 
>   to be more expensive. I would like to request a bigger grant if possible
>
> Please let me know if any additional information is needed.
>
> 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/fdfc414d-2b34-4f44-b2a6-edaa4179ad1c%40googlegroups.com.

Re: Library(JollyDay)'s properties file cannot be found by WebAppClassLoader in Jenkins runtime.

[Tim Jacomb]

This should hopefully explain it for you:
https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/

Thanks
Tim

On Wed, 17 Jul 2019 at 15:32, Jack Shen  wrote:

> Link to the issue in Jira:
> https://issues.jenkins-ci.org/browse/JENKINS-58530
>
>
> I'm trying to use [*JollyDay* |https://github.com/svendiedrichsen/jollyday]to
> provide ability to get holidays, but its day-calculate algorithm is based
> on some .porperties file(typically Jollyday.properties). These files can be
> found in running unit test, but when running it in jenkins, they're missed.
>
> When looking at the stack trace, this lib is using *current thread's
> context classloader* ( WebappClassLoader)  to get resource, but the
> loader returned null.
>
> However, using HolidayCalendar(one class of
> JollyDay).class.getClassLoader().getResource() works fine.( But the
> returned URL is from my system maven repo)
>
> Are there anything I missed to do, like mvn install? I tryed that, but
> it's not the cause.
>
> PS, are all the temp file in the "target" dir? I guess it's because there
> is no jollyday.properties in the dir.
>
> Should I add some more config to include it? But I'm not quite clear about
> how to handle this.
>
>
>
> *Stack Trace*:
>
> Caused by: java.lang.NullPointerExceptionCaused by:
> java.lang.NullPointerException
>
> at
> de.jollyday.configuration.impl.DefaultConfigurationProvider.getProperties(DefaultConfigurationProvider.java:59)
> at
> de.jollyday.configuration.ConfigurationProviderManager.addInternalConfigurationProviderProperies(ConfigurationProviderManager.java:63)
> at
> de.jollyday.configuration.ConfigurationProviderManager.mergeConfigurationProperties(ConfigurationProviderManager.java:57)
> at de.jollyday.HolidayManager.createManager(HolidayManager.java:163) at
> de.jollyday.HolidayManager.getInstance(HolidayManager.java:148) at
> de.jollyday.HolidayManager.getInstance(HolidayManager.java:124) at
> org.jenkinsci.plugins.workinghours.WorkingHoursUI.getRegionHolidays(WorkingHoursUI.java:84)
> at
> org.jenkinsci.plugins.workinghours.WorkingHoursUI.doDynamic(WorkingHoursUI.java:64)
> at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
> at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343)
> ... 64 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/cb7405da-a1e5-447c-96fe-f5d5a7a4eb15%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Proposal: Jenkins Core PR reviewers team

[Tim Jacomb]

Sounds good to me

On Thu, 19 Sep 2019 at 12:26, Oleg Nenashev  wrote:

> Hi all,
>
> I would like to make a proposal w.r.t the Jenkins Core review process.
>
> As you may see from the pull requests
> , currently we have a pretty
> heavy process which includes multiple reviews, labeling PRs for automatic
> changelog drafts, and so on. This process helps us to maintain high quality
> of weekly releases. Over the last year we have had many contributors who
> helped to review core pull requests on a regular basis. These contributors
> do not have WRITE permission in the repo, and they had no way no assign
> labels, request reviews, re-trigger CI, and so on. Only jenkinsci/Core
> members have permission to do that, and it is a serious overhead since we
> do not have many active core maintainers in jenkinsci/Core looking at PRs.
>
> Few months ago GitHub introduced a new TRIAGE
> 
>  permission
> for the repository which basically gives permissions to manage issues/pull
> requests without being actually able to merge them. IMO it gives us a great
> opportunity to expand the core reviewers bandwidth and at the same time to
> offer a path for onboarding new core maintainers (contributor => Triage =>
> Write permissions).
>
> What I suggest to do:
>
>- Introduce a new jenkinsci/core-pr-reviewers team
>- Grant the team TRIAGE permission in
>https://github.com/jenkinsci/jenkins
>- Maybe?: Add CODEOWNERS to GitHub to automatically request reviews
>from the new team for new pull requests
>- Invite contributors who regularly review Jenkins core pull requests:
>alecharp , varyvol
>, MarkEWaite
>, res0nance
>, jvz ,
>MRamonLeon, halkeye  (sorry if I missed
>anyone!)
>
> If the approach works well, later we can expand it to components which are
> a part of the Jenkins core (libraries, modules, etc.).
>
> What do you think?
>
> Best regards,
> Oleg
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAypnU_vnh3GB3_DVDD5R2vZePjzvsuGtpvXEQTsyOrjQ%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-3BifMF%2B8X%3D8wG4Pbh4Q8cguSzx2j-RmtUmORmw10MsB7aLw%40mail.gmail.com.

Re: Proposal: Jenkins Core PR reviewers team

[Tim Jacomb]

I would be interested in joining this team

On Thursday, 19 September 2019 12:26:46 UTC+1, Oleg Nenashev wrote:
>
> Hi all,
>
> I would like to make a proposal w.r.t the Jenkins Core review process. 
>
> As you may see from the pull requests 
> , currently we have a pretty 
> heavy process which includes multiple reviews, labeling PRs for automatic 
> changelog drafts, and so on. This process helps us to maintain high quality 
> of weekly releases. Over the last year we have had many contributors who 
> helped to review core pull requests on a regular basis. These contributors 
> do not have WRITE permission in the repo, and they had no way no assign 
> labels, request reviews, re-trigger CI, and so on. Only jenkinsci/Core 
> members have permission to do that, and it is a serious overhead since we 
> do not have many active core maintainers in jenkinsci/Core looking at PRs.
>
> Few months ago GitHub introduced a new TRIAGE 
> 
>  permission 
> for the repository which basically gives permissions to manage issues/pull 
> requests without being actually able to merge them. IMO it gives us a great 
> opportunity to expand the core reviewers bandwidth and at the same time to 
> offer a path for onboarding new core maintainers (contributor => Triage => 
> Write permissions).
>
> What I suggest to do:
>
>- Introduce a new jenkinsci/core-pr-reviewers team
>- Grant the team TRIAGE permission in  
>https://github.com/jenkinsci/jenkins
>- Maybe?: Add CODEOWNERS to GitHub to automatically request reviews 
>from the new team for new pull requests
>- Invite contributors who regularly review Jenkins core pull requests: 
>alecharp , varyvol 
>, MarkEWaite 
>, res0nance 
>, jvz , 
>MRamonLeon, halkeye  (sorry if I missed 
>anyone!)
>
> If the approach works well, later we can expand it to components which are 
> a part of the Jenkins core (libraries, modules, etc.).
>
> What do you think?
>
> Best regards,
> Oleg
>
>
>
>
>
>
>
>

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

Re: Proposal: Moving the plugin adoption labels from Wiki to GitHub topics

[Tim Jacomb]

+1

On Mon, 11 Nov 2019 at 14:23, Oleg Nenashev  wrote:

> Hi all,
>
> Currently the Adoption labels are on Wiki, and hence it is no longer a way
> to mark plugins for adoption or unmark them for common contributors. I
> suggest moving the process to GitHub and to use a more-or-less common
> "adopt-me" GitHub topic.
> Suggested changes:
>
>- "adopt-me" label is added to plugins which are currently marked for
>adoption
>   - As a bonus, only people with Write permissions in a repo will be
>   able to mark plugins for adoption
>- https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin is moved to
>GitHub. There are pending JEPs to change the process, but we can move it as
>is for now
>- "*This plugin is up for adoption.* "  is removed from Jenkins from
>Jenkins Wiki macros. Later we can add an integration with GitHub topics to
>the plugin site (https://issues.jenkins-ci.org/browse/INFRA-2240)
>
> Would everyone be fine with such suggestion?
>
> 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/a7ec8008-c0e2-45c3-87e4-932df3af28ba%40googlegroups.com
> 
> .
>

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

Re: Next LTS baseline selection

[Tim Jacomb]

2.205 has the password field redesign in it which would be good to get in,
I’ve been bitten by that before.

There’s a PR to the JCasC plugin with the suggested work around which might
fix the issue (awaiting feedback before merging)

Thanks
Tim

On Thu, 21 Nov 2019 at 07:51, ogondza  wrote:

> I like that idea, Jesse. Can we agree on picking 2.204 with JENKINS-58993
> patched to only fail when assertions are on?
>
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/95885a12-770a-41cb-ae4a-9279fe904e73%40googlegroups.com
> 
> .
>

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

Re: Jenkins debug

[Tim Jacomb]

Can’t you just use the regular jetty:run command with mvnDebug?

https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md#building-and-debugging


On Tue, 17 Dec 2019 at 19:12, Carlos Henrique Oliveira dos Santos <
chos2...@gmail.com> wrote:

> I found out that jenkins-dev plugin is point to a older jetty version.
>
>
> Em terça-feira, 17 de dezembro de 2019 12:54:49 UTC-3, Carlos Henrique
> Oliveira dos Santos escreveu:
>>
>> Hi guys,
>>
>> I am trying to start Jenkins using follow commands:
>>
>> # To change the port run mvnDebug jenkins-dev:run -Dport=9090
>> $ cd war
>> $ mvnDebug jenkins-dev:run
>>
>>
>> ...but i am getting this error:
>>
>>
>>
>> [*WARNING*] Failed startup of context
>> o.e.j.m.p.JettyWebAppContext@78b959ab{Jenkins
>> v${project.version},/,file:///Users/user/Projects/jenkins/war/src/main/webapp/,UNAVAILABLE}{file:///Users/users/Projects/jenkins/war/src/main/webapp/}
>>
>> *java.lang.IllegalStateException*: *No LoginService for
>> org.eclipse.jetty.security.authentication.FormAuthenticator@18c137ed in
>> ConstraintSecurityHandler@3ec850fd{STARTING}*
>>
>> *at* 
>> org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration
>> (*LoginAuthenticator.java:76*)
>>
>> *at* 
>> org.eclipse.jetty.security.authentication.FormAuthenticator.setConfiguration
>> (*FormAuthenticator.java:131*)
>>
>> *at* org.eclipse.jetty.security.SecurityHandler.doStart (
>> *SecurityHandler.java:354*)
>>
>> *at* org.eclipse.jetty.security.ConstraintSecurityHandler.doStart (
>> *ConstraintSecurityHandler.java:448*)
>>
>> *at* org.eclipse.jetty.util.component.AbstractLifeCycle.start (
>> *AbstractLifeCycle.java:68*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.start (
>> *ContainerLifeCycle.java:138*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.doStart (
>> *ContainerLifeCycle.java:108*)
>>
>> *at* org.eclipse.jetty.server.handler.AbstractHandler.doStart (
>> *AbstractHandler.java:113*)
>>
>> *at* org.eclipse.jetty.server.handler.ScopedHandler.doStart (
>> *ScopedHandler.java:123*)
>>
>> *at* org.eclipse.jetty.server.session.SessionHandler.doStart (
>> *SessionHandler.java:503*)
>>
>> *at* org.eclipse.jetty.util.component.AbstractLifeCycle.start (
>> *AbstractLifeCycle.java:68*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.start (
>> *ContainerLifeCycle.java:138*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.doStart (
>> *ContainerLifeCycle.java:108*)
>>
>> *at* org.eclipse.jetty.server.handler.AbstractHandler.doStart (
>> *AbstractHandler.java:113*)
>>
>> *at* org.eclipse.jetty.server.handler.ScopedHandler.doStart (
>> *ScopedHandler.java:123*)
>>
>> *at* org.eclipse.jetty.server.handler.ContextHandler.startContext (
>> *ContextHandler.java:908*)
>>
>> *at* org.eclipse.jetty.servlet.ServletContextHandler.startContext (
>> *ServletContextHandler.java:370*)
>>
>> *at* org.eclipse.jetty.webapp.WebAppContext.startWebapp (
>> *WebAppContext.java:1497*)
>>
>> *at* org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp (
>> *JettyWebAppContext.java:360*)
>>
>> *at* org.eclipse.jetty.webapp.WebAppContext.startContext (
>> *WebAppContext.java:1459*)
>>
>> *at* org.eclipse.jetty.server.handler.ContextHandler.doStart (
>> *ContextHandler.java:847*)
>>
>> *at* org.eclipse.jetty.servlet.ServletContextHandler.doStart (
>> *ServletContextHandler.java:287*)
>>
>> *at* org.eclipse.jetty.webapp.WebAppContext.doStart (
>> *WebAppContext.java:545*)
>>
>> *at* org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart (
>> *JettyWebAppContext.java:428*)
>>
>> *at* org.eclipse.jetty.util.component.AbstractLifeCycle.start (
>> *AbstractLifeCycle.java:68*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.start (
>> *ContainerLifeCycle.java:138*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.doStart (
>> *ContainerLifeCycle.java:117*)
>>
>> *at* org.eclipse.jetty.server.handler.AbstractHandler.doStart (
>> *AbstractHandler.java:113*)
>>
>> *at* org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart
>> (*ContextHandlerCollection.java:168*)
>>
>> *at* org.eclipse.jetty.util.component.AbstractLifeCycle.start (
>> *AbstractLifeCycle.java:68*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.start (
>> *ContainerLifeCycle.java:138*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.doStart (
>> *ContainerLifeCycle.java:117*)
>>
>> *at* org.eclipse.jetty.server.handler.AbstractHandler.doStart (
>> *AbstractHandler.java:113*)
>>
>> *at* org.eclipse.jetty.util.component.AbstractLifeCycle.start (
>> *AbstractLifeCycle.java:68*)
>>
>> *at* org.eclipse.jetty.util.component.ContainerLifeCycle.start (
>> *ContainerLifeCycle.java:138*)
>>
>> *at* org.eclipse.jetty.server.Server.start (*Server.java:416*)
>>
>> *at* 

Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Tim Jacomb]

I would recommend dropping team from the name.

It’s a GitHub team, the word is implied

Tim

On Thu, 12 Dec 2019 at 10:34, Oleg Nenashev  wrote:

> Thanks to all for the feedback
> https://github.com/orgs/jenkinsci/teams/team-docker-packaging was created
> (actually I renamed @jenkinsci/docker), and there are CODEOWNERS PRs to all
> repositories.
> Will also cleanup DockerHub later
>
> BR, Oleg
>
> On Tuesday, December 10, 2019 at 8:47:50 PM UTC+1, Carlos Sanchez wrote:
>>
>> LGTM
>>
>> On Tue, Dec 10, 2019 at 7:51 PM Slide  wrote:
>>
>>> +1 looks like a great idea!
>>>
>>> On Tue, Dec 10, 2019 at 8:38 AM Matt Sicker 
>>> wrote:
>>>
 +1 to this idea and initial maintainers. This would go a long way
 toward unblocking changes in this area! :)

 On Tue, Dec 10, 2019 at 7:42 AM Marky Jackson 
 wrote:
 >
 > I have not been as active as I would like but I would also like to be
 a maintainer based on our previous conversation
 >
 > On Dec 10, 2019, at 3:34 AM, Oleg Nenashev 
 wrote:
 >
 > 
 > BTW, I suggest the following list of maintainers based on the recent
 activity:
 >
 > Mark Waite
 > Alex Earl
 > Carlos Sanchez
 > Oleg Nenashev
 > Baptiste Mathus
 > Olivier Vernin
 >
 > Alternative is to just keep all members of
 https://github.com/orgs/jenkinsci/teams/docker/members though some
 contributors are not active at the moment
 >
 > BR, Oleg
 >
 > On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:
 >>
 >> I would like that very much
 >>
 >> On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev 
 wrote:
 >>>
 >>> Hi all,
 >>>
 >>> Right now we have a number of official packages for Docker:
 >>>
 >>> https://github.com/jenkinsci/docker
 >>> https://github.com/jenkinsci/docker-slave
 >>> https://github.com/jenkinsci/docker-ssh-slave
 >>> https://github.com/jenkinsci/docker-jnlp-slave
 >>> https://github.com/jenkinsci/jnlp-agents
 >>>
 >>> All these repositories have different teams which define
 permissions/. In addition to that we have jenkinsci/docker and
 jenkinsci/docker-packaging-team team which also grant permissions. It is
 quite difficult to manage the repositories in the current state, and it is
 difficult to request reviews.
 >>>
 >>> I suggest to keep things simple and just proceed with a single team
 for the official packaging:
 >>>
 >>> Introduce an official "docker-packaging-team" under umbrella of
 Platform Special Interest group which currently manages Docker packaging
 >>> Cleanup existing teams, leave just one for all official Jenkins
 master and agent mages. Plugin Docker packaging (e.g. Remoting over Apache
 Kafka, Swarm plugin) will not be affected
 >>> Update GitHub and DockerHub teams to reflect the changes (mostly
 jenkins4eval which grants write permissions)
 >>> Add new team to CODEOWNERS in all repos
 >>>
 >>> WDYT?
 >>>
 >>> 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 jenkin...@googlegroups.com.
 >>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com
 .
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 > To unsubscribe from this group and stop receiving emails from it,
 send an email to jenkin...@googlegroups.com.

>>> > To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/d333d077-28bb-431f-9f5a-950440970429%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 jenkin...@googlegroups.com.
 > To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/11566D48-9955-40F5-B5EA-75CAEB228589%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 jenkin...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oxKYCkyCgnqxkxR0A%2BaDk%3Dbj0krcd-xAteAE-r1z-QK%3Dg%40mail.gmail.com
 .

>>>
>>>
>>> --
>>> Website: http://earl-of-code.com
>>>
>>> --
>>> You received this message 

Re: [Jenkins-infra] wiki.jenkins.io is now effectively in read-only mode

[Tim Jacomb]

Do we have any information on the Wiki pages that get the most hits, that
way we could target specific pages to migrate to github / jenkins.io?

A quick google suggests the below, but they may not be enabled:
https://confluence.atlassian.com/confeval/confluence-evaluator-resources/confluence-analytics-statistics
https://confluence.atlassian.com/confkb/how-do-i-get-more-statistics-from-confluence-154239308.html

Thanks
Tim

On Sat, 19 Oct 2019 at 08:53, Oleg Nenashev  wrote:

> First version of the plugin Wiki=>GitHub migration guide is available
> here:
> https://jenkins.io/doc/developer/publishing/wiki-page/#migrating-from-wiki-to-github
> Later it will be improved once I finish the migration tool on the top of
> Pandoc
>
> Could use GitHub topics? Or just add to the readme
>>
>
> Yes, I agree we should use GitHub topics. I already have a prototype of
> integration between GitHub topics and  the plugin site, and we can also
> replace queries on the Wiki page while moving it to jenkins.io
>
> On Friday, October 18, 2019 at 6:52:02 PM UTC+2, Tim Jacomb wrote:
>>
>> Could use GitHub topics? Or just add to the readme
>>
>> On Fri, 18 Oct 2019 at 15:24, Robert Sandell 
>> wrote:
>>
>>> And how do I mark a plugin as up for adoption without the wiki labels?
>>>
>>> /B
>>>
>>> Den fre 18 okt. 2019 kl 14:52 skrev Jesse Glick :
>>>
>>>> On Fri, Oct 18, 2019 at 6:27 AM Daniel Beck  wrote:
>>>> > I propose that we restore write access for plugin maintainers at
>>>> least for a time, to allow them to clear out wiki pages after migrating the
>>>> content elsewhere.
>>>>
>>>> Makes sense, but is there some plan to notify maintainers of plugins
>>>> who have not done this? There are a couple thousand pages out there,
>>>> and many people will not see mailing list notifications reliably.
>>>>
>>>> --
>>>> You received this message because you 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/CANfRfr1k8X17Z3P%2Bs89%2BmUnUXtJW%2BiM2zMc09hPu9_AQ08_k6A%40mail.gmail.com
>>>> .
>>>>
>>>
>>>
>>> --
>>> *Robert Sandell*
>>> Software Engineer
>>> CloudBees, Inc.
>>> [image: CloudBees-Logo.png] <http://www.cloudbees.com/>
>>> E: rsan...@cloudbees.com
>>> Twitter: robert_sandell
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS01y0687MwFnRZvXX3jEsGW5iPVNre6ymGUDuC90sDMpA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS01y0687MwFnRZvXX3jEsGW5iPVNre6ymGUDuC90sDMpA%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/c9d5e4ee-6987-4138-9b48-299b3e58cb7e%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/c9d5e4ee-6987-4138-9b48-299b3e58cb7e%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/CAH-3Bifxn-4a%2BBdMqDXCLYOqC9jeZQQ2rERhrU0gFKSznyxuPw%40mail.gmail.com.

Re: tools.bom not working for recent LTS version of jenkins?

[Tim Jacomb]

There’s an open pull request for the latest LTS line
https://github.com/jenkinsci/bom/pull/110

I think the main reason for the delay is the trilead-api split from core
has caused issues in a few plugins tests

Tim
On Thu, 24 Oct 2019 at 05:24, Mark Waite  wrote:

>
>
> On Wed, Oct 23, 2019 at 10:18 PM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> https://repo.jenkins-ci.org/releases/io/jenkins/tools/bom/
>>
>> There's no 2.190.1 version there
>>
>> I honestly don't know if there should be, is there a reason you need to
>> compile your plugin with the latest lts?
>>
>
> As part of my attempt to run the git client plugin automated tests with
> Jenkins 2.190.1, one of the paths being considered was to create a new
> release of the git client plugin which requires Jenkins 2.190.1 as its
> minimum version.  Since the git client plugino uses the plugin bom, it
> seems like it would need a 2.190.x release of the plugin bom.  That would
> allow the git client plugin to depend directly on trilead-api plugin 1.0.5,
> without the classloader related risks of depending on earlier versions of
> the trilead-api plugin when that plugin may not be available in earlier
> versions.  Refer to conversations on
> https://github.com/jenkinsci/git-client-plugin/pull/467 for more details.
>
> However, it would not be very much work to create that 2.190.1 based git
> client plugin release without the plugin bom, then update it later when the
> plugin bom becomes available.
>
>
>> Gavin
>>
>>
>>
>> On Wed, Oct 23, 2019 at 9:04 PM Mike Caspar 
>> wrote:
>>
>>>
>>> The error I get is...
>>>
>>> Failure to find io.jenkins.tools.bom:bom:pom:2.190.1 in
>>> https://repo.jenkins-ci.org/public/ was cached in the local repository,
>>> resolution will not be reattempted until the update interval of
>>> repo.jenkins-ci.org has elapsed or updates are forced
>>>
>>>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/a0c31d5f-85c3-4e95-8278-6962497b2991%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/CAG%3D_DusKMFcmUUaa8gqUYda%2B2j3LKF01MGoARMTowCzWY2xBmQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE%2BiipQn6JRyMhcrOKDd%3DVXwg9DM1Q4Zk9f-rcFzd2g-Q%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-3BiffCKn%3D7pg5WPJEgLLLzMga8b_jzO1agp5fXWxteG5rFQ%40mail.gmail.com.

Re: [Jenkins-infra] wiki.jenkins.io is now effectively in read-only mode

[Tim Jacomb]

Could use GitHub topics? Or just add to the readme

On Fri, 18 Oct 2019 at 15:24, Robert Sandell  wrote:

> And how do I mark a plugin as up for adoption without the wiki labels?
>
> /B
>
> Den fre 18 okt. 2019 kl 14:52 skrev Jesse Glick :
>
>> On Fri, Oct 18, 2019 at 6:27 AM Daniel Beck  wrote:
>> > I propose that we restore write access for plugin maintainers at least
>> for a time, to allow them to clear out wiki pages after migrating the
>> content elsewhere.
>>
>> Makes sense, but is there some plan to notify maintainers of plugins
>> who have not done this? There are a couple thousand pages out there,
>> and many people will not see mailing list notifications reliably.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1k8X17Z3P%2Bs89%2BmUnUXtJW%2BiM2zMc09hPu9_AQ08_k6A%40mail.gmail.com
>> .
>>
>
>
> --
> *Robert Sandell*
> Software Engineer
> CloudBees, Inc.
> [image: CloudBees-Logo.png] 
> E: rsand...@cloudbees.com
> Twitter: robert_sandell
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS01y0687MwFnRZvXX3jEsGW5iPVNre6ymGUDuC90sDMpA%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-3BicsFkKUJQJb6bdBDK-L2AGmTFKo6oNo_eRwigu1da7%2BTw%40mail.gmail.com.

Re: Proposal to switch from OpenJDK to AdoptOpenJDK

[Tim Jacomb]

You shouldn’t need to set any flags on java 8 since u191 for enhanced
container support

https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712



On Fri, 25 Oct 2019 at 19:21, Oleg Nenashev  wrote:

> As for your comment on OpenJ9, what did you mean by saying it will be more
>> tricky taking historical reports in JIRA?
>
> Will try to reply later once I have time to find issue links
>
>
>> Is there an issue/discussion open for the move to Java 11? I would love
>> to see this happen as well!
>
> No discussion. JEP-211
>  deliberately set
> no timeline for switching to Java 11 by default. We ship official OpenJDK
> 11 images tho.
> But for me it is a no-brainer that we should switch sooner or later. Our
> default images do not set experimental flags for Java 8 to enable
> integration with cgroups, so basically Jenkins does not apply resource
> restrictions n Docker and K8s.
> I think Java 11 enablement is justified just by this fact.
>
>
>
> On Fri, Oct 25, 2019 at 9:09 PM Jim Crowley  wrote:
>
>> Oleg,
>>
>> That’s a good idea. Support both before we make the full switch over to
>> AdoptOpenJDK.
>>
>> As for your comment on OpenJ9, what did you mean by saying it will be
>> more tricky taking historical reports in JIRA?
>>
>> Is there an issue/discussion open for the move to Java 11? I would love
>> to see this happen as well!
>>
>>
>> On Friday, October 25, 2019 at 2:03:38 PM UTC-4, Oleg Nenashev wrote:
>>>
>>> Sorry for being late to the thread. I am +1 for migrating Jenkins to
>>> AdoptOpenJDK by default.
>>> We already run significant parts of our infrastructure on AdoptOpenJDK,
>>> and so far I have not seen any issues when the HotSpot engine is used.
>>> OpenJ9 would be much more tricky taking the historical reports in
>>> Jenkins JIRA.
>>>
>>> We also have an option to ship OpenJDK and AdoptOpenJDK images in
>>> parallel and then move when we feel it works well.
>>> Bonus points for switching to Java 11 by default at the same time :D
>>>
>>>
>>> BR, Oleg
>>>
>>>
>>>
>>>
>>> On Wednesday, October 23, 2019 at 8:08:42 PM UTC+3, Jim Crowley wrote:

 Thanks for the information and invite. I'll try to make it tomorrow.

 On Tuesday, October 22, 2019 at 5:04:20 PM UTC-4, Mark Waite wrote:
>
> This seems like a very good topic for discussion in the Jenkins
> Platform Special Interest Group meeting Thursday at 14:00 UTC (
> https://jenkins.io/sigs/platform/#meetings)  .  I've added two items
> to the agenda (
> https://docs.google.com/document/d/1bDfUdtjpwoX0HO2PRnfqns_TROBOK8tmP6SgVhubr2Y/edit#
> ).
>
> The meeting is hosted through Zoom video conferencing and is
> recorded.  The meeting URL is posted to the Gitter channel about 10 
> minutes
> before the meeting starts ( https://gitter.im/jenkinsci/platform-sig).
>
> On Tue, Oct 22, 2019 at 2:49 PM Jim Crowley  wrote:
>
>> Irwin,
>>
>>
>> Thanks for the links! One of those issue is one I opened up! Like I
>> mentioned to Mark, I spoke with the Adopt team and the additional support
>> of more base images are coming in the next PR. The testing framework 
>> needs
>> to be updated first to support the additional bases.
>>
>>
>>
>> On Tuesday, October 22, 2019 at 4:30:20 PM UTC-4, Irwin D'Souza wrote:
>>>
>>> I mentioned this thread on the AdoptOpenJDK slack instance; it looks
>>> like there's been talks around increased Docker base image coverage:
>>> https://github.com/AdoptOpenJDK/openjdk-docker/issues/236 &
>>> https://github.com/AdoptOpenJDK/openjdk-tests/issues/1109
>>>
>>> On Tue, Oct 22, 2019 at 1:47 PM Mark Waite 
>>> wrote:
>>>
 Yes, issues with musl vs. glibc were the key reason that I had
 heard for OpenJDK to not be willing to support Java 11 on Alpine.

 I don't see any mention of Alpine or Debian on the official images
 page at  https://hub.docker.com/_/adoptopenjdk .  There is mention
 of Alpine and Debian on the unofficial images page at
 https://hub.docker.com/r/adoptopenjdk/openjdk8 .  Is there
 somewhere that the difference between official and unofficial 
 AdoptOpenJDK
 images is described?

 On Tue, Oct 22, 2019 at 7:30 AM Jim Crowley 
 wrote:

> Mark,
>
> For Alpine are you referring to the issue with glibc vs musl? It
> looks like the AdoptOpenJDK team built Alpine images with glibc 
> install on
> top of the base image. You can look at the Dockefile here,
> https://github.com/AdoptOpenJDK/openjdk-docker/tree/master/8/jdk/alpine
> .
>
> I am loving the AdoptOpenJDK team's support for multiple platforms
> too! I think it is also nice having all the OpenJ9 builds as well as
> Hotspot. Give users more 

Re: builds have stopped building with windows 8 slaves

[Tim Jacomb]

Isn’t this the same as the previous email in this group about constant
ci.jenkins.io failures?

On Sat, 26 Oct 2019 at 20:07, Mike Caspar  wrote:

> (I changed the IP addresses to not leak out IP addresses)
>
> When windows 8 test machines are launched, I get this message from Blue
> Ocean.
>
> 019-10-26T18:27:16.629Z] Unpacking
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.5.4/apache-maven-3.5.4-bin.zip
> to C:\Jenkins\tools\hudson.tasks.Maven_MavenInstallation\mvn on
> win2012-db2580
>
> Remote call on JNLP4-connect connection from xx.yy.zz.aa/bb.cc.dd.zz:49187
> failed
>
> In console, I see this message (only a partial paste)...
>
> Nothing had changed except for an attempt to change url to new location
> for wiki changeover (also does not build when reverted).
>
> Not sure if I should report this in infra or as a problem in workflow?
> Perhaps someone who knows can forward this along?
>
> If you are interested an can help, check the latest builds for
> ironmq-notifier
>
> Thanks
>
>
> java.lang.OutOfMemoryError: Java heap space
> 11:27:19  Also:
>  org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsBodyExecution.cancel(CpsBodyExecution.java:253)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.steps.BodyExecution.cancel(BodyExecution.java:76)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.steps.ParallelStepExecution.stop(ParallelStepExecution.java:67)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.steps.ParallelStep$ResultHandler$Callback.checkAllDone(ParallelStep.java:147)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.steps.ParallelStep$ResultHandler$Callback.onFailure(ParallelStep.java:134)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsBodyExecution$FailureAdapter.receive(CpsBodyExecution.java:361)
> 11:27:19  at
> com.cloudbees.groovy.cps.impl.ThrowBlock$1.receive(ThrowBlock.java:68)
> 11:27:19  at
> com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
> 11:27:19  at com.cloudbees.groovy.cps.Next.step(Next.java:83)
> 11:27:19  at
> com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
> 11:27:19  at
> com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
> 11:27:19  at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
> 11:27:19  at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
> 11:27:19  at
> com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:186)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:370)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:282)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:270)
> 11:27:19  at
> org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:66)
> 11:27:19  at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 11:27:19  at
> hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
> 11:27:19  at
> jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
> 11:27:19  at jenkins.security.ImpersonatingExecutorService$1.run(Impersona
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/f945662b-e451-4b4a-b45c-00fc6c87ca77%40googlegroups.com
> 
> .
>

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

Re: Enabling ImgBot in jenkinsci and in jenkins-infra/jenkins.io?

[Tim Jacomb]

+1

On Mon, 7 Oct 2019 at 11:10, Raihaan Shouhell 
wrote:

> I think its a good idea  +1
>
> On Monday, 7 October 2019 16:09:29 UTC+8, Oleg Nenashev wrote:
>>
>> Hi all,
>>
>> I would like to enable ImgBot in
>> some of my plugins in order to optimize image sizes. ImgBot is a bot which
>> creates pull requests with image optimizations, e.g. here is a sample pull
>> requests for the Jenkins Core:
>> https://github.com/oleg-nenashev/jenkins/pull/38. There are a lot of
>> historical images in Jenkins, and it could be a good opportunity to
>> optimize them.
>>
>> There is a free open-source plan for ImgBot, so I think enabling the bot
>> should not be a problem. As for other bots, I suggest we enable it in the
>> org but do not enable it widely by default. Each plugin maintainer will be
>> able to enable it on his/her own.
>>
>> What do you think?
>>
>> 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/98b1fe89-d010-40e2-8103-a70d085fcdd0%40googlegroups.com
> 
> .
>

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

Re: Proposal teams: GitHub teams for active contributors without write permissions

[Tim Jacomb]

What benefit does the team have? Over just adding the person to the org

On Sun, 6 Oct 2019 at 01:12, Oleg Nenashev  wrote:

> Hi all,
>
> I would like to sign-off creating GitHub teams for active contributors who
> do not have write access to repositories in jenkinsci and jenkins-infra
> organizations.
>
> *Why?* We have many contributors who help the Jenkins project a lot but
> not listed as organization members on GitHub... just because they do not
> need any special permissions for their work. For example, René Scheibe
>  and Zbynek Konecny
>  contributed dozens of pull requests to
> improve documentation and code across multiple components... but they are
> not members of jenkinsci. Adding such contributors to the organization is
> IMHO a way to recognize their contributions, and it allows contributors to
> put the Jenkins org badge to their GitHub profiles. It would also allow to
> request their reviews in the components if needed.
>
> *What do I propose?*
>
>- Private "contributors" teams are created in jenkinsci and
>jenkins-infra. Teams are private so that they cannot be mentioned
>unintentionally. Teams have no specific access to the repositories
>- External contributors can be added to the organization if they
>remain active in the community for 1 month or above and create 5+ pull
>requests (feel free to propose different numbers, I am just trying to set
>some criteria)
>- Jenkins GitHub admins can add people to the teams upon request
>- ChatOps bot command may be implemented later to enable other
>maintainers to add contributors
>
>  What do you think?
>
> 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/CAPfivLDPu77BovhUiGamx1t5FewLgq-Xu0hcQwjBk07D39Z99w%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-3BidgBQ8F8CeJCj-ZLB2K6Q-Syp90pb4ubSBp%2BtD%3DCL7MZQ%40mail.gmail.com.

Re: How to rename a Jenkins plugin?

[Tim Jacomb]

Normally you would update the plugin name in the your pom.xml and do a
release
https://github.com/jenkinsci/ibm-asoc-plugin/blob/master/pom.xml#L4

This will update the display name but not the artifact ID, i.e. it will
still show up in URLs like the plugin site

Other than that I  think you need to publish a new version that has an
administrative monitor / log messages telling users to migrate to the new
one

Thanks
Tim

On Wed, 9 Oct 2019 at 09:55, Matt Murphy  wrote:

> I’m the maintainer for the the IBM Application Security on Cloud
>  plugin.  The cloud
> service that this plugin interacts with is no longer owned by IBM, so I’d
> like to rename the plugin.  I don’t want to publish a new plugin with the
> new name because that would force users to reconfigure their jobs.
>
>
>
> I tried searching for steps to accomplish this, but I haven’t found
> anything.  Is it possible to rename a plugin (including changing the
> groupId)?
>
>
>
> Thanks for your help.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/03b18a1c-c072-4cc1-8bd4-868d4768f60b%40googlegroups.com
> 
> .
>

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

Re: 502 proxy error on ci.jenkins.io

[Tim Jacomb]

Seems to be happening again now
https://p.datadoghq.com/sb/0Igb9a-dca9738dbb5048025c005182a8f240c0

On Wed, 2 Oct 2019 at 15:14, Paul Allen  wrote:

> Thanks - It seems to be working now.
>
> > On 2 Oct 2019, at 10:24, Olblak  wrote:
> >
> > As you can see on this status page, there is definitely something wrong,
> I start looking at it
> >
> > ---
> > -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> > ---
> >
> >
> >
> >
> > On Wed, Oct 2, 2019, at 10:37 AM, pallen wrote:
> >> Hi Guys,
> >>
> >> I'm getting a 502 proxy error on ci.jenkins.io?  Is it just me or is
> there an outage?
> >>
> >> Kind regards,
> >> Paul
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/fdc23c1f-ecf0-47bc-b4d8-d3bf126b2170%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/bd355020-3a8e-45ec-a2cc-4eb0f87e68c8%40www.fastmail.com
> .
>
> This e-mail may contain information that is privileged or confidential. If
> you are not the intended recipient, please delete the e-mail and any
> attachments and notify us immediately.
>
> Perforce Software UK Ltd is registered in England and Wales as company no.
> 3816019 at the following address: West Forest Gate,
> Wellington Road, Wokingham,
> RG40 2AT, UK
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/5475CAA0-A0A1-4619-9983-3F49D763D1B0%40perforce.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-3Bier9Qgwc6qsDvV_q0yqg_bmzUMi5YoLsbadLaRATeOQBA%40mail.gmail.com.

Re: Newest base pom with really old plugin

[Tim Jacomb]

I would highly recommend just picking a version that the plugin bom
supports, it makes dependency management far easier

On Thu, 19 Dec 2019 at 11:33, Mark Waite  wrote:

>
>
> On Thu, Dec 19, 2019 at 2:32 AM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> Awesome, 2.60 builds though tests fail in good ways I need to fix
>>
>> Can 2.60 support pipeline symbols? I'm thinking I might want to expand it
>> a bit so you can trigger browser notifications inside of pipelines.
>>
>>
> I'm confident it can, since that was the version that git plugin 4.0.0
> required for a large portion of its 18 month beta cycle.
>
> I'd take Uli's recommendation of 2.138 as an even better recommendation.
> It brings you into the set of releases that have even more helpful things
> available.  That is the base version for the git plugin 4.0.0 and feels
> like a nice stable point until the next major "leap".  I expect the next
> major leap after 2.138 will be either 2.190 or 2.204.  That next major leap
> is probably a year or two away for things that I maintain.
>
> I also agree with Baptiste that administrators running very old Jenkins
> versions are much less likely to update to a new plugin release.
>
>
>> Gavin
>>
>>
>> On Thu, Dec 19, 2019 at 1:26 AM Mark Waite 
>> wrote:
>>
>>> I think you'll have better results if you switch to java 8 and Jenkins
>>> 2.60 or newer as base version. That is the first LTS that required Java 8,
>>> if I recall correctly.
>>>
>>> Switch the major version of the plugin at release and call it good.
>>>
>>> On Thu, Dec 19, 2019, 2:17 AM 'Gavin Mogan' via Jenkins Developers <
>>> jenkinsci-dev@googlegroups.com> wrote:
>>>
 Hey all,

 I wanted to do some cleanup, do a few fixes, and release a new version
 of a really old plugin of mine, so I could move the docs from wiki to
 github.

 I thought it would be a good idea to update to latest base pom cause
 ... its better.

 So it was originally targeting 1.455 with java 5 (which i now think
 should have been 7). Updating it to use 7, I still fail to build due to
 enforcer errors

 [INFO] Restricted to JDK 1.7 yet org.codehaus.
 *mojo:animal-sniffer-annotations:jar:1.18:provided* contains
 org/codehaus/mojo/animal_sniffer/IgnoreJRERequirement.class targeted to JDK
 8
 [WARNING] Rule 2:
 org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with
 message:
 Found Banned Dependency:
 org.codehaus.mojo:animal-sniffer-annotations:jar:1.18

 [WARNING] Rule 3: org.apache.maven.plugins.enforcer.BannedDependencies
 failed with message:
 Found Banned Dependency:* org.sonatype.sisu:sisu-guice:jar:3.1.0*


 Both of these come from the super early jenkins core. Is there a way to
 ignore this, or a good recommended core version to use? or can I just bump
 things?

 Gavin

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dutr1LxFDugY1vKwGCE_m5chB60QU1oeWgwVr4byFmx4bA%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/CAO49JtEjjSWuXnYOZS0HUdDDVm79sZXqN0DpVRDKgFUhNLz%3DPQ%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_DutxUTtdP-G36ug9jQy3yD6scw7BhqgYZjLdK%2B1TY6kgoQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this 

Re: Newest base pom with really old plugin

[Tim Jacomb]

The minimum recommended version in the docs is 2.138.x
https://jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/

On Thu, 19 Dec 2019 at 12:13, Tim Jacomb  wrote:

> I would highly recommend just picking a version that the plugin bom
> supports, it makes dependency management far easier
>
> On Thu, 19 Dec 2019 at 11:33, Mark Waite 
> wrote:
>
>>
>>
>> On Thu, Dec 19, 2019 at 2:32 AM 'Gavin Mogan' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> Awesome, 2.60 builds though tests fail in good ways I need to fix
>>>
>>> Can 2.60 support pipeline symbols? I'm thinking I might want to expand
>>> it a bit so you can trigger browser notifications inside of pipelines.
>>>
>>>
>> I'm confident it can, since that was the version that git plugin 4.0.0
>> required for a large portion of its 18 month beta cycle.
>>
>> I'd take Uli's recommendation of 2.138 as an even better recommendation.
>> It brings you into the set of releases that have even more helpful things
>> available.  That is the base version for the git plugin 4.0.0 and feels
>> like a nice stable point until the next major "leap".  I expect the next
>> major leap after 2.138 will be either 2.190 or 2.204.  That next major leap
>> is probably a year or two away for things that I maintain.
>>
>> I also agree with Baptiste that administrators running very old Jenkins
>> versions are much less likely to update to a new plugin release.
>>
>>
>>> Gavin
>>>
>>>
>>> On Thu, Dec 19, 2019 at 1:26 AM Mark Waite 
>>> wrote:
>>>
>>>> I think you'll have better results if you switch to java 8 and Jenkins
>>>> 2.60 or newer as base version. That is the first LTS that required Java 8,
>>>> if I recall correctly.
>>>>
>>>> Switch the major version of the plugin at release and call it good.
>>>>
>>>> On Thu, Dec 19, 2019, 2:17 AM 'Gavin Mogan' via Jenkins Developers <
>>>> jenkinsci-dev@googlegroups.com> wrote:
>>>>
>>>>> Hey all,
>>>>>
>>>>> I wanted to do some cleanup, do a few fixes, and release a new version
>>>>> of a really old plugin of mine, so I could move the docs from wiki to
>>>>> github.
>>>>>
>>>>> I thought it would be a good idea to update to latest base pom cause
>>>>> ... its better.
>>>>>
>>>>> So it was originally targeting 1.455 with java 5 (which i now think
>>>>> should have been 7). Updating it to use 7, I still fail to build due to
>>>>> enforcer errors
>>>>>
>>>>> [INFO] Restricted to JDK 1.7 yet org.codehaus.
>>>>> *mojo:animal-sniffer-annotations:jar:1.18:provided* contains
>>>>> org/codehaus/mojo/animal_sniffer/IgnoreJRERequirement.class targeted to 
>>>>> JDK
>>>>> 8
>>>>> [WARNING] Rule 2:
>>>>> org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with
>>>>> message:
>>>>> Found Banned Dependency:
>>>>> org.codehaus.mojo:animal-sniffer-annotations:jar:1.18
>>>>>
>>>>> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.BannedDependencies
>>>>> failed with message:
>>>>> Found Banned Dependency:* org.sonatype.sisu:sisu-guice:jar:3.1.0*
>>>>>
>>>>>
>>>>> Both of these come from the super early jenkins core. Is there a way
>>>>> to ignore this, or a good recommended core version to use? or can I just
>>>>> bump things?
>>>>>
>>>>> Gavin
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Jenkins Developers" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dutr1LxFDugY1vKwGCE_m5chB60QU1oeWgwVr4byFmx4bA%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dutr1LxFDugY1vKwGCE_m5chB60QU1oeWgwVr4byFmx4bA%40mail.gmail.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>&

Re: JEP-225: Folder-based access control for any credentials provider

[Tim Jacomb]

Scoping to a job

On Thu, 13 Feb 2020 at 11:23, Chris Kilding 
wrote:

> I was unclear on point 2. Is this a way to…
> - scope a credential to an individual job or jobs?
> - scope a credential to an individual build or builds?
> - provide ephemeral credentials that are created at the start of a build,
> exist during the lifetime of the build, and are scrapped at the end?
>
> Ephemeral credentials would be harder, as we would have to reconcile the
> long-lived nature of credentials (and the extra constraints of remote
> credential providers) with the short-lived nature of builds.
>
> Chris
>
> On 13 Feb 2020, at 06:40, Tim Jacomb  wrote:
>
> Which bit were you unclear about?
> Point 1?
>
> Point 1 is a request based authorisation, nothing is allowed to use it by
> default, jobs request to use it and then an autrhorised person allows it
>
> On Wed, 12 Feb 2020 at 23:36, Chris Kilding <
> chris+jenk...@chriskilding.com> wrote:
>
>> Point 2 (credentials scoped to a single build) could be relevant - if
>> we’re adding a credentials concept to a general ACL, a user should be able
>> to apply any kind of restriction that their ACL permits to the credentials
>> objects. (Not just folder restrictions.)
>>
>> I’m a bit unclear about what you meant though - could you clarify, maybe
>> with an example?
>>
>> Chris
>>
>> On 12 Feb 2020, at 18:01, Tim Jacomb  wrote:
>>
>> 
>>
>> Not directly related, possibly even to this JEP,
>>
>> But wanted to add a couple of features I’ve seen in other systems,
>>
>> 1. Require authorisation, before allowed to use, I.e build is run and
>> fails because the credential isn’t authorised for that job but then an
>> administrator can authorise it and it will be allowed to use it on the next
>> run,
>> 2. Credentials scoped to a single build
>>
>> Thanks
>> Tim
>>
>> On Wed, 12 Feb 2020 at 17:50, Chris Kilding <
>> chris+jenk...@chriskilding.com> wrote:
>>
>>> The first thing to figure out is what role-based access control
>>> solutions are already out there for Jenkins, so we can then decide how best
>>> to fit this functionality in.
>>>
>>> I have encountered the following solutions which seem relevant, but I
>>> know very little about them:
>>>
>>> - Cloudbees RBAC plugin (commercial)
>>> - Role Strategy Plugin
>>> - Jenkins permissions system
>>>
>>> Would someone who knows these components well be able to provide more
>>> details, and thoughts on how we might add concepts of folders and
>>> credentials to them, so that credential access constraints could be
>>> formulated as standard rules?
>>>
>>> Chris
>>>
>>> > On 12 Feb 2020, at 16:29, Chris Kilding <
>>> chris+jenk...@chriskilding.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > This is the discussion thread for JEP-225: Folder-based access control
>>> for any credentials provider.
>>> >
>>> > A brief summary...
>>> >
>>> > The Cloudbees Folders Plugin has the ability to restrict access to
>>> credentials on a per-folder basis. Unfortunately this feature is only
>>> available for credentials stored in the Folders plugin's internal provider.
>>> This JEP will extend that concept, and allow users to specify folder-based
>>> access restrictions for any credential, from any provider.  (For example,
>>> the AWS Secrets Manager and Kubernetes providers.)
>>> >
>>> > This JEP is relevant in 2 notable cases:
>>> >
>>> > - Dev / Production environment isolation. (Ensure that only jobs in
>>> the production environment can access production credentials, and vice
>>> versa.)
>>> > - Per-team isolation on a multi-tenant Jenkins. (Ensure that only a
>>> given team or teams can access their credentials.)
>>> >
>>> > You can follow the pull request at
>>> https://github.com/jenkinsci/jep/pull/266.
>>> >
>>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40

Re: GitHub issues option in HOSTING

[Tim Jacomb]

As far as I know for jira cloud the only log in options are atlassian
account or SAML (may be premium option, can’t find docs for it)

For server there’s this paid add on:
https://marketplace.atlassian.com/apps/1217688/oauth-openid-connect-oidc-for-jira-sso?hosting=server=overview
but nothing free that I can see.

On Sat, 8 Feb 2020 at 23:54, Chris Kilding 
wrote:

> While there are differences of opinion on the issue *storage* problem (ie
> do we store our issues in Jira or GitHub), there seems to be common ground
> on solving the *access* problem for users that report issues.
>
> If we can get a GitHub connector up and running for Jira, so that any user
> who wants to report an issue can simply sign in with the GitHub account
> that they (in all likelihood) have already got, we can solve the access
> problem and lower the barrier to entry for reporters.
>
> I don’t know the split between how many reporters we lose because they
> can’t (or won’t) make a Jira account vs. how many we lose because they
> can’t navigate Jira once they’re in. But it would be a start.
>
> This suggests a couple of questions:
>
> 1. Can such a GitHub connector be installed on the Jira we’ve already got?
> 2. If not, can anyone provide a (vague) timescale for getting things into
> Jira Cloud and enabling the connector? (I appreciate this is probably a
> long job.)
>
> Chris
>
> On Sat, 8 Feb 2020, at 2:14 PM, Daniel Beck wrote:
>
>
>
> On Sat, Feb 8, 2020 at 2:46 PM Tim Jacomb  wrote:
>
>
> (replies inline)
> On Sat, 8 Feb 2020 at 12:13, Daniel Beck  wrote:
>
>
> On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
> I also really want to see issues.jenkins go away, but mostly due to how
> slow it is. I don't think cloud is a lot better, but way less maintenance
> for people.
>
>
> When was the last time our Jira instance had performance/availability
> problems? I don't think there have been any problems so far this year, and
> probably not to a notable degree in the last few months of last year...
>
>
>  Now?
> [image: image.png]
> It takes me 9 seconds to open JIRA for it to be interactive.
> And then I have to log in every single time...
>
>
> The only view that even comes close to that for me is the System Default
> dashboard when not logged in, is that what I'm seeing here?(How about
> following an issue link from the changelog?)
>
> I have five custom dashboards, so I never see the default one -- and
> opening issues is almost instantaneous for me. Otherwise I'd go crazy,
> updating dozens of issues every week for the past several years.
>
> I'm also not logged out more than once a week or so. Is it possible that
> you're rarely using Jira to begin with?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BQsV%3DxJEGMdo1NU%3D5PxiMbE6c8bbMu7SrKmHcC06Fn%3Dg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BQsV%3DxJEGMdo1NU%3D5PxiMbE6c8bbMu7SrKmHcC06Fn%3Dg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> *Attachments:*
>
>- image.png
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/fa60cafb-7b5f-406b-a14c-8467015e4f9f%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/fa60cafb-7b5f-406b-a14c-8467015e4f9f%40www.fastmail.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-3BicWcY92OGr8sJcWUMG4UhSqarAu7Y_DNNCw-B9M1az_nw%40mail.gmail.com.

Re: JEP-225: Folder-based access control for any credentials provider

[Tim Jacomb]

Not directly related, possibly even to this JEP,

But wanted to add a couple of features I’ve seen in other systems,

1. Require authorisation, before allowed to use, I.e build is run and fails
because the credential isn’t authorised for that job but then an
administrator can authorise it and it will be allowed to use it on the next
run,
2. Credentials scoped to a single build

Thanks
Tim

On Wed, 12 Feb 2020 at 17:50, Chris Kilding 
wrote:

> The first thing to figure out is what role-based access control solutions
> are already out there for Jenkins, so we can then decide how best to fit
> this functionality in.
>
> I have encountered the following solutions which seem relevant, but I know
> very little about them:
>
> - Cloudbees RBAC plugin (commercial)
> - Role Strategy Plugin
> - Jenkins permissions system
>
> Would someone who knows these components well be able to provide more
> details, and thoughts on how we might add concepts of folders and
> credentials to them, so that credential access constraints could be
> formulated as standard rules?
>
> Chris
>
> > On 12 Feb 2020, at 16:29, Chris Kilding 
> wrote:
> >
> > Hello,
> >
> > This is the discussion thread for JEP-225: Folder-based access control
> for any credentials provider.
> >
> > A brief summary...
> >
> > The Cloudbees Folders Plugin has the ability to restrict access to
> credentials on a per-folder basis. Unfortunately this feature is only
> available for credentials stored in the Folders plugin's internal provider.
> This JEP will extend that concept, and allow users to specify folder-based
> access restrictions for any credential, from any provider.  (For example,
> the AWS Secrets Manager and Kubernetes providers.)
> >
> > This JEP is relevant in 2 notable cases:
> >
> > - Dev / Production environment isolation. (Ensure that only jobs in the
> production environment can access production credentials, and vice versa.)
> > - Per-team isolation on a multi-tenant Jenkins. (Ensure that only a
> given team or teams can access their credentials.)
> >
> > You can follow the pull request at
> https://github.com/jenkinsci/jep/pull/266.
> >
> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%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/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%40mail.gmail.com.

Re: LTS baseline selection

[Tim Jacomb]

We've been running 2.222 in production since first thing Monday,

No issues so far,

We enabled the global background build discarder, it ran for about 9 hours
on the first run and cleared up ~200GB of space,
We're very happy with the disk cleanup feature in 2.221 (thanks DB)

Thanks
Tim

On Tue, 25 Feb 2020 at 22:59, Daniel Beck  wrote:

>
>
> > On 25. Feb 2020, at 16:44, Oleg Nenashev  wrote:
> >
> > There is also  https://issues.jenkins-ci.org/browse/JENKINS-60409 which
> needs to be investigated for the new LTS candidate. Looks like the default
> Jetty behavior changed, and it may impact some users when they upgrade to
> the new baseline
>
> Irrelevant for this thread, as that issue affects every weekly release
> newer than the current LTS baseline. Might need upgrade docs or an
> expedited fix + back port but that applies to every potential LTS baseline
> choice.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/7E8CB82D-2A1F-4A02-B42A-2AE0920CD822%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/CAH-3BieKEt0Jv3RZb19yWmBZNTbyr%2Bmf%2BAmjP1SxeO3XdEvGfA%40mail.gmail.com.

Re: LTS baseline selection

[Tim Jacomb]

That looks like a fairly minor css tweak to fix that, is it just the search
input? I wouldn’t exclude it from LTS for that issue

On Tue, 25 Feb 2020 at 13:52, Ullrich Hafner 
wrote:

> While I like the new look, a mix of the new UI and the existing material
> theme looks kind of weird now, even with disabled UI flag. There are a lot
> of changes that are not part of the flag:
>
> Jenkins 2.222 (new UI disabled):
>
>
>
> Jenkins LTS:
>
>
>
>
> Am 25.02.2020 um 14:39 schrieb Oleg Nenashev :
>
> Hi Ulli,
>
> The new frontend styling is behind the feature flag. By default there is
> only a change in the Jenkins header which should not impact the plugin
> developers except few ones who extend breadcrumbs or customize login/search
> controls. I believe that only few plugin maintainers would be affected
> there. Theme developers are a different story, and indeed there is likely
> to be an impact on them. AFAIK Felix did some experiments with Material
> Design Themes tho, and they worked pretty well out-of-the-box
>
> BR, Oleg
>
>
>
> On Tuesday, February 25, 2020 at 2:29:42 PM UTC+1, Ullrich Hafner wrote:
>>
>>
>>-
>>2.222 was released this Sunday, and the release metrics are yet to be
>>seen.
>>   - The community rating is 19 positives and 2 "I had to rollback"
>>   - There is no issues reported to this release in Jira or in social
>>   media
>>   - There is one negative feedback in the UX SIG Gitter
>>    about the header size in the
>>   default UI. The header went from 68px to 96px (thanks Wadeck) and 
>> caused
>>   some feedback about mispositioned controls and impact on muscle memory
>>   by Rocky Breslow. I consider it as an important feedback, but AFAICT 
>> we can
>>   optimize the header size and backport the change if needed
>>
>>
>> I think we should give theme authors (and maybe plugin developers) more
>> time to update their plugins to the new styling. Otherwise the new UI
>> improvements might look like a step backward rather than a step forward.
>> Then we also have the chance to provide some more UI enhancements in other
>> areas so that the overall appearance looks consistent.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/2b66fcbd-3b15-4fea-8d39-9beeb11f5a8f%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/64C2E3C8-CA2D-4C36-BFAF-9889BA1EA634%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/CAH-3BieW76tV_2%3DqvwAJy7BpnaFzCZ6Mucoi7KGCY-JLefqABQ%40mail.gmail.com.

Re: LTS baseline selection

[Tim Jacomb]

Yes we have the new header UI enabled, the feedback I got from users was
they liked it, no negative feedback received.
JEP-223: No we have no use for it as our instance is fully managed in code

Thanks
Tim

On Wed, 26 Feb 2020 at 15:04, Baptiste Mathus  wrote:

> Curious @Tim:
> did you also:
>
>- enable the new header UI?
>- enable JEP-223?
>
> Thanks!
>
>
> On Wed, Feb 26, 2020 at 11:02 AM Tim Jacomb  wrote:
>
>> We've been running 2.222 in production since first thing Monday,
>>
>> No issues so far,
>>
>> We enabled the global background build discarder, it ran for about 9
>> hours on the first run and cleared up ~200GB of space,
>> We're very happy with the disk cleanup feature in 2.221 (thanks DB)
>>
>> Thanks
>> Tim
>>
>> On Tue, 25 Feb 2020 at 22:59, Daniel Beck  wrote:
>>
>>>
>>>
>>> > On 25. Feb 2020, at 16:44, Oleg Nenashev 
>>> wrote:
>>> >
>>> > There is also  https://issues.jenkins-ci.org/browse/JENKINS-60409
>>> which needs to be investigated for the new LTS candidate. Looks like the
>>> default Jetty behavior changed, and it may impact some users when they
>>> upgrade to the new baseline
>>>
>>> Irrelevant for this thread, as that issue affects every weekly release
>>> newer than the current LTS baseline. Might need upgrade docs or an
>>> expedited fix + back port but that applies to every potential LTS baseline
>>> choice.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/7E8CB82D-2A1F-4A02-B42A-2AE0920CD822%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/CAH-3BieKEt0Jv3RZb19yWmBZNTbyr%2Bmf%2BAmjP1SxeO3XdEvGfA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieKEt0Jv3RZb19yWmBZNTbyr%2Bmf%2BAmjP1SxeO3XdEvGfA%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/CAPyTVp0kF6zx%2BpmR9LCN7XS8iTfi6aS86TGDR3j%3DZMXfRSHzTg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPyTVp0kF6zx%2BpmR9LCN7XS8iTfi6aS86TGDR3j%3DZMXfRSHzTg%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-3Bic5ROtC5em5oNQTJYrT4w6BhkZbf2RueUHE-7CyE%2BPLHQ%40mail.gmail.com.

Re: Support List on jenkins.io?

[Tim Jacomb]

Why not setup required reviews?
There can be a small group of people who can bypass if necessary but most
people will need review

On Thu, 23 Jan 2020 at 11:12, Oleg Nenashev  wrote:

> Code Owners does not prevent merges by other contributors with Write
> permissions. We could combine CODEOWNERS with required reviews
> <https://help.github.com/en/github/administering-a-repository/enabling-required-reviews-for-pull-requests>,
> but it will apply to the entire Jenkins repository.
> I am not sure this is what we want, but happy to discuss it. Setting up
> permissions on the repo level is easier that wrangling with a new repo and
> the delivery pipeline patches
>
>
> On Thu, Jan 23, 2020 at 12:07 PM Tim Jacomb  wrote:
>
>> Is there a problem with using code owners for those files?
>>
>> On Thu, 23 Jan 2020 at 11:05, Oleg Nenashev 
>> wrote:
>>
>>> Hi all,
>>>
>>> Thanks to everyone involved in this discussion. I would also like to
>>> move the page and to improve its look Moving the Commercial
>>> Support <https://wiki.jenkins.io/display/JENKINS/Commercial+Support>
>>> and Approved Trademark Usage
>>> <https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage>
>>> pages is in my backlog for Wiki migration. This pages are not easy to
>>> migrate IMO, because jenkins.io grants a wide access for managing these
>>> pages (Copy Editors, SIG leaders, GSoC team, etc.). Such access is supposed
>>> to be restricted IMO, especially for the trademarks page. Access in Wiki
>>> was also restricted at some point.
>>>
>>> My plan for these pages is/was to...
>>>
>>>- Create a new public repository within Jenkins Infra for the
>>>sensitive content. Write permissions will be restricted to the Jenkins
>>>Infra team and to the Jenkins Board
>>>- Repository will include sensitive content, including Commercial
>>>Support, Trademarks, and maybe Governance docs in the future (once under
>>>https://jenkins.io/project/).
>>>- For Commercial Support and Approved Trademarks we will use
>>>separate Asciidoc pages for each entry.
>>>- jenkins.io builder will pull this resource and include pages into
>>>jenkins.io, similar to how it happens with currently generated
>>>content
>>>
>>> Would appreciate feedback about such process.
>>>
>>> P.S: I will make sure to create a JIRA entry for it if someone wants to
>>> contribute
>>>
>>>
>>> On Thursday, January 23, 2020 at 6:22:29 AM UTC+1, Marky Jackson wrote:
>>>>
>>>> I like the idea of waiting for the advocacy meeting but that doesn’t
>>>> mean we can’t get started on a WIP pr
>>>>
>>>> > On Jan 22, 2020, at 9:21 PM, 'Gavin Mogan' via Jenkins Developers <
>>>> jenkin...@googlegroups.com> 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/6cc34bcb-d4b6-4f5a-a293-8c8b6f03356e%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/6cc34bcb-d4b6-4f5a-a293-8c8b6f03356e%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>>
> 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/vjLgQtpz06Y/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/CAH-3BidZWKWSGL3xAbuGhkHtp02JjvFE0ze9SLag5dNuEgZ-OA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidZWKWSGL3xAbuGhkHtp02JjvFE0ze9SLag5dNuEgZ-OA%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/CAPfivLB_059-YyxN%3DP-RNPm48euCLYk61oUJDv_aMAyOkcuyMw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLB_059-YyxN%3DP-RNPm48euCLYk61oUJDv_aMAyOkcuyMw%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-3Bifo%2BRub_7DSzO5-DtXUMAuCkpEbFDQnuFL9Gv4-kj-f9g%40mail.gmail.com.

Re: Support List on jenkins.io?

[Tim Jacomb]

Is there a problem with using code owners for those files?

On Thu, 23 Jan 2020 at 11:05, Oleg Nenashev  wrote:

> Hi all,
>
> Thanks to everyone involved in this discussion. I would also like to move
> the page and to improve its look Moving the Commercial Support
>  and Approved
> Trademark Usage
>  pages
> is in my backlog for Wiki migration. This pages are not easy to migrate
> IMO, because jenkins.io grants a wide access for managing these pages
> (Copy Editors, SIG leaders, GSoC team, etc.). Such access is supposed to be
> restricted IMO, especially for the trademarks page. Access in Wiki was also
> restricted at some point.
>
> My plan for these pages is/was to...
>
>- Create a new public repository within Jenkins Infra for the
>sensitive content. Write permissions will be restricted to the Jenkins
>Infra team and to the Jenkins Board
>- Repository will include sensitive content, including Commercial
>Support, Trademarks, and maybe Governance docs in the future (once under
>https://jenkins.io/project/).
>- For Commercial Support and Approved Trademarks we will use separate
>Asciidoc pages for each entry.
>- jenkins.io builder will pull this resource and include pages into
>jenkins.io, similar to how it happens with currently generated content
>
> Would appreciate feedback about such process.
>
> P.S: I will make sure to create a JIRA entry for it if someone wants to
> contribute
>
>
> On Thursday, January 23, 2020 at 6:22:29 AM UTC+1, Marky Jackson wrote:
>>
>> I like the idea of waiting for the advocacy meeting but that doesn’t mean
>> we can’t get started on a WIP pr
>>
>> > On Jan 22, 2020, at 9:21 PM, 'Gavin Mogan' via Jenkins Developers <
>> jenkin...@googlegroups.com> 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/6cc34bcb-d4b6-4f5a-a293-8c8b6f03356e%40googlegroups.com
> 
> .
>

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

Re: Proposal: Automatically requesting code reviews from plugin developer teams (CODEOWNERS)

[Tim Jacomb]

> The default for a team is "secret" which means members are not visible to
anyone, the only other option available is "closed" which means the members
are visible only to members of the organization, not the general public. I
think since it is not exposed to the general public that this should be ok?

This is implemented here:
https://github.com/jenkins-infra/ircbot/pull/75

I've also implemented support to make transition easier, allow switching a
secret team to closed and allow upgrading permissions to maintainer of the
team,


   1. New teams created will be 'visible' (org members can see them and
   they show up in the reviewers list if CODEOWNERS are used)
   2. The first user in the HOSTING request will be made a 'Maintainer' of
   the GH team
   3. Adds a new command for making a secret team visible
   4. Adds a command to add a user as a maintainer of a team

Any feedback welcomed here or in the PR

Thanks
Tim


On Mon, 13 Jan 2020 at 13:24, Slide  wrote:

> The default for a team is "secret" which means members are not visible to
> anyone, the only other option available is "closed" which means the members
> are visible only to members of the organization, not the general public. I
> think since it is not exposed to the general public that this should be ok?
>
> On Mon, Jan 13, 2020 at 6:00 AM Marky Jackson 
> wrote:
>
>> But the teams are not, and that could expose individuals without their
>> consent.
>>
>> On Jan 13, 2020, at 4:58 AM, Tim Jacomb  wrote:
>>
>> 
>> The list of maintainers is already public in the repository permissions
>> list,
>>
>> +1 for changing this
>>
>> I assume the API call needs to be updated slightly in the IRC bot
>>
>> Thanks
>> Tim
>>
>> On Mon, 13 Jan 2020 at 12:46, Marky Jackson 
>> wrote:
>>
>>> Oleg,
>>> I feel that need some form of consent from maintainers.
>>>
>>> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev 
>>> wrote:
>>>
>>> 
>>>
>>> One thing here is that the most of the *pluginId-developers* teams are
>>> secret at the moment, and the teams must be public to operate properly with
>>> CODEOWNERS.
>>> I suggest to make all of them public, IMHO there is no value in hiding
>>> teams in the open-source project (apart form unintended mention prevention).
>>> I will add it to the next governance meeting, but I would appreciate the
>>> feedback
>>>
>>>
>>>
>>> On Fri, Jan 10, 2020 at 12:31 PM Oleg Nenashev 
>>> wrote:
>>>
>>>> I'd guess any plugin maintainer can just proceed and add CODEOWNERS to
>>>> the repo.
>>>> There is no need to wait for the bot if you want to start adopting the
>>>> suggestion :)
>>>>
>>>> On Thursday, January 9, 2020 at 7:07:08 PM UTC+1, Gavin Mogan wrote:
>>>>>
>>>>> Sweet I was going to suggest the same thing..
>>>>>
>>>>> Lots of plugin maintainers don't realize they are not "watching" a
>>>>> repo. and I think tools like pr bot don't count you unless your listed as 
>>>>> a
>>>>> reviewer
>>>>>
>>>>> So much +1 for me
>>>>>
>>>>> On Thu., Jan. 9, 2020, 6:29 a.m. Oleg Nenashev, 
>>>>> wrote:
>>>>>
>>>>>> Perfect, this makes the barrier to acceptance quite low,
>>>>>>> without forcing a change on anyone.
>>>>>>>
>>>>>> Yes, I do not think we are in position to enforce the process at the
>>>>>> moment. Historically Jenkins project gives a lot of freedom to plugin
>>>>>> maintainers to define how they operate, and IMHO it is a part of the
>>>>>> project's culture. IMHO we should rather lead by example there and help 
>>>>>> by
>>>>>> providing tools and solutions simplifying the work and removing routine.
>>>>>>
>>>>>> On Thursday, January 9, 2020 at 3:04:51 PM UTC+1, Jesse Glick wrote:
>>>>>>>
>>>>>>> On Thu, Jan 9, 2020 at 8:05 AM Oleg Nenashev 
>>>>>>> wrote:
>>>>>>> > We add CODEOWNERS template to plugin archetypes
>>>>>>>
>>>>>>> Yes, though we need to do JENKINS-58557 first.
>>>>>>>
>>>>>>> > We submit pull requests […]
>>>>>>> > Each plugin maintainer or maintainer team will decide on their own
&

Re: What is the best approach for mutually exclusive permissions - re: proposed Jenkins.CONFIGURE and Jenkins.SYSTEM_READ permissions

[Tim Jacomb]

Perfect thanks Michael

On Mon, 27 Jan 2020 at 15:21, Michael Cirioli 
wrote:

> Tim,
>
> I've added a section to our proposed JEP-223
> <https://github.com/jenkinsci/jep/tree/master/jep/224> committing to work
> with you on the Jenkins.SYSTEM_READ effort so that we can find a way to
> provide both of these features to the user in a way that makes sense and
> provides a non-confusing experience.
>
> thanks
> -mike
>
>
>
> On Thursday, January 23, 2020 at 2:57:00 PM UTC-5, Tim Jacomb wrote:
>>
>>
>>
>> (replies inline)
>>
>>
>>
>> On Wed, 22 Jan 2020 at 01:24, Michael Cirioli 
>> wrote:
>>
>>> (moving this discussion from https://github.com/jenkinsci/jep/pull/261
>>> in order to have more visibility)
>>>
>>>- Both proposals expect plugins to override getRequiredPermission()
>>>in order to determine what should be shown to a user.  The intention of
>>>JEP- is that _most_ items would be shown (read-only) to a user,   
>>> This
>>>will potentially create a conflict with JEP-223, as a user may be shown
>>>things that can be changed by a user with Jenkins.CONFIGURE, but the
>>>changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
>>>- If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ,
>>>should they be able to view some things they can't configure, and being
>>>able to change some things that a user who only has Jenkins.SYSTEM_READ
>>>would normally only be able to view?
>>>
>>> I don't currently have a proposal on how to best address this, but I do
>>> have some ideas
>>>
>>>- Provide a mean for permissions to specify precedence (ie.
>>>CONFIGURE is less restrictive than SYSTEM_READ).  This is different than
>>>the current *implies(...)* because an administrator may not want a
>>>user with the CONFIGURE permission to automatically also have SYSTEM_READ
>>>
>>> I think that configure should just be above system read, but I don't
>> know how that would affect the UX of CONFIGURE
>>
>>>
>>>- Add logic to the matrix-auth plugin such that some permission
>>>types are mutually exclusive.  ie. if you grant CONFIGURE, you can't also
>>>grant SYSTEM_READ.
>>>
>>> Hopefully unneeded
>>
>>>
>>>- Allow getRequiredPermission() to return a list of permissions, and
>>>tailor the user experience for any given plugin with custom logic.  This
>>>may be more error prone to maintain, and would need to be well thought 
>>> out
>>>enough so that any plugins that are unaware of the new permissions behave
>>>in a predictable way.
>>>
>>> Another thought I had was updating the jelly tags to allow to take an
>> array, and add a method called 'hasAnyPermission', which would at least
>> solve the view part
>>
>>> Although the above thoughts are focused on the two new permissions
>>> currently being proposed, an ideal solution should support any additional
>>> permissions that may find their way into Jenkins in the future.
>>>
>>> --
>>> You received this message because you 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/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>
>>
>> On Wed, 22 Jan 2020 at 15:28, Jesse Glick  wrote:
>>
> On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli 
>>> wrote:
>>> > Consider the case where a user has both Jenkins.CONFIGURE and
>>> Jenkins.SYSTEM_READ - what would the expected experience be?
>>> >
>>> > ..a user may be shown things that can be changed by a user with
>>> Jenkins.CONFIGURE, but the changes may not be persisted because of the
>>> Jenkins.SYSTEM_READ changes.
>>>
>>> If you split parts of the `/configure` page into an `/administer`
>>> page, rather than conditionally hiding them, then I think this could
>>> be solved in a different way that feels more in line with existing
>>> patterns:
>>>
>>
>> I

Re: What is the best approach for mutually exclusive permissions - re: proposed Jenkins.CONFIGURE and Jenkins.SYSTEM_READ permissions

[Tim Jacomb]

An update on system read,

Wadeck and I took a look at making the UI look read only, rather than just
removing the apply buttons, and we got it working.

Screenshots are in the PR description:
https://github.com/jenkinsci/jenkins/pull/4149

Please take a look and provide any feedback you have

Thank
Tim



On Mon, 27 Jan 2020 at 17:48, Tim Jacomb  wrote:

> Perfect thanks Michael
>
> On Mon, 27 Jan 2020 at 15:21, Michael Cirioli 
> wrote:
>
>> Tim,
>>
>> I've added a section to our proposed JEP-223
>> <https://github.com/jenkinsci/jep/tree/master/jep/224> committing to
>> work with you on the Jenkins.SYSTEM_READ effort so that we can find a way
>> to provide both of these features to the user in a way that makes sense and
>> provides a non-confusing experience.
>>
>> thanks
>> -mike
>>
>>
>>
>> On Thursday, January 23, 2020 at 2:57:00 PM UTC-5, Tim Jacomb wrote:
>>>
>>>
>>>
>>> (replies inline)
>>>
>>>
>>>
>>> On Wed, 22 Jan 2020 at 01:24, Michael Cirioli 
>>> wrote:
>>>
>>>> (moving this discussion from https://github.com/jenkinsci/jep/pull/261
>>>> in order to have more visibility)
>>>>
>>>>- Both proposals expect plugins to override getRequiredPermission()
>>>>in order to determine what should be shown to a user.  The intention of
>>>>JEP- is that _most_ items would be shown (read-only) to a user,   
>>>> This
>>>>will potentially create a conflict with JEP-223, as a user may be shown
>>>>things that can be changed by a user with Jenkins.CONFIGURE, but the
>>>>changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
>>>>- If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ,
>>>>should they be able to view some things they can't configure, and being
>>>>able to change some things that a user who only has Jenkins.SYSTEM_READ
>>>>would normally only be able to view?
>>>>
>>>> I don't currently have a proposal on how to best address this, but I do
>>>> have some ideas
>>>>
>>>>- Provide a mean for permissions to specify precedence (ie.
>>>>CONFIGURE is less restrictive than SYSTEM_READ).  This is different than
>>>>the current *implies(...)* because an administrator may not want a
>>>>user with the CONFIGURE permission to automatically also have 
>>>> SYSTEM_READ
>>>>
>>>> I think that configure should just be above system read, but I don't
>>> know how that would affect the UX of CONFIGURE
>>>
>>>>
>>>>- Add logic to the matrix-auth plugin such that some permission
>>>>types are mutually exclusive.  ie. if you grant CONFIGURE, you can't 
>>>> also
>>>>grant SYSTEM_READ.
>>>>
>>>> Hopefully unneeded
>>>
>>>>
>>>>- Allow getRequiredPermission() to return a list of permissions,
>>>>and tailor the user experience for any given plugin with custom logic.
>>>>This may be more error prone to maintain, and would need to be well 
>>>> thought
>>>>out enough so that any plugins that are unaware of the new permissions
>>>>behave in a predictable way.
>>>>
>>>> Another thought I had was updating the jelly tags to allow to take an
>>> array, and add a method called 'hasAnyPermission', which would at least
>>> solve the view part
>>>
>>>> Although the above thoughts are focused on the two new permissions
>>>> currently being proposed, an ideal solution should support any additional
>>>> permissions that may find their way into Jenkins in the future.
>>>>
>>>> --
>>>> You received this message because you 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/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>
>>>
>>> On Wed, 22 Jan 2020 at 15:28, Jesse Glick  wrote:
>>>
>> On

JEP-13: timja youtube permissions for JCasc

[Tim Jacomb]

Hi

As a sub-project leader for JCasc I'm requesting permission to upload
videos to the jenkinsci youtube channel for JCasC sub-project meetings

https://github.com/jenkinsci/jep/blob/master/jep/13/README.adoc#eligibility

I have a signed ICLA:
https://github.com/jenkinsci/infra-cla/tree/master/collected/icla/timja
and my google account has 2fa on it

Thanks
Tim

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

GitHub issues option in HOSTING

[Tim Jacomb]

Hi

GitHub issues use is growing in the ecosystem, many plugins are now using
it,

Some benefits from my experience in using it:

   -

   Easy subscription to issues / pull requests for repositories I maintain
   / co-maintain
   -

   Much easier to be a co-maintainer, with JIRA only the ‘component lead’
   gets notified by default, you _can_ create your own filters and
   subscriptions, but it’s a lot more effort and most people (including me)
   don’t do that.
   -

   Tight integration with SCM, issues are closed when a pull request is
   merged, and you can click on a commit to see what version it was released
   in, JIRA on the other hand is very out of sync.


Some repositories that are using them:

https://github.com/jenkinsci/configuration-as-code-plugin,
https://github.com/jenkinsci/slack-plugin,

https://github.com/jenkinsci/google-compute-engine-plugin

And many more...

I’ve heard that this was raised a year ago or so, and there were two
reasons that it wasn’t adopted:

   -

   Delete issues support - for security fixes, GitHub now supports this
   -

   Transferring issues - now supported, but I think you need write access,
   may need a bot to ease this, but we can see how this goes.
   -

   Cross repository / component work - There’s now organisation level
   projects that can be used to group and track issues across projects
   https://github.com/orgs/jenkinsci/projects/3 (Plugin docs),
   https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins
   Configuration-as-Code developer tools), this doesn’t solve the issue of a
   bug in multiple components, there’s a few ways this could be solved, one
   issue for tracking it, tagging the maintainers teams in the issue,
   reporting it multiple times and linking the issues together (possibly the
   best option?).


I think it makes sense to offer an option during the hosting process on
which issue tracker the maintainer wants to use.

Currently maintainers are able to enable GitHub issues themselves after the
repo is hosted but that leaves them with a JIRA component that users who
are used to Jenkins JIRA might report issues into.

I would also suggest that we add some text to the Component field that says:

‘Many components use GitHub issues now, if you can’t find the component
create an issue on component’s GitHub repository.

Any feedback or questions?

Thanks

Tim

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

Re: How to create a private repo under github.com/jenkinsci?

[Tim Jacomb]

It’s not possible to have a private repo, the plan that jenkinsci is on
only supports public repos

On Mon, 3 Feb 2020 at 08:00, 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Why do you need it to be private? If it's for your own development, do it
> in your own GitHub/org and then request hosting when it's working.
>
> All plugins hosted in the main update center have to be public and open
> source.
>
> I don't know if there's official  but you can review
> https://jenkins.io/doc/developer/publishing/requesting-hosting/
>
> Gavin
>
> On Sun., Feb. 2, 2020, 11:56 p.m. Shihaaz Buhary, 
> wrote:
>
>> Apologies for my wording. :)
>> When we request for hosting through "HOSTING" Jira ticket, can we also
>> request to make it as private under https://github.com/jenkinsci
>> 
>>  until
>> we request to make it as public? If so, what is the process?
>>
>> On Monday, February 3, 2020 at 12:59:24 PM UTC+5:30, Gavin Mogan wrote:
>>>
>>> You shouldn't be creating any repos under the org. They should go
>>> through infra or hosting jira tickets.
>>>
>>> Why do you need to create a repo?
>>>
>>> On Sun., Feb. 2, 2020, 11:25 p.m. Shihaaz Buhary, 
>>> wrote:
>>>
 Hi All,

 Is there a way that we can create a private repository under
 https://github.com/jenkinsci
 
  and
 then later make it public? Or we can only create public repos?

 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/f4ae6b20-75ec-4977-8b9f-c4fade479816%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/143f20b1-9d7b-4d60-9e0f-18cdbccaecc7%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/CAG%3D_DuufBgm4LfY3K91F-5m6y%3D3bgd0E5Gn1t_XEOys4sHk9sw%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-3BicAC4_bAPpfHx1h3kqgRZZijAKPA94S_OHBa1Dx5XfPzg%40mail.gmail.com.

Re: Adopt a plugin request

[Tim Jacomb]

It’s you jenkins jira / artifactory account

On Thu, 30 Jan 2020 at 17:41, Terry Moreland 
wrote:

> Just getting around to this now, and want to confirm the username in the
> yaml file under permissions, that should be the Jenkins-ci username or
> github one?
>
> Just want to be clear because there is a github account with the same name
> as my jenkins-ci one that isn't mine
>
>
> On Fri, 17 Jan 2020, 9:21 pm Oleg Nenashev, 
> wrote:
>
>> Hi Terry,
>>
>> I granted you access to the repository inside the jenkinsci GitHub
>> organization: https://github.com/jenkinsci/appspider-build-scanner-plugin
>> This repository was hosted by the previous maintainer, and we consider it
>> as a main repository for the plugin (though fork history suggests
>> otherwise).
>> Jenkins org admins have no access to the original repo you referenced (
>> https://github.com/rapid7/jenkinsci-appspider-plugin), and you will need
>> to figure the access to this repo with your company if needed.
>> Please make sure that the releases are performed to
>> https://github.com/jenkinsci/appspider-build-scanner-plugin (this repos
>> should be an origin).
>>
>> In order to get release permissions, please submit a pull request to
>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-jenkinsci-appspider-plugin.yml
>>
>> Best regards,
>> Oleg Nenashev
>>
>>
>> On Thursday, January 16, 2020 at 10:22:27 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> Sorry, did not get to it. Will try to do the transfer tomorrow
>>>
>>> On Thu, Jan 16, 2020, 15:05 Oleg Nenashev 
>>> wrote:
>>>
 Thanks for the ping!
 I will do the permission transfer today

 On Thursday, January 16, 2020 at 2:59:25 PM UTC+1, Terry Moreland wrote:
>
> Just posting a follow up on this request, it's now been over 2 weeks
> (with some extra padding to accommodate the holiday period), As there is 
> no
> e-mail for the original maintainers account I've been unable to e-mail but
> have mentioned @nbugash in 3 comments on the pull request to this
> repository none of which have received any response.  I also attempted to
> reach out via Linked-In profile but again no response.
>
> For reference this is for:
> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
> pull request:
> https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
> github id: tsmoreland
> jenkins id: tmoreland
>
>
> On Friday, 20 December 2019 09:15:41 UTC, Terry Moreland wrote:
>>
>> I've also added a comment to the current pull request pinging his
>> personal github account which is the one he associated with the plugin.  
>> As
>> of yet no reply either there or via linked in
>
> --
 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/c2nWqrqzrNg/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/674d4170-efef-4fda-a415-9466c2ffb224%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/1fabd105-62d4-4528-84b6-5ba598236b29%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/CAM5UBjdXgvd%2BucMrAXSNB5R6aGFzRBtPYUjG_%3DCSsnwb%3DQmc6A%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: Remove network discovery services

[Tim Jacomb]

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

On Thu, 30 Jan 2020 at 19:50, Slide  wrote:

> I'm +1 on this, reducing the attack footprint for core is a good idea.
>
> On Thu, Jan 30, 2020 at 11:41 AM Jeff Thompson 
> wrote:
>
>> On 1/30/20 11:25 AM, Jesse Glick wrote:
>>
>> On Thu, Jan 30, 2020 at 11:47 AM Jeff Thompson  
>>  wrote:
>>
>> the capabilities could be pulled out of core into a plugin
>>
>> That was the longstanding proposal in JENKINS-33596.
>>
>> I think it's time to act on it.
>>
>> The key to implementing it in a plugin is to have someone who relies on
>> it maintain it. If swarm uses it maybe someone involved with that could
>> take it on. I'd be willing to help get things going with that, but not to
>> maintain it. If nobody is interested enough for that, we should kill it off.
>>
>> Jeff
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/e8f4603d-a953-10f8-0eb0-8cada6eaae36%40cloudbees.com
>> 
>> .
>>
>
>
> --
> 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/CAPiUgVc5Rijvp9OnktyfAsG8M2SrrMO0UwUR%2BTHwBm97pYCBaA%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-3BifRQoyW2ECh1b4dV4axLtW6PzoK2WAJGOWJ%2BLE-3VcmVA%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Tim Jacomb]

ng peaces from your requirements get integrated into Jira:
>
>
>- Easy subscription to issues / pull requests for repositories I
>maintain / co-maintain
>
>
> This is quite easy in Jira as well.
>
>
>- Much easier to be a co-maintainer, with JIRA only the ‘component
>lead’ gets notified by default, you _can_ create your own filters and
>subscriptions, but it’s a lot more effort and most people (including me)
>don’t do that.
>
>
> I think I don’t get the point here, maybe you need to clarify why Jira is
> here more complex
>
>
>- Tight integration with SCM, issues are closed when a pull request is
>merged, and you can click on a commit to see what version it was released
>in, JIRA on the other hand is very out of sync.
>
>
> We had that in Jira as well. The service was located on Kohsuke’s server
> is now not running anymore. I think it would be awesome if we could restore
> that integration. Maybe we can use the existing Jira Jenkins plugin for
> that task.
>
> Am 02.02.2020 um 12:13 schrieb Tim Jacomb :
>
> Hi
>
> GitHub issues use is growing in the ecosystem, many plugins are now using
> it,
>
> Some benefits from my experience in using it:
>
>- Easy subscription to issues / pull requests for repositories I
>maintain / co-maintain
>- Much easier to be a co-maintainer, with JIRA only the ‘component
>lead’ gets notified by default, you _can_ create your own filters and
>subscriptions, but it’s a lot more effort and most people (including me)
>don’t do that.
>- Tight integration with SCM, issues are closed when a pull request is
>merged, and you can click on a commit to see what version it was released
>in, JIRA on the other hand is very out of sync.
>
>
> Some repositories that are using them:
> https://github.com/jenkinsci/configuration-as-code-plugin,
> https://github.com/jenkinsci/slack-plugin,
> https://github.com/jenkinsci/google-compute-engine-plugin
> And many more...
>
> I’ve heard that this was raised a year ago or so, and there were two
> reasons that it wasn’t adopted:
>
>- Delete issues support - for security fixes, GitHub now supports this
>- Transferring issues - now supported, but I think you need write
>access, may need a bot to ease this, but we can see how this goes.
>- Cross repository / component work - There’s now organisation level
>projects that can be used to group and track issues across projects
>https://github.com/orgs/jenkinsci/projects/3 (Plugin docs),
>https://github.com/orgs/jenkinsci/projects/1  (Community Bridge:
>Jenkins Configuration-as-Code developer tools), this doesn’t solve the
>issue of a bug in multiple components, there’s a few ways this could be
>solved, one issue for tracking it, tagging the maintainers teams in the
>issue, reporting it multiple times and linking the issues together
>(possibly the best option?).
>
>
> I think it makes sense to offer an option during the hosting process on
> which issue tracker the maintainer wants to use.
>
> Currently maintainers are able to enable GitHub issues themselves after
> the repo is hosted but that leaves them with a JIRA component that users
> who are used to Jenkins JIRA might report issues into.
>
> I would also suggest that we add some text to the Component field that
> says:
> ‘Many components use GitHub issues now, if you can’t find the component
> create an issue on component’s GitHub repository.
>
> Any feedback or questions?
>
> Thanks
> Tim
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%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/7f2ffee6-9a49-475f-afa8-e09628527d0f%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/7f2ffee6-9a49-475f-afa8-e09628527d0f%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> --
> Yo

Re: Wiki redirects, wiki exporter, and plugin changelogs

[Tim Jacomb]

If anyone wants to help out there’s a progress page here:

https://jenkins-wiki-exporter.jenkins.io/progress

Pick one that isn’t in progress,
Use the wiki exporter to get all content and images,
Do a bit of cleanup
Open a pull request
Add your pull request to the GitHub project tracking it (
https://github.com/orgs/jenkinsci/projects/3), I think any org member can
do it, and if you can’t do it then ask in the gitter channel
https://gitter.im/jenkinsci/docs

The progress page is automatically updated based on the GitHub project

Thanks
Tim

On Fri, 7 Feb 2020 at 14:12, Olblak  wrote:

> Indeed congrats to everybody, this sub-project is a beautiful example of
> contributing to an OSS project is not only about write code for the
> application itself but also improving its ecosystem through collaboration.
>
> ---
> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
>
>
> On Fri, Feb 7, 2020, at 2:56 PM, Mark Waite wrote:
>
> Gavin Mogan has made significant improvements to
> https://plugins.jenkins.io/ .  It loads faster, works better, and is
> easier to maintain.  Thanks Gavin!
>
> As part of those improvements, plugin pages on the Jenkins wiki are now
> automatically redirected to https://plugins.jenkins.io/ .  For example,
> the wiki page that would previously have opened for
> https://wiki.jenkins.io/display/JENKINS/Git+Plugin now redirects to
> https://plugins.jenkins.io/git .  The new page loads much faster and is
> more easily and reliably maintained in the plugin repository.
>
> Only plugin pages on the wiki are automatically redirected.  Other pages
> on the Jenkins wiki are not automatically redirected.  As we move
> documentation from the wiki to https://jenkins.io/doc/, more wiki pages
> will be redirected.
>
> Because the Jenkins wiki is read only, plugin maintainers will need to
> move their documentation the next time they update it.  Plugin
> documentation preferences are:
>
>- Migrate documentation from wiki to GitHub as described in Oleg
>Nenashev's blog post
><https://jenkins.io/blog/2019/10/21/plugin-docs-on-github/> and
>demonstrated in the Nov 22, 2019 developer meetup
><https://www.youtube.com/watch?v=PaQsvli92XY>
>- Migrate changelog creation from manual edits of the wiki to
>automated GitHub release drafter as described in the online
>documentation
>
> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>and demonstrated in the online meetup
>
> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc#jenkins-online-meetup-recording>
>- Migrate historical changelogs from wiki to GitHub CHANGELOG file
>using the wiki exporter <https://jenkins-wiki-exporter.jenkins.io/>
>
> Plugins that have not migrated their documentation from the wiki to GitHub
> will continue to show that documentation on https://plugins.jenkins.io/
> .  Wiki based documentation can't be edited due to the spam problems which
> forced us to make the Wiki read-only.
>
> Plugin developers that aren't ready to transition to automatic changelogs
> could migrate their changelog from wiki to GitHub CHANGELOG.md file using
> wiki exporter and continue to maintain the changelog manually.
>
> Deepest and most sincere thanks to Gavin Mogan for his excellent work on
> the transition of plugin documentation from Wiki to GitHub!  Thanks also to
> Tim Jacomb, Oleg Nenashev, and many others for their efforts to make the
> transition successful.  Over 250 plugin repositories have already completed
> the transition from Wiki documentation to maintaining their documentation
> in GitHub.
>
> Mark Waite
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/d5db809a-e912-452d-93f8-162d8584001f%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/d5db809a-e912-452d-93f8-162d8584001f%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/678e79c3-b7e2-4eaf-9a6d-52284ac7e30b%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/678e79c3-b7e2-4eaf-9a6d-52284ac7e30b%40www.fastmai

Re: GitHub issues option in HOSTING

[Tim Jacomb]

(replies inline)
On Sat, 8 Feb 2020 at 12:13, Daniel Beck  wrote:

>
> On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> I also really want to see issues.jenkins go away, but mostly due to how
>> slow it is. I don't think cloud is a lot better, but way less maintenance
>> for people.
>>
>
> When was the last time our Jira instance had performance/availability
> problems? I don't think there have been any problems so far this year, and
> probably not to a notable degree in the last few months of last year...
>
>
 Now?
[image: image.png]
It takes me 9 seconds to open JIRA for it to be interactive.
And then I have to log in every single time...

Compared to GitHub issues which is:
[image: image.png]
~3 seconds to be fully done, but I can interact with the page after 2
seconds.
And I'm already logged in so I don't need to spend another 15 seconds
logging in.

I've definitely clicked to open a JIRA issue before and then not distracted
while it was loading...

Thanks
Tim

-- 
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLqd%3DLAjBGwxPP5%2BdkTp%2Bof1L0AUetZ5HdLj6Cu%2BZZ86w%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-3BidGCCf%3DvSNUqfVhG_3ZBqQykJZ5h%3DYpDHLnm2BsND9%2Bpg%40mail.gmail.com.

Re: What is the best approach for mutually exclusive permissions - re: proposed Jenkins.CONFIGURE and Jenkins.SYSTEM_READ permissions

[Tim Jacomb]

(replies inline)



On Wed, 22 Jan 2020 at 01:24, Michael Cirioli 
wrote:

> (moving this discussion from https://github.com/jenkinsci/jep/pull/261 in
> order to have more visibility)
>
>- Both proposals expect plugins to override getRequiredPermission() in
>order to determine what should be shown to a user.  The intention of
>JEP- is that _most_ items would be shown (read-only) to a user,   This
>will potentially create a conflict with JEP-223, as a user may be shown
>things that can be changed by a user with Jenkins.CONFIGURE, but the
>changes may not be persisted because of the Jenkins.SYSTEM_READ changes.
>- If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ, should
>they be able to view some things they can't configure, and being able to
>change some things that a user who only has Jenkins.SYSTEM_READ would
>normally only be able to view?
>
> I don't currently have a proposal on how to best address this, but I do
> have some ideas
>
>- Provide a mean for permissions to specify precedence (ie. CONFIGURE
>is less restrictive than SYSTEM_READ).  This is different than the current
>*implies(...)* because an administrator may not want a user with the
>CONFIGURE permission to automatically also have SYSTEM_READ
>
> I think that configure should just be above system read, but I don't know
how that would affect the UX of CONFIGURE

>
>- Add logic to the matrix-auth plugin such that some permission types
>are mutually exclusive.  ie. if you grant CONFIGURE, you can't also grant
>SYSTEM_READ.
>
> Hopefully unneeded

>
>- Allow getRequiredPermission() to return a list of permissions, and
>tailor the user experience for any given plugin with custom logic.  This
>may be more error prone to maintain, and would need to be well thought out
>enough so that any plugins that are unaware of the new permissions behave
>in a predictable way.
>
> Another thought I had was updating the jelly tags to allow to take an
array, and add a method called 'hasAnyPermission', which would at least
solve the view part

> Although the above thoughts are focused on the two new permissions
> currently being proposed, an ideal solution should support any additional
> permissions that may find their way into Jenkins in the future.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com
> 
> .


On Wed, 22 Jan 2020 at 15:28, Jesse Glick  wrote:

> On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli 
> wrote:
> > Consider the case where a user has both Jenkins.CONFIGURE and
> Jenkins.SYSTEM_READ - what would the expected experience be?
> >
> > ..a user may be shown things that can be changed by a user with
> Jenkins.CONFIGURE, but the changes may not be persisted because of the
> Jenkins.SYSTEM_READ changes.
>
> If you split parts of the `/configure` page into an `/administer`
> page, rather than conditionally hiding them, then I think this could
> be solved in a different way that feels more in line with existing
> patterns:
>

I'm not sure this would work well for read only support, what items on the
existing configure page would you not want to expose?

>
> · If you have `ADMINISTER`, `/administer` has a *Save* (and *Apply*)
> button. Else, if you have `SYSTEM_READ`, it does not. If you have
> neither, it cannot be displayed at all.
> · If you have `CONFIGURE`, `/configure` has *Save*. If you have
> `VIEW_CONFIGURATION` (at global scope?), it does not. If you have
> neither, it cannot be displayed at all.
>
> an ideal solution should support any additional permissions that may find
> their way into Jenkins in the future
>
> Do we really want to be adding complex new permission options? The
> Jenkins permission system is way too complex as it stands, making for
> a poor UX, and as for Jenkins developers, I at least can barely keep
> the intended behavior straight in my head. Many advanced use cases
> would be better handled via `configuration-as-code` plus other
> tooling, processes, or policies (GitHub’s `CODEOWNERS`, for example).
>
>
Absolutely agree with handling configuration via `configuration-as-code` or
other tools, but I do think we're missing a lot of information that is
useful to users
to either:
1. contribute to the plugins / configuration of their instance.
2. debug why their build has an issue
3. debug / solve an issue faster with why their agent isn't starting (cloud
logs, agent startup logs etc)

Just thinking of ci.jenkins.io if some of the information above 

Re: JIRA Sign Up Issues

[Tim Jacomb]

p.s. thanks to all involved,

Oleg, olblak, halkeye, tyler and daniel and anyone I missed :)

On Thu, 23 Jan 2020 at 20:24, Tim Jacomb  wrote:

> Hi David
>
> That should be fixed now (I was able to create an account after deploying
> the fix)
>
> Thanks
> Tim
>
> On Wed, 22 Jan 2020 at 16:35, Olblak  wrote:
>
>> Hi David,
>>
>> Thanks for reporting this, It seems the problem is not gone.
>> I give it another look
>>
>>
>> ---
>> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
>> ---
>>
>>
>> On Wed, Jan 22, 2020, at 3:53 PM, Marky Jackson wrote:
>>
>> Currently there is an issues being worked on with LDAP
>>
>> On Jan 22, 2020, at 1:33 AM, David Hodgkinson <
>> david.hodgkin...@outplay.com> wrote:
>>
>> Hi there,
>>
>> When attempting to sign up for an account here:
>> https://accounts.jenkins.io/signup in order to open a bug report with a
>> plugin I get the following error:
>>
>> HTTP ERROR 500
>>
>> Problem accessing /doSignup. Reason:
>>
>> Server Error
>>
>>
>> Caused by:
>>
>> javax.servlet.ServletException: javax.servlet.ServletException: 
>> javax.naming.NoPermissionException: [LDAP: error code 50 - no write access 
>> to parent]; remaining name 'cn=outplaydave,ou=people,dc=jenkins-ci,dc=org'
>>  at 
>> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
>>  at 
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>>  at org.eclipse.jetty.server.Server.handle(Server.java:503)
>>  at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>>  at 
>> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>>  at 
>> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>>  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>>  at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>>  at 
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>>  at 
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>>  at 
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>>  at 
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>>  at 
>> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>>  at 
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>>  at 
>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
>>  at java.lang.Thread.run(Thread.java:748)
>> Caused by: javax.servlet.ServletException: 
>> javax.naming.NoPermissionException: [LDAP: error code 50 - no write access 
>> to parent]; remaining name 'cn=outplaydave,ou=people,dc=jenkins-ci,dc=org'
>>  at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:784)
>>  at org.kohsuke.stapler.Stapler.invoke(Stapler.java:864)
>>  at org.kohsuke.stapler.Stapler.invoke(Stapler.java:668)
>>  at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
>>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>  at 
>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:857)
>>  at 
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1655)
>>  at 
>> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:215)
>>  at 
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
>>  at 
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>>  at 
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>>  at 
>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>>  at 
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>>  at 
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>>  at 
>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>>  at 
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>>  at 
>> org.eclipse.jetty.server.handler.ContextHan

Re: JIRA Sign Up Issues

[Tim Jacomb]

Hi David

That should be fixed now (I was able to create an account after deploying
the fix)

Thanks
Tim

On Wed, 22 Jan 2020 at 16:35, Olblak  wrote:

> Hi David,
>
> Thanks for reporting this, It seems the problem is not gone.
> I give it another look
>
>
> ---
> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
>
>
> On Wed, Jan 22, 2020, at 3:53 PM, Marky Jackson wrote:
>
> Currently there is an issues being worked on with LDAP
>
> On Jan 22, 2020, at 1:33 AM, David Hodgkinson <
> david.hodgkin...@outplay.com> wrote:
>
> Hi there,
>
> When attempting to sign up for an account here:
> https://accounts.jenkins.io/signup in order to open a bug report with a
> plugin I get the following error:
>
> HTTP ERROR 500
>
> Problem accessing /doSignup. Reason:
>
> Server Error
>
>
> Caused by:
>
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.naming.NoPermissionException: [LDAP: error code 50 - no write access to 
> parent]; remaining name 'cn=outplaydave,ou=people,dc=jenkins-ci,dc=org'
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at org.eclipse.jetty.server.Server.handle(Server.java:503)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>   at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.servlet.ServletException: 
> javax.naming.NoPermissionException: [LDAP: error code 50 - no write access to 
> parent]; remaining name 'cn=outplaydave,ou=people,dc=jenkins-ci,dc=org'
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:784)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:864)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:668)
>   at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:857)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1655)
>   at 
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:215)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   ... 15 more
> Caused by: 

Re: Any plans for the github checks API?

[Tim Jacomb]

+1  would be great,
I've done some ground laying work for it here:
https://github.com/jenkinsci/github-branch-source-plugin/pull/269

It requires a github-api-plugin version to be published with a recent ish
version of github-api

Thanks
Tim

On Mon, 27 Jan 2020 at 16:09, Raihaan Shouhell 
wrote:

> I think having a checks api would be great.
> Reports sending checks back to the change request would be a useful
> feature.
>
>
> On Monday, 27 January 2020 20:57:31 UTC+8, Oleg Nenashev wrote:
>>
>> Just to bump this thread, we consider adding Checks API integration as a
>> GSoC 2020 project idea.
>> We had a preliminary discussion with Ulli Hafner (Warnings NG) and other
>> parties.
>>
>> If someone is interested to join the project, please let me know
>>
>> On Thursday, May 10, 2018 at 5:56:28 PM UTC+2, Jesse Glick wrote:
>>>
>>> On Thu, May 10, 2018 at 5:37 AM, Steven F  wrote:
>>> > The examples in the article show elements such as linting,
>>> > build, static analysis as separate and individually runnable things.
>>> In
>>> > Jenkins 2.x Pipeline it feels like bundling these things together is
>>> more
>>> > encouraged.
>>>
>>> Well, it is generally more straightforward to have those things be run
>>> as part of a single Jenkins build, triggered by SCM changes. What is
>>> missing is an API which would allow Jenkins report plugins (`Publisher
>>> & SimpleBuildStep`, for example) to indicate to the system that there
>>> is some information to be displayed in an abstract “change request”,
>>> perhaps associated with source code lines, which would then be
>>> implemented by `github-branch-source` with the Checks API.
>>>
>>> jxpe...@godaddy.com wrote:
>>> > just rerunning the job from github would save a step
>>>
>>> See JENKINS-45455 for rerunning generally; again we would need a new
>>> API to allow this is to be integrated with in-PR “chatops” triggers,
>>> so that `github-branch-source` could receive GH events and refire them
>>> as requests to rerun parts of a build, which
>>> `pipeline-model-definition` would then interpret as a Declarative
>>> build trigger.
>>>
>>> All this would allow you to do more from GitHub and less from Blue
>>> Ocean or the Jenkins “classic” UI. @abayer has done the most work in
>>> this area and should probably be commenting.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/fa0449e3-53ec-42d2-a788-cad59557d4d2%40googlegroups.com
> 
> .
>

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

Re: Proposal: Moving the plugin adoption labels from Wiki to GitHub topics

[Tim Jacomb]

The badge could be automatically added on the plugin site if one of the
adopt topics is added to the GitHub repo?

On Tue, 18 Feb 2020 at 08:01, Ivan Fernandez Calvo 
wrote:

> Sure, the badge is something additional,
>  something that users can see when they go to the documentation, then they
> can decide
> if they want to use a plugin in adoption.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/7e802140-b00c-4ccc-adcf-c84be95ab610%40googlegroups.com
> .
>

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

Re: Proposal: Jenkins Core PR reviewers team

[Tim Jacomb]

+1 from my side

On Tue, 18 Feb 2020 at 08:10, Francisco Javier Fernandez <
fjfernan...@cloudbees.com> wrote:

> Oleg, Marky, +1 from my side. Any help is always more than welcome!
>
> El domingo, 16 de febrero de 2020, 19:59:06 (UTC+1), Marky Jackson
> escribió:
>>
>> Thank you kindly Oleg, please do get well. Sending healing thoughts.
>>
>> On Feb 16, 2020, at 10:30 AM, Oleg Nenashev  wrote:
>>
>> Hi Marky. As we discussed in PM, I have an action item to follow-up on
>> that. Sorry that I cannot provide the response time you expect, but I was
>> mostly off over past days (sick leave). I will do my best to propose formal
>> criteria for newcomer core PR reviewers next week. The informal criteria
>> before was several months of activities in the core and a number of
>> substantial contributions.
>>
>> If others vote in favor of adding Marky to the Core PR Reviewers, I am +1
>> w.r.t that.
>>
>> BR, Oleg
>>
>>
>>
>> On Sun, Feb 16, 2020, 19:10 Marky Jackson  wrote:
>>
>>> I wanted to circle back around on this
>>>
>>> On Thursday, February 13, 2020 at 4:48:44 PM UTC-8, Marky Jackson wrote:

 I am happy to be included and thank you Gavin

 On Feb 13, 2020, at 4:46 PM, 'Gavin Mogan' via Jenkins Developers <
 jenkin...@googlegroups.com> wrote:

 Sorry ya'll, with the new approved core developers, I'm going to step
 down as a core-pr-reviewer. Its a little overwhelming to me, and I'm not
 comfortable with core/java, but i'm still up for helping out randomly where
 i can, especially for plugins, and web/javascript stuff. I'll lurk randomly
 elsewhere.

 (this leaves room for Marky though)

 On Sun, Feb 2, 2020 at 1:04 AM Marky Jackson 
 wrote:

> I love a good challenge.
> Let’s hold off on this request and I will get some general reviews
> under my belt for some time and reapply at a later date.
> Thanks kindly for the consideration.
>
> On Feb 1, 2020, at 11:53 PM, Daniel Beck  wrote:
>
>
> Extrapolating from the introduction of this team would mean people
> should first be regular core PR reviewers. There's no process barrier to
> just start doing that.
>
> Right now,
> https://github.com/jenkinsci/jenkins/pulls?utf8=%E2%9C%93=is%3Apr+involves%3Amarkyjackson-taulia
> looks a little empty.
>
> --
> You received this message because you 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/CAMo7PtLNMKCiby_hamQ%2BpUBZyVZBzyTphw8LiTE1Y1xsbz9EOw%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkin...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/6001CF17-C6EB-4F86-ABF0-3754580C0BE3%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 jenkin...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusuUMUQuMqXYwbQ6vf%2BqaXgNzT9cg_5M9QYJzh7c%3DVbWg%40mail.gmail.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/0sdrcSOQW64/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/46d147a4-3f81-4eea-93ad-3a355329eb28%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 jenkin...@googlegroups.com.
>> To view 

Re: Looking for potential weekend hackathon ideas

[Tim Jacomb]

Might be interesting to see where you could get with the GitHub checks api?

Here’s the gsoc project proposal:
https://jenkins.io/projects/gsoc/2020/project-ideas/github-checks/


On Thu, 20 Feb 2020 at 17:03, Matt Sicker  wrote:

> Hi all,
>
> I'll be attending Hack Illinois [1], a weekend-long hackathon focused
> on contributing to open source projects. This hackathon is in about a
> week, so while this is somewhat late notice, I'm looking for any
> suggestions on bugs, features, and other work that might be
> appropriate for a university-level audience. The students will range
> in skill levels and experience, so I'd like to have a bag of issues or
> features that span the complexity spectrum.
>
> [1]: https://www.hackillinois.org/
>
> --
> 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/CAEot4owJZvpGfU-u32dX4AecJ-7w1%3DW%3DJAunPh0uMxrRADz-Jg%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-3BifDCQy59o%3DvxVLzx6zuuZvOm147a%3D%3DdbAZpsSoddDHbUw%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Tim Jacomb]

Who is going to update it? And what benefit does that bring?

And moving to the cloud version brings less features, a new account type
everyone has to sign up to, but less maintenance

On Mon, 10 Feb 2020 at 10:28, Ullrich Hafner 
wrote:

> Ok, then let us summarize the side track:
> We cannot and do not want to drop Jira because it is used in a lot of
> places and the features are superior to GitHub issues. We can improve
> performance and usability of Jira if we would deploy a more recent version
> of Jira (or use the cloud version).
>
> Then I am more then before -1 on opening support for GitHub issues, since
> our users should simply use only one tool to report issues for Jenkins and
> its plugins. (And for me as developer it makes cross-component issue
> handling also simpler if there is only one tool to use.)
>
> > Am 10.02.2020 um 10:15 schrieb Daniel Beck :
> >
> >
> >
> >> On 10. Feb 2020, at 10:08, Ullrich Hafner 
> wrote:
> >>
> >> What other services are using our LDAP?
> >
> > Account app (duh), Wiki (sort of going away very slowly), all our
> Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this is
> why you use your Jenkins user name in
> https://github.com/jenkins-infra/repository-permissions-updater/ )
> >
> > Could we exclude LDAP from this thread? It's already a mess, we went
> from "Wouldn't it be nice if we had better support for GH issues in the
> hosting process" to "Let's shut down Jira".
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/37A68695-188E-499A-A7AB-F9604673E4F4%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/630057BF-6723-41B8-8DD2-C3BED62176F4%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/CAH-3BiehijtntYhN3xqRj85%3Dw3M7BnEwHh%3DQXZ1fetXb8eX3yw%40mail.gmail.com.

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

[Tim Jacomb]

This used to be done for pipeline with the 'workflow-aggregator' plugin,
afaik it's not very popular though? and isn't really being maintained
anymore

Any one able to provide any background? Or why this would be a good / bad
idea

Thanks
Tim

On Fri, 21 Feb 2020 at 14:50, Chris Kilding 
wrote:

> Hi Rick,
>
> For specific use cases, perhaps we are looking more at meta-plugins than
> metapackages…
>
> Meta-plugins would consist (almost) exclusively of a POM. Versions of each
> downstream plugin that is relevant to the use case would be pinned and
> controlled in the POM. Each meta-plugin release marks a combination of
> those plugins that are certified to work together. This takes the version
> testing and pinning work out of the Jenkins admin’s hands.
>
> The various cloud providers are good candidates for meta-plugins, because
> every integration with a provider is typically built on the following
> foundational components:
> - An SDK (e.g. aws-java-sdk-plugin)
> - A shared configuration mechanism (e.g. aws-global-configuration-plugin)
>
> And the cloud providers update their SDKs frequently, especially with
> security fixes, so the rate of dependency churn is high.
>
>
> On the topic of advertising popular plugins, platform-plugins.json looks
> like a good in-band mechanism of doing this, and if particular use case
> meta-plugins are popular, they too should be advertised through it.
>
> Chris
>
> > On 21 Feb 2020, at 00:58, Rick  wrote:
> >
> > Hi Chris,
> >
> > Thanks for providing the advice. People usually use Jenkins as one or
> several specific scenes. Like you mentioned an AWS metapackage. I think we
> can define two kinds of metapackages. One is the pre-defined which likes
> AWS use cases, e.g. Another kind is that show the popular metapackages
> which come from the users of Jenkins distribution customise service. How do
> think about this?
> >
> > Platform-plugins.json is a good example. Thanks Jesse!
> >
> > Best regards,
> > Rick
> >
> >> On 21 Feb 2020, at 00:33, Jesse Glick  wrote:
> >>
> >> On Thu, Feb 20, 2020 at 9:51 AM Chris Kilding
> >>  wrote:
> >>> These metapackages in turn could be consumed (and featured) by the
> proposed Jenkins customise service.
> >>
> >> Also
> >>
> >>
> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/jenkins/install/platform-plugins.json
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2-mR6ShssSHEHL-f8msytS4_x6K%3DFSmaYBF6kju4gj%2Bg%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/F10030E1-760D-48BD-B149-7B8595596ABC%40126.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/0371C77F-E9D3-48B1-BD77-D5B0C1173F90%40chriskilding.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-3Bic3nxaJM4hGB2jWr70%2BG2AgCenjdLaCoo60E3dNynkekQ%40mail.gmail.com.

Re: Commit access request (File operations plugin)

[Tim Jacomb]

Please cc him in this thread, if there’s no response we normally wait 2
weeks from cc and then grant access

On Sun, 23 Feb 2020 at 18:23, Ramzi El-Yafi  wrote:

> Hi,
>
> As per the adopt a plugin guidelines, I would like to request commit
> access to the file operations plugin:
>
> *Plugin Repo: *https://github.com/jenkinsci/file-operations-plugin
> *PR I would like to deliver: *
> https://github.com/jenkinsci/file-operations-plugin/pull/9
> *GitHub Id:* relyafi
> *Jenkins Infrastructure Account: *relyafi
>
> *Background: *I initially emailed pskumar448 (the plugin owner) at the
> end of December to get his input on the best way to handle the use case I
> had for copying and renaming files within a single operation. Having
> received no response, I developed a change to satisfy my requirements, and
> included both him and another developer who had made changes (darxriggs).
> Darxriggs did provide feedback, but after emailing him to discuss this, he
> stated he does not have merge access, nor time to look into my PR or use
> case further. I have emailed pskumar448 twice since publishing the PR
> requesting feedback, and have unfortunately still had no response.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/2dc89d77-25a6-426b-9afc-7a78af16f184%40googlegroups.com
> 
> .
>

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

Re: JEP-225: Folder-based access control for any credentials provider

[Tim Jacomb]

Which bit were you unclear about?
Point 1?

Point 1 is a request based authorisation, nothing is allowed to use it by
default, jobs request to use it and then an autrhorised person allows it

On Wed, 12 Feb 2020 at 23:36, Chris Kilding 
wrote:

> Point 2 (credentials scoped to a single build) could be relevant - if
> we’re adding a credentials concept to a general ACL, a user should be able
> to apply any kind of restriction that their ACL permits to the credentials
> objects. (Not just folder restrictions.)
>
> I’m a bit unclear about what you meant though - could you clarify, maybe
> with an example?
>
> Chris
>
> On 12 Feb 2020, at 18:01, Tim Jacomb  wrote:
>
> 
>
> Not directly related, possibly even to this JEP,
>
> But wanted to add a couple of features I’ve seen in other systems,
>
> 1. Require authorisation, before allowed to use, I.e build is run and
> fails because the credential isn’t authorised for that job but then an
> administrator can authorise it and it will be allowed to use it on the next
> run,
> 2. Credentials scoped to a single build
>
> Thanks
> Tim
>
> On Wed, 12 Feb 2020 at 17:50, Chris Kilding <
> chris+jenk...@chriskilding.com> wrote:
>
>> The first thing to figure out is what role-based access control solutions
>> are already out there for Jenkins, so we can then decide how best to fit
>> this functionality in.
>>
>> I have encountered the following solutions which seem relevant, but I
>> know very little about them:
>>
>> - Cloudbees RBAC plugin (commercial)
>> - Role Strategy Plugin
>> - Jenkins permissions system
>>
>> Would someone who knows these components well be able to provide more
>> details, and thoughts on how we might add concepts of folders and
>> credentials to them, so that credential access constraints could be
>> formulated as standard rules?
>>
>> Chris
>>
>> > On 12 Feb 2020, at 16:29, Chris Kilding 
>> wrote:
>> >
>> > Hello,
>> >
>> > This is the discussion thread for JEP-225: Folder-based access control
>> for any credentials provider.
>> >
>> > A brief summary...
>> >
>> > The Cloudbees Folders Plugin has the ability to restrict access to
>> credentials on a per-folder basis. Unfortunately this feature is only
>> available for credentials stored in the Folders plugin's internal provider.
>> This JEP will extend that concept, and allow users to specify folder-based
>> access restrictions for any credential, from any provider.  (For example,
>> the AWS Secrets Manager and Kubernetes providers.)
>> >
>> > This JEP is relevant in 2 notable cases:
>> >
>> > - Dev / Production environment isolation. (Ensure that only jobs in the
>> production environment can access production credentials, and vice versa.)
>> > - Per-team isolation on a multi-tenant Jenkins. (Ensure that only a
>> given team or teams can access their credentials.)
>> >
>> > You can follow the pull request at
>> https://github.com/jenkinsci/jep/pull/266.
>> >
>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%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/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you

Re: Presenting frontend toolchain changes

[Tim Jacomb]

Normal jira sounds fine to me,
Webpack is a very standard front end tool these days

On Thu, 9 Jan 2020 at 17:26, Felix Queiruga  wrote:

> Hi everybody,
>
> I have a working draft for replacing js-builder with webpack on Jenkins
> core (not on plugins). The branch is a WIP, it's only missing adapting JS
> unit tests and linter.
>
> Before I submit the draft PR, I'd like to know if this toolchain change
> should be first explained on a JEP or if a normal JIRA ticket is enough.
> Any thoughts on this matter?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/f7df41b5-30ff-4d23-8549-48ceddfff5ab%40googlegroups.com
> 
> .
>

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

Re: Proposal: Automatically requesting code reviews from plugin developer teams (CODEOWNERS)

[Tim Jacomb]

Possibly could give maintainers team maintainer permission to help with
that if the person they want to add is a member of the org

On Mon, 13 Jan 2020 at 13:37, Daniel Beck  wrote:

> How do you plan to address issues in plugins whose maintainers are largely
> (or even completely) managed outside the repo-specific team, or with custom
> teams that are largely maintained manually?
>
> Since we grant repo admin permissions, it's easiest for maintainers to
> just add new people as external collaborators, rather than go through Jira
> to get someone to tell the IRC bot to add a new team member. Nobody is a
> team maintainer by default.
>
> As an example of the kind of mess we're in, see jenkinsci/blueocean-plugin
> which has more than a dozen external collaborators, and its
> blueocean-plugin Developers team governs write access to four separate
> repositories (which also have external collaborators, and possibly their
> own "$pluginId-plugin Developers" teams).
>
> On Thu, Jan 9, 2020 at 2:05 PM Oleg Nenashev 
> wrote:
>
>> Hi all,
>>
>> I propose to improve the code review process across the Jenkins GitHub
>> organization. TL;DR: Let's introduce CODEOWNERS in repositories and
>> automatically request reviews from maintainer teams.
>>
>> *Motivation:* In a number of plugins we have issues with pull requests
>> which do not get timely reviews from the maintainers. It slows down
>> delivery of fixes and impacts contributor experience, especially for
>> newcomers who have to wait and to ping maintainers. Finally it impacts our
>> ability to attract and retain contributors, and also causes frustration
>> among maintainers and Jenkins users who see the desired PRs unmerged.
>>
>> *Why does it happen?* We have well known issues with abandoned plugins,
>> and there we cannot do much except promoting the adoption process
>> .
>> But lack of reviews also happens in other plugins. In many cases it is just
>> caused by maintainers missing GitHub notifications (I am guilty of that
>> too) and/or forgetting to follow-up. It is normal, because many plugins are
>> maintained by volunteers. Life happens, work happens, etc. But we could
>> help maintainers to keep track of review requests.
>>
>> *Current state:*
>>
>>- In recent years GitHub introduced support of code review requests.
>>GitHub offers built-in dashboards so that every user can see the pending
>>reviews (link ). There are
>>also tools like In recent years GitHub introduced support of code review
>>requests. Pull reminders  which can
>>integrate with corporate environments. For example, it allows to notify
>>about new PRs and to periodically remind about stale review requests in
>>Slack.
>>- How do we use GitHub? For each plugin we already have a GitHub team
>>( ${reponame}-developers) which could be used to request reviews (see 
>> GitHub
>>permissions management
>>
>> ).
>>jenkinsci organization members can request reviews inside the organization
>>- External contributors cannot request reviews if they are not a part
>>of the organization or repository collaborators. They can only CC
>>maintainers in comments, and they won/t be able to see developer teams and
>>request reviews from them
>>
>> *Proposed solution:* GitHub now offers Code Owners metadata file
>> 
>>  for
>> repos. It allows to specify owners of particular sections of code and to
>> automatically request reviews from them in pull requests. Such reviews will
>> be requested even if the submitter is not a member of the GitHub
>> organization. It would also help organization members, because they will
>> not need to manually request reviews and spend time on it. In order to
>> implement that for a repo, we just need to add a string like "*
>> @jenkinsci/pluginId-plugin-developers " in to .github/CODEOWNERS (example
>> 
>> ).
>>
>> *Scope of changes: *Plugin repositories inside the jenkinsci GitHub
>> organizations. Other organizations (e.g. jenkins-infra) or non-plugin
>> repositories are out of the scope.
>>
>> *Risks:*
>>
>>- "${reponame}-developers" team is a common practice, put it is not a
>>case for all plugin repositories.
>>   - Solution: We skip repositories with a different permission model
>>- Not every maintainer may want to be requested in such way. Some
>>people do not like to receive too many notifications, and prefer to look 
>> at
>>the repository periodically.
>>   - Solution: the process should be opt-in
>>- Ownership changes in plugin? How they will impact the process
>>   

Re: Proposal: Automatically requesting code reviews from plugin developer teams (CODEOWNERS)

[Tim Jacomb]

The list of maintainers is already public in the repository permissions
list,

+1 for changing this

I assume the API call needs to be updated slightly in the IRC bot

Thanks
Tim

On Mon, 13 Jan 2020 at 12:46, Marky Jackson 
wrote:

> Oleg,
> I feel that need some form of consent from maintainers.
>
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev  wrote:
>
> 
>
> One thing here is that the most of the *pluginId-developers* teams are
> secret at the moment, and the teams must be public to operate properly with
> CODEOWNERS.
> I suggest to make all of them public, IMHO there is no value in hiding
> teams in the open-source project (apart form unintended mention prevention).
> I will add it to the next governance meeting, but I would appreciate the
> feedback
>
>
>
> On Fri, Jan 10, 2020 at 12:31 PM Oleg Nenashev 
> wrote:
>
>> I'd guess any plugin maintainer can just proceed and add CODEOWNERS to
>> the repo.
>> There is no need to wait for the bot if you want to start adopting the
>> suggestion :)
>>
>> On Thursday, January 9, 2020 at 7:07:08 PM UTC+1, Gavin Mogan wrote:
>>>
>>> Sweet I was going to suggest the same thing..
>>>
>>> Lots of plugin maintainers don't realize they are not "watching" a repo.
>>> and I think tools like pr bot don't count you unless your listed as a
>>> reviewer
>>>
>>> So much +1 for me
>>>
>>> On Thu., Jan. 9, 2020, 6:29 a.m. Oleg Nenashev, 
>>> wrote:
>>>
 Perfect, this makes the barrier to acceptance quite low,
> without forcing a change on anyone.
>
 Yes, I do not think we are in position to enforce the process at the
 moment. Historically Jenkins project gives a lot of freedom to plugin
 maintainers to define how they operate, and IMHO it is a part of the
 project's culture. IMHO we should rather lead by example there and help by
 providing tools and solutions simplifying the work and removing routine.

 On Thursday, January 9, 2020 at 3:04:51 PM UTC+1, Jesse Glick wrote:
>
> On Thu, Jan 9, 2020 at 8:05 AM Oleg Nenashev 
> wrote:
> > We add CODEOWNERS template to plugin archetypes
>
> Yes, though we need to do JENKINS-58557 first.
>
> > We submit pull requests […]
> > Each plugin maintainer or maintainer team will decide on their own
> whether they accept the process or not. Merging or closing the pull 
> request
> will indicate the decision
>
> Perfect, this makes the barrier to acceptance quite low, without
> forcing a change on anyone.
>
 --
 You received this message because you 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/f3f0b2d4-bb98-458d-9c96-ccdee1d1fec1%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/U_lFkTzmg1E/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/bc4c21c0-a18c-467a-a02e-a26cfa5acd97%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/CAPfivLATCB1R_OWLsEuGNoCx-k%2BqfQwJHxwvJOVbEFkgHWTW4A%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/77113232-CBF5-4E20-963D-836E75DA4161%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 

Re: Plugin host

[Tim Jacomb]

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


On Thu, 26 Dec 2019 at 16:46, selva vignesh 
wrote:

> Hello Team,
> Currently, I am looking for a guide to host my plugin in Jenkins side.
> Kindly assite me.
> Thanks in advance
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/68666448-18e0-4f91-8ff7-c0fc39b62bd0%40googlegroups.com
> 
> .
>

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

Re: Plugin host

[Tim Jacomb]

Not that I’m aware of
If you start from one of the plugin archetypes you should get a test or two
that can be useful depending on what your plugin does
https://github.com/jenkinsci/archetypes

On Thu, 26 Dec 2019 at 20:08, selva vignesh 
wrote:

> Hi Tim,
> Is unit test mandatory for hosting plugin?
>
> On Thu, Dec 26, 2019 at 2:10 PM Tim Jacomb  wrote:
>
>> https://jenkins.io/doc/developer/publishing/requesting-hosting/
>>
>>
>> On Thu, 26 Dec 2019 at 16:46, selva vignesh 
>> wrote:
>>
>>> Hello Team,
>>> Currently, I am looking for a guide to host my plugin in Jenkins side.
>>> Kindly assite me.
>>> Thanks in advance
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/68666448-18e0-4f91-8ff7-c0fc39b62bd0%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/68666448-18e0-4f91-8ff7-c0fc39b62bd0%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/CAH-3BifQLw3h08dvchXMjSp-Pt2T7DPp5FcB6RP9CwE-JraD8Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifQLw3h08dvchXMjSp-Pt2T7DPp5FcB6RP9CwE-JraD8Q%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/CAOVVkp%3Dk_TgPSqGgt9Kj3bm9k5nXMnQNoH_%3DCUQ4L6STE_5sPg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAOVVkp%3Dk_TgPSqGgt9Kj3bm9k5nXMnQNoH_%3DCUQ4L6STE_5sPg%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-3Bif6sL4WGbq9Cix8xC4XOpjnh5HhD86gWFdYj4qrepPnWA%40mail.gmail.com.

Re: Uninstall plugin

[Tim Jacomb]

Docs for that are here:
https://wiki.jenkins.io/plugins/servlet/mobile?contentId=65142785#content/view/65142785

Possibly documented on Jenkins.io as well but didn’t come up when I googled
it...

On Fri, 27 Dec 2019 at 21:07, selva vignesh 
wrote:

> Team,
> In global Configuration I'm saving credential details for my plugin. Its
> stored as a XML in Jenkins_home path.
> When i uninstall the plugin, these xml are not getting deleted. How to
> delete these XML when i uninstall the plugin.
> Kindly assist me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/2a4d5491-1e2d-4973-bdc6-e6ca7574bbf6%40googlegroups.com
> 
> .
>

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

Re: Happy Holiday

[Tim Jacomb]

Personally I’ve never found the invite system in slack very difficult, (not
as simple as straight GitHub integration :( ) but you just deploy an app
like
https://github.com/outsideris/slack-invite-automation/blob/master/README.md,
add a badge to your readme and then people self service sign themselves up.
(Jenkins UX is a weird one for some reason CDF foundation hasn’t set that
up so you need an invite)

I’ve seen it work really well elsewhere, k8s has a very large slack
community with multiple sigs and user groups.

Also I’ve never googled something and had a gitter result come back...

Discourse could be useful, as an alternative / supplicant to a mailing list
but I don’t think it handles the real time chat aspect.

IRC has a higher barrier to entry imo especially for someone who has used
slack or gitter. It works well once you get used to it  but I don’t think
many newer projects are using it.

Gitter works most of the time and it’s okay (few annoying issues with it
though)

I agree that driving this through a SIG would probably be best, with
analysis on what the community wants, along with options out there and a
recommendation?

Or different SIGs / plugins keep choosing their own means and it stays
fragmented

Happy holidays
Tim


On Fri, 27 Dec 2019 at 11:41, Marky Jackson 
wrote:

> I said Hugo but meant Discourse
>
> On Dec 26, 2019, at 6:39 PM, Marky Jackson 
> wrote:
>
> 
>
> I like using chat bots with Hugo but found it even easier with slack and
> kubernetes integration but I think that might be over the top.
> I do like this conversation though and think it would be worth a survey of
> sort but that is up to the board and sig leads to try and drive adoption.
> I think the advocacy team can help drive this and other topics but the
> leads of sig’s and the board have the ultimate representation and that was
> more the logic for my original email, to help the larger community
> discussion take place in the open.
>
> On Dec 26, 2019, at 6:35 PM, William Hetherington  wrote:
>
> 
> Interesting, I run discourse for a personal project but didn’t think about
> it for this that is definitely another option!
>
> I wrote a plugin for it to do websockety type comms from a chat box, but I
> haven’t looked at it in ages, it is probably not functional atm.
>
> On Thu, Dec 26, 2019 at 18:12 Marky Jackson 
> wrote:
>
>> I am a +1 on discourse. Widely used in another oss project and a great
>> medium.
>> The mailing list is good but lacks the direct ‘fast’ style communications
>> a project of this size needs. I still use it but it is not part of muscle
>> memory.
>>
>> On Dec 26, 2019, at 6:10 PM, 'Gavin Mogan' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>> 
>>
>> Personally, I'd love to downplay the realtime chat and make the mailing
>> lists a bit more useful. Maybe something like discourse (self hosted, or
>> https://free.discourse.group/) setup, where we can have threads that are
>> easily searchable. Its totally able to be managed by email for those who
>> prefer email, and threaded for those that don't.
>>
>> I can't remember the last time I did a google search and the jenkins
>> mailing list came up.
>>
>> But yea, a longer discussion is probably needed.
>>
>> On Thu, Dec 26, 2019 at 6:04 PM Marky Jackson 
>> wrote:
>>
>>> Replying to both Gavin and William,
>>> I think your both points are fair and I completely accept it. I do think
>>> gitter is limiting but I am in favor of openness over limiting any day.
>>> Thank you both for your insight and this is what the community needs
>>> more of. Open discussion and understanding of all view points.
>>> Thank you both again and happy holidays
>>>
>>> On Dec 26, 2019, at 5:53 PM, William Hetherington 
>>> wrote:
>>>
>>> 
>>> Echo much of what Gavin said. Chat is a tough problem to solve, you
>>> don’t reach critical mass if there is a cost, and there are just so many.
>>>
>>> Keybase.io and a private Jenkins team might be a good option?
>>>
>>> It’s e2e encrypted, X-platform clients, allows for public entry rooms in
>>> what is otherwise a private “team”
>>>
>>> https://keybase.io/willwh is my user if you want to follow or chat.
>>>
>>> The other nice thing is keybase is well integrated to github too :)
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> On Thu, Dec 26, 2019 at 17:41 'Gavin Mogan' via Jenkins Developers <
>>> jenkinsci-dev@googlegroups.com> wrote:
>>>
 I would be very much against yet another slack i'd have to join.
 Especially cause its a closed system, requiring invites to join. Its
 certainly why i havn't bothered looking into the jenkins-ux sig.

 Gitter is nice because everything is public and googleable, you only
 need a github account, which is the minimum you'd need to contribute to any
 of the jenkins systems anyways. Though gitter is pretty abandoned, and I
 would prefer IRC, especially with a public logging bot.

 Gavin



 On Thu, Dec 26, 2019 at 5:27 

Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Tim Jacomb]

do you mean #jenkins on irc or gitter http://gitter.im/jenkinsci/jenkins ?

gitter jenkins is are very heavy user channel

irc jenkins isn't so bad but still lots of people after pipeline help.

On the kubernetes slack there's a few, -users and -dev
channels
Which helps separate out the noise in my opinion.

But yeah open to both...

On Wed, 8 Apr 2020 at 14:50, Daniel Beck  wrote:

>
>
> > On 8. Apr 2020, at 14:17, Oleg Nenashev  wrote:
> >
> > creation of chats and other communication channels for Jenkins core
> maintainers which could help in the case of runtime communications:
> merge/changelog discussions, sync-ups between maintainers, etc. Right now
> we mostly use pull requests and mailing lists for such kind of discussions,
> but a number of private messages between maintainers makes me tink that we
> might be lacking a chat for runtime discussions
>
> I see this going in two ways:
>
> - Core development related (and will probably pretty open)
> - Core maintenance related (and can easily be limited to committers and
> the triage team)
>
> It seems to me that there are already plenty of venues to discuss the
> former, and it's typically not time sensitive. OTOH, the latter needs (or
> can benefit from) closer coordination, especially towards end of the week,
> or before LTS schedule related dates.
>
> I prefer we don't create yet another almost-general-purpose chat (what
> wrong with #jenkins and equivalents for general questions about core?), so
> for me, the latter seems more useful. A larger scope would also increase
> the volume of messages, which makes it less viable to have notifications
> enabled.
>
> That said, I'm open to either (or both…), if the chosen approach doesn't
> work we can always change it. Given the relatively small group of people
> involved, it shouldn't be too difficult to change direction.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/925CE240-87BD-44B3-8D15-535FDFE4F328%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/CAH-3Bif09MwSQZFW6CLvnejsN7drWk8Zo%2Bp8Yw0U8UWhY-G01A%40mail.gmail.com.

Re: Proposal: Windows support policy for Jenkins

[Tim Jacomb]

Sounds reasonable to me +1,
I speak as someone who barely ever touches Windows and never for Jenkins 
though

Thanks
Tim

On Friday, 10 April 2020 13:26:51 UTC+1, 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/c755618e-b046-44b9-b155-38fdaba6d214%40googlegroups.com.

Re: [Proposal] Centralize chat on matrix

[Tim Jacomb]

Hi

I've just had a try of matrix using riot.im

The UI looks nice and it's easier the core matrix.org server than IRC

Few negatives I found though:

* Bridging to IRC on freenode required some googling as you get insta
kicked out as you haven't identified to nickserv, needed to google around
to find how to DM nickserv from matrix,
but that worked in the end. I'll continue using it for a bit and see how it
compares to IRC cloud.
* It seems someone has to add each irc room as published on matrix.org
otherwise you can't search it, (I was able to join #jenkins and
#jenkins-infra, but #jenkins-meeting didn't come up)
* gitter bridge UX is horrid, it's because of limitations of the gitter API
and there's issues been open for years, but I wouldn't recommend using this
bridge
[image: image.png]
* no threading support (riot-web#2349
), even gitters limited
threads are better than nothing imo in a busy room
* no oauth support so can't use GitHub / twitter / google auth, if you host
your own server you can setup LDAP
* if we self hosted for LDAP it's another service to maintain

Positives:
* all open source
* the bridging is nice so you can have IRC in as well if you use that
* emoji reactions to messages (gitter doesn't have this)
* easy file sharing

@Gavin Mogan  if we were to use this is there a
reason not to use the SaaS version (other than LDAP auth)?

Personally I think that Slack is a better tool,
* threading
* lots of communities use it
* very easy to use
* fully SaaS
* lots of easy to add bot integrations

But happy to use it if it gets us off gitter and gives us one place where
all the jenkins community chat rooms would be

Thanks
Tim



On Fri, 10 Apr 2020 at 10:35, Ullrich Hafner 
wrote:

> Interesting, yet another chat system:-) In our university they now
> installed Mattermost and Rocket.Chat in order to help us to collaborate
> with the students during the lock down...
>
> I like the idea to have one centralized system. I looks like Matrix (or
> Mattermost or Rocket.Chat) seem to be very user friendly systems that lower
> the barrier for beginners. And they seem to be superior to Gitter (which
> looks a little bit outdated compared to the other systems).
>
> Our resources for infrastructure are quite valuable - Gitter and IRC do
> not require anything on our side, the service is provided for free. What is
> required for our organization to get such a chat system running? (We almost
> have no time to get our other services running, see e.g. the discussion
> about Jira.)
>
> Am 10.04.2020 um 01:44 schrieb 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com>:
>
> I heard about matrix for the first time a few months ago when mozilla
> officially shut down its irc servers and switched to matrix.
>
> I'm really bad at documenting ideas, but I'm open to any and all questions.
>
> Matrix is decentralized federated (nice fun buzz words again) chat system.
>
> *Vs IRC:*
> IRC has a large barrier of entry these days. Most people don't have irc
> clients anymore. No persistent logging. Really hard file sharing. No
> notifications. IRCCloud makes this simple, but costs money.
> Matrix
>
> Matrix has a matrix-ircd gateway to let irc clients talk to matrix, as if
> it was an irc server
>
> *Vs Gitter:*
> Gitter is pretty much abandonware these days, it was acquired by gitter
> and not much has been done since. They recently added threads, but I find
> them horrible, hard to track.
> Notifications are inconsistent, they are pretty decent on desktop, but non
> existent on mobile.
> Gitter is good in the sense that its low barrier to entry. You just need
> github, gitlab, or twitter account. And most people have that already.
>
> *Vs Slack:*
> * Channels can be public to guests (see
> https://view.matrix.org/room/!GibBpYxFGNraRsZOyl:matrix.org/)
> * Can hook up to our jenkins ldap auth, so no need for extra accounts (if
> self hosting)
>
> *Useful features:*
> * Federated, people could use jenkins account (if self hosting) or
> matrix.org, or any other server (for example I self host chat.g4v.dev)
> * Flair - like reddit, you can get various labels beside your names in
> channels, you could have "core-contributor" or "plugin-author" or whatever
> else we wanted
> * Fully integrated with https://jitsi.org/ for per channel video
> conferencing
> * I almost have helm charts for all basic features if we want to self host
> * Bridging for most major services (gitter, irc, slack, etc) inside a
> matrix channel with 2 way communication. It will likely show up as bot on
> gitter side, but does work
> 
> as an example on gitter jenkinsci/docs
>
> List of other sdks, servers, clients, etc -
> https://matrix.org/docs/projects/try-matrix-now
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [Proposal] Centralize chat on matrix

[Tim Jacomb]

>
> >  if we were to use this is there a reason not to use the SaaS version
> (other than LDAP auth)?
>
> I think if we did modular.im, we could still use ldap, and they might be
> have open source pricing. I think its something that cdf might be
> interested in.
>
> I just don't like slack because I have now close to 15 different slack
> accounts. Each server needs individual accounts, and monitoring. The
> desktop client can handle multiple servers ..okay, though ate up a lot of
> memory. I don't know if this ever got fixed.
>

Agree the multiple accounts is a pain
The performance was fixed mid last year:
https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4


> I'm a big fan of the big shared environment like gitter and irc where you
> can belong to multiple communities at the same time.
> I also like the matrix has matrix-irc, which would allow weechat, irssi,
> ircloud, etc to connect and use basic features like you would with an IRC
> server if desired.
>
> Agree that's useful


Tim

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

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

[Tim Jacomb]

There's a proposal for automating plugin release here:
https://jenkins.io/jep/221
Not sure what's needed to get it going though, would be great to get done

Thanks
Tim

On Fri, 10 Apr 2020 at 16:46, Slide  wrote:

> 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
  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 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
 
 .

>>>
>>>
>>> --
>>> 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
>> 
>> .
>>
>
>
> --
> 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
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send 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-3Bify1eu%3DFs4F9VPYw_Ai_JBySYGCTvNS%2BJdcx%2BO5yWPYPg%40mail.gmail.com.

Re: Configuration Slicing plugin adoption

[Tim Jacomb]

Normally you use the Jenkins bom
https://github.com/jenkinsci/bom

Which includes the common plugins that are depended on, it saves a lot of
time when updating versions.

Thanks
Tim

On Mon, 13 Apr 2020 at 12:44, Guy Sheffer  wrote:

> Thanks Oleg,
> To anyone that could help,
> I have got as far as updating all the versions by hand, but I am getting
> some RequireUpperBoundDeps errors. I am not sure what is the methodology to
> fix this, assuming now all the versions are up to date (which they might
> not be because I did this manually).
> I am really close to making a new release that supports pipeline build and
> would really appreciate figuring out this hopefully last step, will note
> that it does build on my local machine.
>
> Thanks,
> Guy
>
> https://issues.jenkins-ci.org/browse/JENKINS-61827?filter=21951
>
> On Sunday, March 15, 2020 at 3:14:58 PM UTC+2, Guy Sheffer wrote:
>>
>> Hey, here is the information as requested in
>> https://wiki.jenkins.io/pages/viewpage.action?pageId=103088172
>>
>>-
>>
>>Link to a plugin you want to adopt:
>>https://plugins.jenkins.io/configurationslicing/
>>-
>>
>>Link(s) to pull requests you want to deliver, if applicable:
>>https://github.com/jenkinsci/configurationslicing-plugin/pull/21
>>Note: this is not my code, however I want to build, fix and manage
>>the plugin
>>-
>>
>>Your GitHub username/id (e.g. oleg-nenashev for
>>https://github.com/oleg-nenashev/)
>>guysoft
>>-
>>
>>Your Jenkins infrastructure account id. Create your account
>> if you don’t have one: guysoft
>>
>> Also, I tried to build the plugin and the build fails (test plugin fro
>> the tutorial works fine).
>> So I want to fix that first.
>> Build output here if anyone can tell me what is going on:
>> https://pastebin.com/reU1DbAt
>>
>> 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/1afbeb77-9f02-4e44-a8e4-38070deb864b%40googlegroups.com
> 
> .
>

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

New bom lines released

[Tim Jacomb]

Hi

Just a note to say we've recently shipped the following bom lines:

   - 2.190.x
   - 2.204.x
   - 2.222.x

We are no longer shipping updates for 2.150.x

Usage guide: https://github.com/jenkinsci/bom#usage
Releases: https://github.com/jenkinsci/bom/releases

Thanks
Tim

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

Re: plugin parent 4.0

[Tim Jacomb]

This seems not to have happened, I'm happy to do it Oleg if you're too busy?

Thanks
Tim

On Mon, 6 Apr 2020 at 09:55, Oleg Nenashev  wrote:

> Hi all,
>
> There was no new breaking changes coming in, and I think it is time to go
> ahead and release a 4.0 version.
> I plan to do so tomorrow if there is no negative feedback.
>
> It would be great if somebody could write a blogpost with a summary of the
> changes in the new major release
>
> P.S: 4.0 works great in plugins I tried.
>
> Best regards,
> Oleg
>
>
> On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:
>>
>> I applied 4.0-beta-6 to the git client plugin as part preparation to set
>> Jenkins 2.204.1 as the new required minimum version.  Worked great.  No
>> issues detected.
>>
>> On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson 
>> wrote:
>>
>>> +1
>>>
>>> I don't remember if I've pushed any commits that use the beta parent,
>>> but I've tried it out on a variety of different plugins I've investigated.
>>> I've found it to work better than any of the other earlier versions and
>>> can't think of any issues I've encountered.
>>>
>>> Jeff
>>> On 3/26/20 3:20 AM, Tim Jacomb wrote:
>>>
>>> I've been using it on a few plugins, no issues
>>>
>>> On Thu, 26 Mar 2020 at 09:11, James Nord  wrote:
>>>
>>>> Hi Oleg et al.
>>>>
>>>> is it time to move the plugin parent out of beta?
>>>>
>>>> have not seen any negative feedback (or positive door that matter) but
>>>> I've been using it for numerous proprietary plugins with no issue.
>>>>
>>>> /James
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> 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/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%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/CAH-3BifaAfugnsG0BQpH3heqvPx7eY-KxhJX_xnmSjNLivy72w%40mail.gmail.com.

Re: plugin parent 4.0

[Tim Jacomb]

Hi

plugin pom 4 is now released,

Full release notes including all beta versions:
https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0

Thanks
Tim

On Wed, 15 Apr 2020 at 19:52, Tim Jacomb  wrote:

> This seems not to have happened, I'm happy to do it Oleg if you're too
> busy?
>
> Thanks
> Tim
>
> On Mon, 6 Apr 2020 at 09:55, Oleg Nenashev  wrote:
>
>> Hi all,
>>
>> There was no new breaking changes coming in, and I think it is time to go
>> ahead and release a 4.0 version.
>> I plan to do so tomorrow if there is no negative feedback.
>>
>> It would be great if somebody could write a blogpost with a summary of
>> the changes in the new major release
>>
>> P.S: 4.0 works great in plugins I tried.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Monday, March 30, 2020 at 12:26:54 AM UTC+2, Mark Waite wrote:
>>>
>>> I applied 4.0-beta-6 to the git client plugin as part preparation to set
>>> Jenkins 2.204.1 as the new required minimum version.  Worked great.  No
>>> issues detected.
>>>
>>> On Thu, Mar 26, 2020 at 8:38 AM Jeff Thompson 
>>> wrote:
>>>
>>>> +1
>>>>
>>>> I don't remember if I've pushed any commits that use the beta parent,
>>>> but I've tried it out on a variety of different plugins I've investigated.
>>>> I've found it to work better than any of the other earlier versions and
>>>> can't think of any issues I've encountered.
>>>>
>>>> Jeff
>>>> On 3/26/20 3:20 AM, Tim Jacomb wrote:
>>>>
>>>> I've been using it on a few plugins, no issues
>>>>
>>>> On Thu, 26 Mar 2020 at 09:11, James Nord  wrote:
>>>>
>>>>> Hi Oleg et al.
>>>>>
>>>>> is it time to move the plugin parent out of beta?
>>>>>
>>>>> have not seen any negative feedback (or positive door that matter) but
>>>>> I've been using it for numerous proprietary plugins with no issue.
>>>>>
>>>>> /James
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> 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/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/dbeebe3e-d25e-44be-af92-1f26ce1c8582%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/CAH-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%40mail.gmail.com.

Re: Jenkins Plugin Wiki

[Tim Jacomb]

Possibly that could have an impact

I’m hoping to look at this soon


On Tue, 7 Apr 2020 at 18:30, Mark Waite  wrote:

> Interesting.  I see the same outdated page that you show in your
> screenshot.
>
> The ci.jenkins.io build queue is quite long right now.  The acceptance
> test harness is processing pull requests and will likely be doing that for
> a few more hours.  That might be blocking some processing of updates of
> plugins.jenkins.io.
>
> On Tue, Apr 7, 2020 at 11:16 AM Eric Citaire 
> wrote:
>
>> Just now (see screenshot).
>>
>> Le mar. 7 avr. 2020 à 15:27, Eric Citaire  a
>> écrit :
>>
>>> Right now it is up to date. But it is not the case all the time.
>>>
>>> I can't tell when exactly it was out of date, but I saw it multiple
>>> times out of date and back up to date a couple hours later.
>>>
>>> As if it was load balanced and one of the backends is out of date,
>>> except that refreshing or emptying the browser cache has no effect.
>>>
>>> Le mardi 7 avril 2020 15:15:51 UTC+2, Mark Waite a écrit :

 I'm seeing the current releases for docker-java-api and docker-plugin
 when I view them through https://plugins.jenkins.io/ .

 Are you still seeing them shown as out of date?

 Have you forced a refresh of your browser?

 On Tue, Apr 7, 2020 at 6:16 AM Eric Citaire  wrote:

> I'm experiencing the same behavior on other plugins released
> recently (docker-plugin and docker-java-api). The plugins site keeps
> rolling back to the old version.
>
> I think there is a real problem with the plugins site.
>
> Le mardi 7 avril 2020 11:09:12 UTC+2, selva vignesh a écrit :
>>
>> Galvin, for an hour back, I was able to see the documentation in
>> plugin site. But now, seems reverted to 1.0 release.
>> Do i need to do anything from my side. please assist.
>>
>> On Tue, Apr 7, 2020 at 12:23 PM selva vignesh 
>> wrote:
>>
>>> Gavin, I'll proper release tag for upcoming releases
>>>
>>> On Tue, Apr 7, 2020 at 11:15 AM 'Gavin Mogan' via Jenkins Developers
>>>  wrote:
>>>
 I see 1.1 at
 http://updates.jenkins-ci.org/download/plugins/zohosprints/

 i also see 1.0.2, which you don't seem to have a tag/release for

 I'm very confused by the state of your repo.

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

> yes Slide. I am referring releasing plugin as a build. Sorry
> for the confusion.
>
> Sure Gavin. I will release one more build without hyphen.
>
> On Tue, Apr 7, 2020 at 9:08 AM 'Gavin Mogan' via Jenkins
> Developers  wrote:
>
>> 11 days ago is a suspicious number, none of them line up with
>> https://github.com/jenkinsci/zohosprints-plugin/releases
>>
>> I'm honestly not sure what will happen when you add values after
>> the version number (ex 1.0.3-docrelease), i know beta and alpha goto
>> experimental. Can you do a proper "1.0.3" or "1.0.4" release, 
>> without the
>> hyphen bits?
>>
>>
>> On Mon, Apr 6, 2020 at 8:36 PM Slide  wrote:
>>
>>> 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 <
>>> selvavi...@gmail.com> 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 <
 ric...@bywater.nz> 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 <
> no-r...@forwardemail.net> 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 jenkin...@googlegroups.com.
>> To view this discussion on the 

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

[Tim Jacomb]

+1 to inbound agent rename

What about just ssh-agent for the ssh one? We don’t need to worry about the
plugin name clash here I think

Thanks
Tim
On Sun, 12 Apr 2020 at 09:36, 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> sshd-agent?
>
> On Sun, Apr 12, 2020 at 1:12 AM Oleg Nenashev 
> wrote:
>
>> Also, I am not sure about using "jenkins/ssh-build-agent" as an image
>> name for SSH agents. Would appreciate opinions/suggestions. Maybe
>> "ssh-outbound-agent" though it may sound greek to users?
>>
>> On Sunday, April 12, 2020 at 9:13:48 AM UTC+2, Oleg Nenashev wrote:
>>>
>>> While we are here, I suggest to rename "jenkins/jnlp-slave" to
>>> "jenkins/inbound-agent" instead of merely replacing a single term.
>>> "JNLP" terminology is also deprecated, and with WebSockets support it
>>> creates even more confusion.
>>>
>>> BR, Oleg
>>>
>>> On Friday, April 10, 2020 at 11:06:38 PM UTC+2, Oleg Nenashev wrote:

 Dear all,

 We will be renaming Jenkins agent Docker images on Sunday/Monday in
 order to get rid of the "slave" terminology in image names. Scope: current
 "jenkins/slave", "jenkins/jnlp-slave" and "jenkins/ssh-slave" images. The
 renaming will involve renaming repositories on GitHub and re-configuring
 repositories on DockerHub. See INFRA-1105
  for more info.

 Potential impact:

- There might be some disruptions for developers who rely on the
images or use GitHub APIs to fetch repositories (no all APIs and GtHub 
 Apps
handle renaming correctly).
- There should be no issues for Jenkins users, we will keep
delivery flows for old naming so they will have time to migrate.
   - Migration period is TBD, because many components will need
   follow-up updates (e.g. some Docker and Kubernetes plugins), not to 
 speak
   about user. I would suggest to target 1 year of support

 I will submit a blogpost with the migration summary once it is
 completed.

 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/028ee530-2f2e-4131-ac99-2b499a7bbc1e%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/CAG%3D_Duu_%3DyiYCe6m_xKt7%3DmDbGO3%3DOMHXVfQyvP%3DQs7yMm9KfA%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-3BifCPX0MUzEsMv6q09hQ39vmjJk8Ho2Wnh1F-wKk4LJmZQ%40mail.gmail.com.

Re: Configuration Slicing plugin adoption

[Tim Jacomb]

Hi Guy

Timestamper and the two workflow plugins are in bom, I would still
recommend adding it,

It looks like timestamper changed its group id at some point

Thanks
Tim

On Sun, 19 Apr 2020 at 14:09, Guy Sheffer  wrote:

> Hey Tim,
> That bom (pom.xml) does not seem to hold most of the plugins used in
> Configuration Slicing plugin. This is because the plugin slices settings of
> many plugins. Each plugin is included as a dependency.
>
> You can grasp the size of the list here:
> https://github.com/jenkinsci/configurationslicing-plugin/blob/devel/pom.xml
>
> Just to make sure, I went over the plugins and made sure, indeed quite a
> lot, including email-ext, ant, groovy and others are not in that POM.
> I am fairly sure I managed to get all the dependencies under gorup-id
> org.jenkins-ci.plugins up to date. That was easy because the pages are for
> the plugins are documented. However I cam not sure about other settings.
> Such as timestamper in org.jvnet.hudson.plugins or plexus-utils in
> org.codehaus.plexus .
>
> This is the final step to get this plugin to build with the new support
> for pipeline, so if someone with more experience than me could take a look
> its likely something simple I overlooked.
>
> Thanks for helping out,
> Guy
>
> On Monday, April 13, 2020 at 3:29:20 PM UTC+3, Tim Jacomb wrote:
>>
>> Normally you use the Jenkins bom
>> https://github.com/jenkinsci/bom
>>
>> Which includes the common plugins that are depended on, it saves a lot of
>> time when updating versions.
>>
>> Thanks
>> Tim
>>
>> On Mon, 13 Apr 2020 at 12:44, Guy Sheffer  wrote:
>>
>>> Thanks Oleg,
>>> To anyone that could help,
>>> I have got as far as updating all the versions by hand, but I am getting
>>> some RequireUpperBoundDeps errors. I am not sure what is the methodology to
>>> fix this, assuming now all the versions are up to date (which they might
>>> not be because I did this manually).
>>> I am really close to making a new release that supports pipeline build
>>> and would really appreciate figuring out this hopefully last step, will
>>> note that it does build on my local machine.
>>>
>>> Thanks,
>>> Guy
>>>
>>> https://issues.jenkins-ci.org/browse/JENKINS-61827?filter=21951
>>>
>>> On Sunday, March 15, 2020 at 3:14:58 PM UTC+2, Guy Sheffer wrote:
>>>>
>>>> Hey, here is the information as requested in
>>>> https://wiki.jenkins.io/pages/viewpage.action?pageId=103088172
>>>>
>>>>-
>>>>
>>>>Link to a plugin you want to adopt:
>>>>https://plugins.jenkins.io/configurationslicing/
>>>>-
>>>>
>>>>Link(s) to pull requests you want to deliver, if applicable:
>>>>https://github.com/jenkinsci/configurationslicing-plugin/pull/21
>>>>Note: this is not my code, however I want to build, fix and manage
>>>>the plugin
>>>>-
>>>>
>>>>Your GitHub username/id (e.g. oleg-nenashev for
>>>>https://github.com/oleg-nenashev/)
>>>>guysoft
>>>>-
>>>>
>>>>Your Jenkins infrastructure account id. Create your account
>>>><https://accounts.jenkins.io/> if you don’t have one: guysoft
>>>>
>>>> Also, I tried to build the plugin and the build fails (test plugin fro
>>>> the tutorial works fine).
>>>> So I want to fix that first.
>>>> Build output here if anyone can tell me what is going on:
>>>> https://pastebin.com/reU1DbAt
>>>>
>>>> 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 jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/1afbeb77-9f02-4e44-a8e4-38070deb864b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1afbeb77-9f02-4e44-a8e4-38070deb864b%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/adeb4ba8-4c56-47d9-99b5-f499e5a1dc5d%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/adeb4ba8-4c56-47d9-99b5-f499e5a1dc5d%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/CAH-3Bic1uwPJKPUuYhhecwCbW-jvWGeNWzKCnx91FG7%2BGHaZQQ%40mail.gmail.com.

Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Tim Jacomb]

Also this for moderation on slack:
https://github.com/foqal/slack-moderator/blob/master/README.md


On Thu, 9 Apr 2020 at 12:51, Tim Jacomb  wrote:

> There’s this project for a public archive of slack:
> https://github.com/dutchcoders/slackarchive
>
> We would need the equivalent for IRC as well I think.
>
> With IRC currently there’s no public log of any of the Jenkins channels.
> Each person needs to log it then self or pay / run a service that will do
> it for them afaik
>
>
>
> On Thu, 9 Apr 2020 at 10:43, Radosław Antoniuk 
> wrote:
>
>> Hey, I'm not critisizing! I just have my own preference and opinion :-)
>> You know, if IRC would be so great, Slack wouldn't exist.
>> Indeed, between Gitter and IRC probably I'd choose IRC. Between
>> Rocket.Chat and IRC (although I never used it), for my own startup, I am
>> choosing Slack or Rocket.Chat, because of integrations and UI/mobile
>> friendliness etc. It always boils down to TCO and needed feature-set.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWjVxaq6a5AxxcVEpnh2_xuRzRAKxZxa2pVf9daVKDhhkQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWjVxaq6a5AxxcVEpnh2_xuRzRAKxZxa2pVf9daVKDhhkQ%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-3Bidr%2Bi-SFNJyGRgYS%3DTiyqWDJ2FWF9FM0s86mDR3au5pvQ%40mail.gmail.com.

Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Tim Jacomb]

There’s this project for a public archive of slack:
https://github.com/dutchcoders/slackarchive

We would need the equivalent for IRC as well I think.

With IRC currently there’s no public log of any of the Jenkins channels.
Each person needs to log it then self or pay / run a service that will do
it for them afaik



On Thu, 9 Apr 2020 at 10:43, Radosław Antoniuk 
wrote:

> Hey, I'm not critisizing! I just have my own preference and opinion :-)
> You know, if IRC would be so great, Slack wouldn't exist.
> Indeed, between Gitter and IRC probably I'd choose IRC. Between
> Rocket.Chat and IRC (although I never used it), for my own startup, I am
> choosing Slack or Rocket.Chat, because of integrations and UI/mobile
> friendliness etc. It always boils down to TCO and needed feature-set.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWjVxaq6a5AxxcVEpnh2_xuRzRAKxZxa2pVf9daVKDhhkQ%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-3BicJYs_4%2Bvn%2BjeFZYQPFE5f0XM5o-nRFJcAawhJArxBDWg%40mail.gmail.com.

Re: Maintainer of copy-editors group on GitHub?

[Tim Jacomb]

+1

You should have it due to your role as documentation officer imo

On Fri, 17 Apr 2020 at 15:10, Mark Waite  wrote:

> I'd like to be assigned as a maintainer of the copy-editors team on the
> Jenkins CI GitHub account.
>
> Are there specific steps that I should take to be granted maintainer
> permission to https://github.com/orgs/jenkins-infra/teams/copy-editors ?
>
> Thanks,
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/963caf2a-f552-493e-b21a-d22d7813608d%40googlegroups.com
> 
> .
>

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

Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Tim Jacomb]

I think a core-dev chat room would be useful,

I don’t think it needs limiting to just be core-developers though

Anything related to development on the core would be welcomed there

Thanks
Tim

On Wed, 8 Apr 2020 at 13:17, Oleg Nenashev  wrote:

> Hi all,
>
> In the Proposal: Expanding the Jenkins Core maintainers team
> 
>  thread
> we briefly discussed creation of chats and other communication channels for
> Jenkins core maintainers which could help in the case of runtime
> communications: merge/changelog discussions, sync-ups between maintainers,
> etc. Right now we mostly use pull requests and mailing lists for such kind
> of discussions, but a number of private messages between maintainers makes
> me tink that we might be lacking a chat for runtime discussions. Also, we
> could setup a regular call to discuss maintenance topics, do reviews in the
> screenshare mode and to do knowledge transfers about the codebase.
>
> I would appreciate feedback from Jenkins core maintainers and active
> contributors:
>
>- Would a dedicated chat help us? E.g. jenkinsci/core-developers in
>Gitter
>- Would it make sense to have a regular or an on-demand call for core
>maintainers?
>
> 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/7b23e02b-ef9d-4f15-b6d7-b45eeb80d9a4%40googlegroups.com
> 
> .
>

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

Re: Git plugin 5.0 require Jenkins 2.190.3

[Tim Jacomb]

You aren’t breaking anything so I don’t know why you would need to break it.

On Thu, 26 Mar 2020 at 21:29, Mark Waite  wrote:

>
> On Thu, Mar 26, 2020 at 3:17 PM Jesse Glick  wrote:
>
>> On Thu, Mar 26, 2020 at 10:47 AM Mark Waite 
>> wrote:
>> > No breaking changes in API's in the transition from current git client
>> plugin to git client plugin 5.0.  No breaking changes in API's in the
>> transition from current git plugin to git plugin 5.0.
>>
>> So why bother bumping the major version to begin with?
>>
>>
> Good question.  I assumed (possibly incorrectly) that a change of required
> Jenkins version would best be handled by increasing the major number.
>
> Increasing the major number is also a chance to reduce the confusion
> caused when users mistakenly decide to use git plugin 3.x with git client
> plugin 3.x.
>
> Is it a general practice that we can change the minimum Jenkins version
> without updating the major number?
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr035Sn9SKtVj9OE0JYvSYOx1oQE%3D9bg%3D6RxJYjem6N2wg%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/CAO49JtFjJ_HSWJxkvYJZ0Li8wWHUseFDczpBDd43wovjbQZ25w%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-3Biez6Z%2BREJWMgd%3Dd%3DV0UqkJkyU1eQmQbKTgE4%2B-_Y%2BpDrA%40mail.gmail.com.

Re: GitHub issues option in HOSTING

[Tim Jacomb]

That's cool Radek, was this what you used to migrate them?
https://github.com/parcelLab/jira-to-github

Or something else?

On Wed, 25 Mar 2020 at 16:27, Radek Antoniuk 
wrote:

> I would like to vote +1 for GitHub Issues.
>
> I tried migration via the API for jira plugin and the only thing that we
> would lose is the original reporter (it would be noted in the comment but
> not the issue creator) - I think that this can be lived with.
> See https://github.com/warden/jira-plugin/issues for examples (those were
> all automated via API).
>
> With the fact that we're not using fixVersion field and release
> process/board in JIRA (I don't think we need it TBH), I think that GH
> Issues would be more than enough.
> Additionally:
> - we could use GH Actions for automated label management, releases etc...
> - the users to use GH SSO only and not create special account in Jenkins
> - we lose performance problems with JIRA infra
> - we have a single and _automated_ code-to-issue linking on code-level even
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/94e85849-653a-4789-92a3-d84a7ca3e2ac%40googlegroups.com
> 
> .
>

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

Re: plugin patent 4.0

[Tim Jacomb]

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

On Thu, 26 Mar 2020 at 09:11, James Nord  wrote:

> Hi Oleg et al.
>
> is it time to move the plugin parent out of beta?
>
> have not seen any negative feedback (or positive door that matter) but
> I've been using it for numerous proprietary plugins with no issue.
>
> /James
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.com
> .
>

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

Re: plugin parent 4.0

[Tim Jacomb]

2.164.x is fine, the bom sample plugin is using it on this version

On Thu, 23 Apr 2020 at 08:53, Ullrich Hafner 
wrote:

>
>
> Am 23.04.2020 um 01:06 schrieb 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com>:
>
>  I'll update to 2.164, or tell dependabot to ignore this dep.
>
>
> I think you need to update to at 2.204 (I got errors for older versions).
> But it is also safe to ignore the plugin pom 4.x updates.
>
>
> On Wed, Apr 22, 2020 at 4:02 PM Oleg Nenashev 
> wrote:
>
>> There is a *"Note: Jenkins 2.164.x is the minimum supported version as
>> it's the first version that includes the Jenkins bom" *warning in
>> release notes
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.0
>> For older core versions we can still release the 3.x Plugin POM versions
>> on-demand.
>>
>> Best regards,
>> Oleg
>>
>> On Thu, Apr 23, 2020 at 12:47 AM 'Gavin Mogan' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> Are there version limits to the parent pom now? Is there a way to
>>> disable the bom stuff for older jenkins?
>>>
>>>
>>> https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgraphql-server-plugin/detail/dependabot%2Fmaven%2Forg.jenkins-ci.plugins-plugin-4.1/1/pipeline/
>>>
>>> Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not 
>>> find artifact org.jenkins-ci.main:jenkins-bom:pom:2.150.1 in incrementals 
>>> (https://repo.jenkins-ci.org/incrementals/)
>>>
>>>
>>>
>>>
>>> On Wed, Apr 22, 2020 at 5:42 AM Jesse Glick 
>>> wrote:
>>>
 On Wed, Apr 22, 2020 at 4:41 AM Ullrich Hafner <
 ullrich.haf...@gmail.com> wrote:
 >> occasions wasted plenty of time trying to track down cryptic
 `LinkageError`s caused by mismatched dependencies.
 >
 > Was that while developing plugins or core?

 Plugins.

 > even if the enforcer finds something during compile it might be
 totally different when deployed to a real Jenkins system.

 I was referring more to errors in tests. As noted in JENKINS-41827,
 some class loading scenarios can work in tests and break in production
 or vice-versa.

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0DFXCo1HH8xg2WfWfSAjM%3D2-U839%3D9365bw5Kxsu8%3DQQ%40mail.gmail.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/exd3fc9NUAg/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/CAG%3D_DuuNqxatsTiNXbrNpxnE%2B_mHZjwqxu9i3Qu5bTHhSP0Jig%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/CAPfivLDE2fwANgoBk5dGBW%2BA0Mq0GDdOPraziNtFoc%2BT2uC1GA%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_DusvB1sDb3wSwHFV2RK6JZKZsPAfTmcth18c%2Bh%2BCAn5Sgg%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/25823FF0-3E4A-41D1-A6DD-E98989E27F97%40gmail.com
> 
> .
>

-- 

Re: Plugin: Liquibase Runner

[Tim Jacomb]

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: LTS baseline selection for the successor of 2.222

[Tim Jacomb]

2.235 would also be my preference, I've got 2 (hopefully) last system read
PRs, I would love to get in before the LTS

On Wed, 29 Apr 2020 at 14:54, Daniel Beck  wrote:

>
>
> > On 29. Apr 2020, at 12:44, Oliver Gondža  wrote:
> >
> > In accordance we recently approved process changes, we are doing next
> baseline section two weeks earlier in the cycle.
>
> Assuming nobody merges something crazy into core this week, I'm for 2.235.
>
> We've moved the baseline decision earlier to give us the freedom to choose
> a very recent release without a lot of risk and overlapping work schedules,
> since we'll have 4 weeks to identify and fix problems and back port those
> fixes. So I propose we try this and see how it goes.
>
> (FWIW we probably want to figure out what to do about JENKINS-61937 before
> the new LTS lands…)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/900CA800-A7CB-486B-B49A-93DF05F30CB8%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/CAH-3BicEUb9i%2BD_x3FVsN914UumR8mGeKMFd_3%3D0zrAb%2BgrJaQ%40mail.gmail.com.

Re: Plugin: Liquibase Runner

[Tim Jacomb]

I would check you deploy credentials in your settings.xml as a first step,
it should be fairly quick to give you permission unless the job is broken

On Fri, 1 May 2020 at 14:15, Robert Reeves  wrote:

> Hi, Team!
>
>
>
> Thanks for accepting the PR to give my GitHub/Artifactory user access to
> release the plugin.
>
>
>
> My GitHub user is r2datical and accounts.jenkins.io user is r2datical.
> Same one I’ve used for the daticaldb plugin. I’ve logged into the
> Artifactory instance with that account. However, I’m getting the 403 error
> still:
>
>
>
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on
> project liquibase-runner: Failed to deploy artifacts: Could not transfer
> artifact org.jenkins-ci.plugins:liquibase-runner:hpi:1.3.0 from/to
> maven.jenkins-ci.org (https://repo.jenkins-ci.org/releases/):
> Authorization failed for
> https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/liquibase-runner/1.3.0/liquibase-runner-1.3.0.hpi
> 403 Forbidden -> [Help 1]
>
>
>
> Is this a timing thing or is there another step I need to perform?
>
>
>
> Thanks!
>
>
>
> Robert
>
>
>
>
>
> *From:* jenkinsci-dev@googlegroups.com  *On
> Behalf Of *Robert Reeves
> *Sent:* Wednesday, April 29, 2020 8:31 AM
> *To:* jenkinsci-dev@googlegroups.com
> *Cc:* Keith Collison ; Daniel Beck ;
> Nathan Voxland 
>
> *Subject:* RE: Plugin: Liquibase Runner
>
>
>
> Hi, Team! Just checking on the PR. As far as I can tell, it’s passed the
> checks. Slide asked me to attach the thread to the PR and I’ve done that.
> What’s next?
>
>
>
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1513
>
>
>
> Thanks!
>
>
>
> Robert
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CY4PR06MB2949FF0BF680C7D0FCC6FBEB83AD0%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/CY4PR06MB29491CACE61D32F8534DBA7383AB0%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-3BifU%3DK98L5rvvOfr43g5bgc_YORcMiOiraWAGJ4mJZ0Urw%40mail.gmail.com.

Re: Welcome GSoC 2020 students and mentors!

[Tim Jacomb]

Congrats to all selected, and good luck on your projects.

On Mon, 4 May 2020 at 19:12, Oleg Nenashev  wrote:

> Dear all,
>
> The GSoC 2020 projects have been announced by Google
> <https://summerofcode.withgoogle.com/organizations/4945163270488064/>. We
> are proud to announce that our organization got 7 project slots. In the
> next four months we will have 6 students working on Jenkins and one - on
> Jenkins X, all of the selected students have already made valuable
> contributions to the project. Please welcome them to the Jenkins
> organization!
>
>-
>
>Sladyn Nunes - Custom Jenkins distribution build service
>-
>
>Sumit Sarin - External Fingerprint storage for Jenkins
>-
>
>Rishabh Budhouliya - Git Plugin Performance Improvements
>-
>
>Kezhi Xiong - GitHub Checks API for Jenkins plugins
>-
>
>Loghi Perinpanayagam - Jenkins Machine Learning Plugin for Data Science
>-
>
>Buddhika Chathuranga - Jenkins Windows Services: YAML Configuration
>Support
>-
>
>Zixuan Liu - Jenkins X: Apps/Addons consolidation
>
>
> In addition to the newcomer students, we will have a number of experienced
> and newcomer contributors who will be mentoring Jenkins projects: Kristin
> Whetstone, Jeff Pearce, Xiaojie Zhao, Andrey Falko, Oleg Nenashev, Michael
> Cirioli, Mark Waite, Francisco Fernandez, Parichay Barpanda, Justin
> Harringa, Ayush Agarwal, Jon Brohauge, Tim Jacomb, Ulli Hafner, Sagar
> Utekar, Next Turn, Marky Jackson, Ioannis Moutsatsos, Shivay Lamba and
> Bruno Kinoshita. Same to the Jenkins X folks: Kara de la Marck, Nikhil Da
> Rocha, James Strachan, Sahil Kalra, Neha Gupta, and Oscar Medina. Welcome
> aboard!
>
> In the next few days we will be updating the Jenkins website and posting
> more information there. Official blog post will also be published this
> week. During the next 4 weeks project teams will be reaching out to
> potential stakeholders in order to establish connections and to get
> feedback regarding their project designs. If you have any
> comments/proposals/concerns, please join the project-specific discussions
> in the mailing lists once they start. We will appreciate any feedback and
> help with project onboarding and community bonding.
>
> Best regards,
>
> Jenkins GSoC org team
>
> P.S: Please see this announcement
> <https://groups.google.com/forum/#!topic/jenkinsci-gsoc-all-public/Gi5-I-1BYok>
> in the GSoC mailing list for more info
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/ce5cb2bf-352c-45ef-9010-62ead45b3d30%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/ce5cb2bf-352c-45ef-9010-62ead45b3d30%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/CAH-3BifW%3DYFskFRO9mwURkXys1Ou4mGGkJ5gW8%3DK3AmJq29zOQ%40mail.gmail.com.

Re: Governance and Jenkins is the Way on Jumbotron

[Tim Jacomb]

+1

On Tue, 5 May 2020 at 02:07, Mark Waite  wrote:

> The "Jenkins is the Way
> " blog post
> invites users to share their Jenkins stories.  I would like to see us
> highlight the collection and highlighting of Jenkins experiences even more.
>
> One way to highlight further is to add the "Jenkins is the Way" blog post
> to the Jumbotron on the front page of the jenkins.io site.  I've added it
> to the governance meeting agenda for this Wednesday.
>
> As one way of reducing time spent in the governance meeting on the topic,
> I'd like to gather comments from the mailing list prior to the meeting.
>
> Would you support including "Jenkins is the Way" in the Jumbotron rotation
> for a period of 30 - 45 days?
>
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/112ac905-7ddd-4961-a731-21c1e02fe0de%40googlegroups.com
> 
> .
>

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

Re: Next Jenkins weekly

[Tim Jacomb]

Couldn’t multiple instances run it?
It makes sense to me that release runs the the tests on the artifacts,

And also makes sense that ci.jenkins.io has tests that it’s working
(possibly it could have simpler tests and doesn’t need to run the full
acceptance tests set)

Thanks
Tim

On Fri, 24 Apr 2020 at 21:08, Mark Waite  wrote:

>
>
> On Fri, Apr 24, 2020 at 12:52 PM Jesse Glick  wrote:
>
>> On Fri, Apr 24, 2020 at 12:19 PM Mark Waite 
>> wrote:
>> > The test results aggregator plugin might help us combine test results
>> from multiple jobs into a single summary job.
>>
>> Or just combine them into one job.
>>
>>
> That is certainly an option and is worth discussion.
>
> The acceptance test jobs run on ci.jenkins.io because they don't need the
> added security provided by release.ci.jenkins.io.  They are using the
> publicly available Debian, CentOS, and OpenSUSE images to install the
> latest weekly Jenkins from the public repositories.  They are part of a
> repository that is also used to check that the ci.jenkins.io
> infrastructure is providing the expected agent labels and is executing jobs
> promptly.
>
> The build and package jobs run on release.ci.jenkins.io because they need
> credentials and permissions that we'd rather not include in ci.jenkins.io
> .
>
> We could move the acceptance test jobs to release.ci.jenkins.io but then
> they are no longer able to help us confirm the health of ci.jenkins.io.
>
> Mark Waite
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0BbRGafPyrCDukMdt8SQGdo4X2W8pgNOEzxHcbsqhE6A%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/CAO49JtFCuA9LmG7BW0sdDvrYinO9T8jGeYptwBnSwLFu69QuAQ%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-3BidMfABzCzVPs4RX2XRZWseEhzGTsPZ%2BUDQANyaJZ7kc%3Dw%40mail.gmail.com.

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

[Tim Jacomb]

+1

On Wed, 29 Apr 2020 at 10:51, Richard Bywater  wrote:

> I think its a good idea to make as many of the teams as possible that are
> needed to keep Jenkins trucking along official & documented so the proposal
> makes sense to me.
>
> I'm also interested in helping out the team to help spread the load around
> a bit.
>
> Richard.
>
> On Wed, 29 Apr 2020 at 21:09, 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
>>   
>> <https://www.jenkins.io/doc/developer/publishing/preparation/#look-for-similar-plugins>
>>   and offering to contribute there instead of hosting a new plugin (but 
>> not
>>   blocking hosting)
>>   - Plugin licenses (see this thread
>>   <https://groups.google.com/forum/#!topic/jenkinsci-dev/-KprgkVIDpQ>
>>   )
>>- Processing plugin release permissions in Repository Permission
>>Updater
>><https://github.com/jenkins-infra/repository-permissions-updater>.
>>There is a @jenkins-infra/hosting
>><https://github.com/orgs/jenkins-infra/teams/hosting> team handling
>>it (Alex Earl, Baptiste Mathus and me)
>>- Processing GitHub permission and Plugin adoption
>><https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/>
>>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 <https://www.jenkins.io/projects/infrastructure/ircbot/>
>>- Manual changes in GitHub repositories for some requests, e.g.
>>plugin renaming. There is a @jenkinsci/github-admins
>><https://github.com/orgs/jenkinsci/teams/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 @jenkinsci/github-admins
>><https://github.com/orgs/jenkinsci/teams/github-admins> team which
>>manages it
>>- Processing blacklisting and plugin tagging/doc URL requests in
>>/update-center2 <https://github.com/jenkins-infra/update-center2> for
>>non-security reasons. It is currently handled by Daniel Beck and a number
>>of other contributors
>>- Maintaining the Plugin hosting, publishing and governance
>>documentation in https://www.jenkins.io/doc/developer. Docs SIG is
>>doing some cleanup
>>
>> If we agree that we want to have a more official team, I will create a
>> new page on jenkins.io for

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

[Tim Jacomb]

+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
>>>   
>>> <https://www.jenkins.io/doc/developer/publishing/preparation/#look-for-similar-plugins>
>>>and offering to contribute there instead of hosting a new plugin
>>>   (but not blocking hosting)
>>>   - Plugin licenses (see this thread
>>>   <https://groups.google.com/forum/#!topic/jenkinsci-dev/-KprgkVIDpQ>
>>>   )
>>>- Processing plugin release permissions in Repository Permission
>>>Updater
>>><https://github.com/jenkins-infra/repository-permissions-updater>.
>>>There is a @jenkins-infra/hosting
>>><https://github.com/orgs/jenkins-infra/teams/hosting> team handling
>>>it (Alex Earl, Baptiste Mathus and me)
>>>- Processing GitHub permission and Plugin adoption
>>><https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/>
>>> 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
>>><https://www.jenkins.io/projects/infrastructure/ircbot/>
>>>- Manual changes in GitHub repositories for some requests, e.g.
>>>plugin renaming. There is a @jenkinsci/github-admins
>>><https://github.com/orgs/jenkinsci/teams/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 @jenkinsci/github-admins
>>><https://github.com/orgs/jenkinsci/teams/github-admins> team which
>>>manages it
>>>- Processing blacklisting and plugin tagging/doc URL requests in
>>>/update-center2 <https://github.com/jenkins-