Re: Proposal: Jenkins Core PR reviewers team

[Marky Jackson]

I am happy to be included and thank you Gavin

> On Feb 13, 2020, at 4:46 PM, 'Gavin Mogan' via Jenkins Developers 
>  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 jenkinsci-dev+unsubscr...@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 jenkinsci-dev+unsubscr...@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 jenkinsci-dev+unsubscr...@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 the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/04BD050C-4C95-4A65-AC85-38D2119D99EE%40gmail.com.

Re: Proposal: Jenkins Core PR reviewers team

['Gavin Mogan' via Jenkins Developers]

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 jenkinsci-dev+unsubscr...@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 jenkinsci-dev+unsubscr...@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 jenkinsci-dev+unsubscr...@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.

Re: 2.204.3 RC

[Mark Waite]

Thanks so much!

I think you'll need to backport
https://github.com/jenkinsci/jenkins/pull/4494 into the stable-2.204 branch
so that the Azure maven cache reference is removed.

On Thu, Feb 13, 2020 at 12:47 PM Oliver Gondža  wrote:

> My apology for slipping the scheduled date. I expect to have the RC out
> tomorrow.
>
> On 13/02/2020 20.37, Oleg Nenashev wrote:
> > Good question. I think we need feedback from Oliver Gondza about the
> > planned dates.
> > I have not heard anything about the date changes
> >
> > On Thursday, February 13, 2020 at 7:16:34 PM UTC+1, Raul Arabaolaza
> wrote:
> >
> > Hello all,
> >
> > According to the calendar the 2.204.3 RC should be out yesterday
> > Wednesday 12th, but it seems is not yet and there are no new commits
> > in the stable-2.204 branch since 16 days ago. Has it been delayed
> > for some reason?
> >
> > Regards
> >
> > --
> >
> > Raul Arabaolaza Barquin
> > Staff Software Engineer
> >
> > CloudBees, Inc.
> >
> >
> >
> > P: +34-637340429
> > E: rarab...@cloudbees.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/aefb4360-0a58-42e5-8f91-086df2da49d1%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/jenkinsci-dev/aefb4360-0a58-42e5-8f91-086df2da49d1%40googlegroups.com?utm_medium=email_source=footer
> >.
>
>
> --
> 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/6bc8920f-b5e6-f101-0d44-5000cecaae0f%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/CAO49JtGp71uBxW12xByig31Z-ygAHsgSvaXf5PL3p8_1r5MOYg%40mail.gmail.com.

Re: 2.204.3 RC

[Oliver Gondža]

My apology for slipping the scheduled date. I expect to have the RC out 
tomorrow.


On 13/02/2020 20.37, Oleg Nenashev wrote:
Good question. I think we need feedback from Oliver Gondza about the 
planned dates.

I have not heard anything about the date changes

On Thursday, February 13, 2020 at 7:16:34 PM UTC+1, Raul Arabaolaza wrote:

Hello all,

According to the calendar the 2.204.3 RC should be out yesterday
Wednesday 12th, but it seems is not yet and there are no new commits
in the stable-2.204 branch since 16 days ago. Has it been delayed
for some reason?

Regards

-- 


Raul Arabaolaza Barquin
Staff Software Engineer

CloudBees, Inc.



P: +34-637340429
E: rarab...@cloudbees.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/aefb4360-0a58-42e5-8f91-086df2da49d1%40googlegroups.com 
.



--
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/6bc8920f-b5e6-f101-0d44-5000cecaae0f%40gmail.com.

Re: 2.204.3 RC

[Oleg Nenashev]

// CC Oliver

On Thu, Feb 13, 2020 at 8:37 PM Oleg Nenashev 
wrote:

> Good question. I think we need feedback from Oliver Gondza about the
> planned dates.
> I have not heard anything about the date changes
>
> On Thursday, February 13, 2020 at 7:16:34 PM UTC+1, Raul Arabaolaza wrote:
>>
>> Hello all,
>>
>> According to the calendar the 2.204.3 RC should be out yesterday
>> Wednesday 12th, but it seems is not yet and there are no new commits in the
>> stable-2.204 branch since 16 days ago. Has it been delayed for some reason?
>>
>> Regards
>>
>> --
>>
>> Raul Arabaolaza Barquin
>> Staff Software Engineer
>>
>> CloudBees, Inc.
>>
>>
>>
>> P: +34-637340429
>> E: rarab...@cloudbees.com
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/M_RtDuDXtbU/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/aefb4360-0a58-42e5-8f91-086df2da49d1%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/CAPfivLBnrDB6kWXmfYJ9Ygo34buTG-PThipa5nNgZDiYdt5wfg%40mail.gmail.com.

