Re: Any plans for the github checks API?

[Sladyn Nunes]

+1
"ChatOps" triggers would be highly beneficial thereby letting the
github-branch-source to run the required checks on specific parts. Also
detailed reports from GitHub Checks could be published and maybe parsed as
required.


On Mon, Jan 27, 2020, 6:27 PM 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/8215b84f-fd28-4066-a8d6-473683a43282%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/CAC-Leqttb4%3DVhSnd%3DKLeq69GioC4mzmpyadcJUG0gdX9TN%3DbOw%40mail.gmail.com.

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

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: Expanding the Jenkins Core maintainers team

[Raihaan Shouhell]

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, at 13:01, Oleg Nenashev  wrote: 
>> > 
>> > TL;DR: I propose to expand the Jenkins Core maintainers team by 
>> inviting the most active code reviewers to the team. 
>> > 
>>
>> I'm all for adding more active maintainers, so +1. It's been nice 
>> actually getting reviews for submissions (and with this change they will 
>> even be green, not grey!). 
>>
>> 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. 
>>
>>
>> > • We ensure that there is a knowledge transfer process established to 
>> help new maintainers 
>> >   • We start doing regular office hours with Q and joint PR 
>> grooming/review sessions, e.g. every 2 weeks. I am ready to run such 
>> sessions 
>> >   • Maintainer guidelines and best practices are documented in the 
>> Jenkins core repo. We will gradually create this documentation together 
>> during KT sessions   
>>
>>
>> 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. 
>>
>>
>>

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

Re: Any plans for the github checks API?

[Raihaan Shouhell]

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.

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

[Michael Cirioli]

Tim,

I've added a section to our proposed JEP-223 
 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
>>  
>> 
>> .
>
>
> 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 

Re: JEPs & BDFL ~ KK

[Jesse Glick]

On Sun, Jan 26, 2020 at 4:28 PM Oleg Nenashev  wrote:
> [the JEP process] does not achieve its main purpose - facilitate the 
> community feedback, help JEP submitters to get their changes delivered, and 
> to ensure that all changes are net-positive for the Jenkins project and 
> beneficial for Jenkins users down the line.
> …
> JEP process is followed if there is no consensus OR there is major impact on 
> users (breaking changes)

I would draw the line very differently and say that the JEP _process_
is not so important as the JEP itself: it is a single clear document
explaining to future generations how a particular major design
decision in Jenkins was made and why, all with an easily remembered
handle “JEP-456”. There need not be any breaking changes involved or
lack of consensus. In fact if there is no consensus then there is no
point in having a numbered JEP at all: you should first work to refine
your idea with skeptics, or just defer it. (File a draft PR if you
want something to refer to.)

Echoing KK (I think!), JEP should be a tool which assists people who
are already comfortable working on Jenkins. Keep the “editor” role,
responsible for matters of form and administration; and merge
“sponsor”, “contributors”, “BDFL”, “BDFL delegate”, and “reviewer”
into a simple “author” who is responsible for submitting the JEP,
doing the implementation, and delivering it, or delegating pieces of
this as they see fit. The board would just be a last resort in case
someone is trying to push through an unpopular change, with or without
a JEP.

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

Re: Any plans for the github checks API?

[Oleg Nenashev]

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/8215b84f-fd28-4066-a8d6-473683a43282%40googlegroups.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
>>> 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