Re: 2.204.3 RC

[Oleg Nenashev]

Good question. I think we need feedback from Oliver Gondza about the 
planned dates.
I have not heard anything about the date changes

On Thursday, February 13, 2020 at 7:16:34 PM UTC+1, Raul Arabaolaza wrote:
>
> Hello all,
>
> According to the calendar the 2.204.3 RC should be out yesterday Wednesday 
> 12th, but it seems is not yet and there are no new commits in the 
> stable-2.204 branch since 16 days ago. Has it been delayed for some reason? 
>
> Regards 
>
> -- 
>
> Raul Arabaolaza Barquin
> Staff Software Engineer
>
> CloudBees, Inc.
>
>
>
> P: +34-637340429
> E: rarab...@cloudbees.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/aefb4360-0a58-42e5-8f91-086df2da49d1%40googlegroups.com.

Re: About - Simple Pull Request Plugin

[Oleg Nenashev]

Hi Aytunc,

Your approach is quite similar to what is documented in my project idea.
I went a bit beyond w.r.t implementation options, but the approach you 
suggest is one of the most straightforward ways to implement Pipeline as 
YAML.

 - Develop a Converter which will convert yml files to legacy declarative 
> or scripted pipelines .
>
There is no legacy declarative or scripted pipelines :) . They keep 
evolving, and I do not think that YAML support is going to replace them 
anytime soon.
https://github.com/jenkinsci/simple-pull-request-job-plugin is an example 
of such converter.
The converter approach makes total sense as a standalone solution,

Develop a converter screen where uses can convert their declarative 
> pipelines to yaml or vice versa.
>
Would be great

 

On Wednesday, February 12, 2020 at 1:50:25 PM UTC+1, Aytunc Beken wrote:
>
> Hi Oleg,
>
> Thanks for the details. The projects which are proposed/developed are 
> similar what I want to achieve. However, approach may differ.
>
> What I planned was this:
>  - Develop a Converter which will convert yml files to legacy declarative 
> or scripted pipelines . 
>Reason: Just wanted not to interfere with the core pipeline mechanism. 
> A smart, well developed converter will be enough to make it work.
>  - Develop a converter screen where uses can convert their declarative 
> pipelines to yaml or vice versa. 
>Reason: Users should not spend time to convert their legacy pipelines. 
> UI converter will same lots of time.
>
> How these sounds for you ? Not sure how much it is parallel within your 
> mind.
>
> Thanks.
>
>
> On Wednesday, February 12, 2020 at 1:26:47 PM UTC+1, Oleg Nenashev wrote:
>>
>> UPD. I have officially submitted this project idea: 
>> https://groups.google.com/forum/#!topic/jenkins-pipeline-authoring-sig/Ko8KTEcK_vY
>>  
>> and jenkins-infra/jenkins.io#2849 
>> 
>>
>> Hi Aytunc, what would be your plan there? the GSoC project idea does not 
>> block anyone from working on this area, but it might make sense to sync-up 
>> with other interested contributors.
>>
>> Best regards,
>> Oleg
>>
>> On Monday, February 10, 2020 at 5:14:51 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> Hi,
>>>
>>> No ongoing work right now, but indeed there is a lot of interest in the 
>>> community.
>>> If you are interested to work on it, this is great!
>>>
>>> Actually I am planning to submit a follow-up project idea for Google 
>>> Summer of Code 2020. I have already referenced it in 
>>> https://gitter.im/jenkinsci/pipeline-authoring-sig , but I have not 
>>> announced it yet through official channels.
>>> The draft idea is here: 
>>> https://github.com/jenkins-infra/jenkins.io/blob/ff5527bb98f1b28159f88894c9abbe346eeaf3d2/content/projects/gsoc/2020/project-ideas/pipeline-as-yaml-experiment.adoc
>>> If you plan to work on this area in short-term, I will adjust my project 
>>> idea accordingly.
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Monday, February 10, 2020 at 11:05:01 AM UTC+1, Aytunc Beken wrote:

 Hi,

 I was planning to work on a new plugin for enabling Yaml files for 
 Pipelines. However I found this plugin and it looks similar.

 https://jenkins.io/blog/2018/07/17/simple-pull-request-plugin/

 Does any one knows about it? Does is still continues ? 

 Thanks. Regards

>>>

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

Pipeline-Authoring SIG Meetings Update

[Marky Jackson]

Hello Friends!
I just wanted to send out a meeting update regarding the regular 
Pipeline-Authoring SIG meeting times.

Our regular bi-weekly scheduled meeting time of Friday 9 AM PST is remaining 
and I am happy to announce we have added a second meeting time that is more 
EMEA friendly and that is bi-weekly on Thursday at 2 PM UTC starting on 
February 27, 2020.

The community calendar has been updated to reflect the meetings times. That 
link is https://jenkins.io/event-calendar/

If you have any questions, do not hesitate to reach out in the gitter channel 
https://gitter.im/jenkinsci/pipeline-authoring-sig

Look forward to seeing everyone!

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

2.204.3 RC

[Raul Arabaolaza]

Hello all,

According to the calendar the 2.204.3 RC should be out yesterday Wednesday
12th, but it seems is not yet and there are no new commits in the
stable-2.204 branch since 16 days ago. Has it been delayed for some reason?

Regards

-- 

Raul Arabaolaza Barquin
Staff Software Engineer

CloudBees, Inc.



P: +34-637340429
E: rarabaol...@cloudbees.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/CADm-baS-T-ankTJ_5Yi4nSnQqpXsW1ABBpBC09bgUTkc7bMrJA%40mail.gmail.com.

Re: Proposal: Expanding the Jenkins Core maintainers team

[Oleg Nenashev]

I have added Raihaan Shouhell , Matt Sicker 
, Tim Jacomb , Ramon Leon 
 and Evaristo Gutiérrez 
  to the core maintainers team.
Welcome aboard!

On Wednesday, February 12, 2020 at 12:44:34 PM UTC+1, Oleg Nenashev wrote:
>
> Hi all,
>
> Thanks to everyone who contributed to the maintainer guide!
> It is still under review in https://github.com/jenkinsci/jenkins/pull/4472, 
> but I believe the most critical feedback was addressed there.
> Is everyone is fine, I would like to proceed and to finally grant 
> permissions as it was suggested in the original email.
>
> Is anyone opposed to it?
>
> Best regards,
> Oleg
>
>
> On Tuesday, February 4, 2020 at 1:59:25 AM UTC+1, Oleg Nenashev wrote:
>>
>> Created a draft pull request with maintainer guidelines here: 
>> https://github.com/jenkinsci/jenkins/pull/4472
>> Would appreciate feedback
>>
>> On Tuesday, January 28, 2020 at 11:02:58 AM UTC+1, Oleg Nenashev wrote:
>>>
>>> Hi Raihaan,
>>>
>>> Yes, at least it is what our documentation says: *"If you work on 
>>> Jenkins core on behalf of your employer, your company needs to have CCLA in 
>>> place. Have CCLA printed, signed, scanned back to PDF, then send it to 
>>> jenkinsci-...@googlegroups.com  along with 
>>> your account on Jenkins ."*.  
>>> https://github.com/jenkinsci/infra-cla#corporate-cla
>>>
>>> So, if you work on the Jenkins core as your wok responsibilities, it 
>>> would need CCLA.
>>>
>>> If you do it during your spare time, it is not needed. Our ICLA covers 
>>> the end responsibility of a contributor to ensure the permissive license 
>>> anyway anyway in (4): "You represent that you are legally entitled to grant 
>>> the above license. If your employer(s) has rights to intellectual property 
>>> that you create that includes your Contributions, you represent that you 
>>> have received permission to make Contributions on behalf of that employer, 
>>> that your employer has waived such rights for your Contributions to the 
>>> Project, or that your employer has executed a separate Corporate CLA with 
>>> the Project.". There is "OR" in the end here.
>>>
>>> BR, Oleg
>>>
>>> On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote:

 I was under the impression that a CCLA has to be filed first, is my 
 assumption wrong?
 I'm currently in the process of getting that sorted out

 On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote:
>
> One thing to mention is that I will be traveling on Jan 29 ... Feb 08: 
> FOSDEM and then a business trip. This time my time will be really 
> limited, 
> and it is safe to assume that I will not be available to review and merge 
> pull requests. On the other hand, I also will unlikely be available for 
> timely Q After considering options, my preference was to add more 
> maintainers and to do the best efforts on the documentation fronts before 
> I 
> go off.
>
> Regarding the permissions, I am waiting for the Weekly release with 
> regression patches and for ICLA submission from Raihaan 
>
> I wonder about the methodology used here though. The data is 
>> objective, but do these numbers actually tell us something useful, other 
>> than that Gavin's recent (awesome) contributions to the project are 
>> elsewhere? This seems akin to counting lines of code changed as a proxy 
>> for 
>> productivity.
>>
> Be sure I recognize and hugely appreciate Gavin's contributions. At 
> the moment they just do not go into the Jenkins core, and hence Gavin was 
> not in my list for Core maintainers. If others would like to add Gavin to 
> the core maintainers team, I would be happy to support it. Regarding my 
> methodology, I just used the existing queries, they do not represent 
> quality of the reviews and other factors. If anyone wants to introduce 
> better metrics and to reconsider the list, be my guest :)
>
> I'd also like to recommend that we emphasize the need to evaluate the 
>> usefulness of contributions in the maintainer guidelines. Not all 
>> contributions make sense to merge, and even useful contributions might 
>> result in weird inconsistencies or even problems across the whole of 
>> Jenkins if accepted as submitted. There's some subjectivity here, but 
>> even 
>> if you tend to be lenient on such matters, please still consider these 
>> issues and don't simply focus on whether the code works in isolation; 
>> that's not how it's going to affect users.
>>
> Duly noted, I will add it explicitly to the maintainer docs
>  
> BR, Oleg
>
>
>
>
> On Saturday, January 25, 2020 at 11:44:10 PM UTC+1, Daniel Beck wrote:
>>
>>
>>
>> > On 21. Jan 2020, 

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

[Daniel Beck]

On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding <
chris+jenk...@chriskilding.com> wrote:

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

Given the way you wrote up this list, do you mean
https://plugins.jenkins.io/matrix-auth with the third item?

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

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

[Jesse Glick]

On Wed, Feb 12, 2020 at 12:50 PM Chris Kilding
 wrote:
> I have encountered the following solutions which seem relevant, but I know 
> very little about them:
>
> - Cloudbees RBAC plugin (commercial)

https://docs.cloudbees.com/docs/admin-resources/latest/plugins/rbac
a.k.a. `nectar-rbac`

> - Role Strategy Plugin

Also allows roles to be defined and then mapped to groups of users. At
a high level, the main difference in design (as I understand it) is
that `role-strategy` centralizes configuration at the system level,
using pattern matching rules to make access control decisions; whereas
`nectar-rbac` is oriented towards folder-level configuration (usually
adding, but potentially also suppressing, permissions from the parent)
and supports delegating further decisions to a folder-level
administrator.

More commonly used than either of these is the old `matrix-auth`,
which also got folder-level support a few years back, and has a
simpler configuration system (no concept of roles or synthetic
groups).

> - Jenkins permissions system

A pretty complicated topic, as I am sure the JEP-223 developers will
tell you! Very broadly, there is a `SecurityRealm` which defines
authenticated users (subjects); a set of `Permission`s which define
general operations (verbs); various `AccessControlled` objects such as
`Job`s; and an `AuthorizationStrategy` which is a factory for `ACL`s,
effectively granting or denying access to a given subject-verb-object
triplet.

https://jenkins.io/doc/developer/security/ gives a brief overview. We
need more depth.

> thoughts on how we might add concepts of folders and credentials to them

As noted, folders are already well integrated with access control, and
the authorization plugins can support plugin-contributed permissions.

There are a couple of permissions already defined in the `credentials`
plugin but I have never fully understood how they are intended to be
used in context and I suspect few administrators have managed to set
this up meaningfully. There is generally a lack of a clear notion in
Jenkins of how builds, as opposed to directly user-initiated actions,
should be authenticated and authorized, and in particular how this
ought to interact with stored credentials. The `authorize-project`
plugin offers one approach but it is not a good UX.

The overall goal of the JEP draft—to decouple access control decisions
about credential use from the physical storage layer—makes sense for
at least some cases. I am not convinced it is the most natural way to
consume Kubernetes credentials, since K8s has a native RBAC system and
the `kubernetes` plugin can interact with namespaces and service
accounts, though the existing `kubernetes-credentials-provider`
basically treats K8s `Secret`s as a monolithic store (it assumes the
Jenkins master process has permission to read them all) so you do no
worse by using Jenkins ACL to make finer-grained decisions.

I hope the above helped. I realize there are more questions than
answers here: design options need to be explored.

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

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

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

[Chris Kilding]

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