Does the approval list live beyond the lifetime of the jenkins machine (my initial impression is that the approval list disappears on Jenkins machine restart)?
Also, I imagine that ASF wants an explicit way to see who is approved and who is denied which the plugin doesn't seem to allow. On Tue, Jan 14, 2020 at 3:11 PM Pablo Estrada <pabl...@google.com> wrote: > I've merged https://github.com/apache/beam/pull/10582 to unblock existing > contributors that are having trouble getting their PRs tested without > committer help. We can discuss Kai's suggestion. > > Looking at https://github.com/jenkinsci/ghprb-plugin, it seems like the > 'add to whitelist' comment adds contributors permanently to a whitelist. > This would have more immediate results than the .asf.yaml file. It would be > harder to track who has the privilege, but it doesn't sound like that > concerns us, right? > > Thoughts from others? > -P. > > On Tue, Jan 14, 2020 at 1:43 PM Kai Jiang <jiang...@gmail.com> wrote: > >> Nice! I took a look at Beam Jenkins job properties ( >> CommonJobProperties.groovy#L108-L111 >> <https://github.com/apache/beam/blob/54e610809c87bdfba6ab94a8462e513ae17936e3/.test-infra/jenkins/CommonJobProperties.groovy#L108-L111>) >> and it uses jenkinsci/ghprb-plugin >> <https://github.com/jenkinsci/ghprb-plugin>. >> It should support the feature of comment add to whitelist from committer >> on PR for adding new contributors to whitelist. >> Adding github account to asf yaml might be a little heavy if this >> approach works. Could we also test on this method? >> >> Best, >> Kai >> >> >> On Tue, Jan 14, 2020 at 1:16 PM Pablo Estrada <pabl...@google.com> wrote: >> >>> I've added all the PR authors for the last 1000 merged PRs. I will merge >>> in a few minutes. I'll have a follow up change to document this on the >>> website. >>> >>> On Tue, Jan 14, 2020 at 11:29 AM Luke Cwik <lc...@google.com> wrote: >>> >>>> Should we scrape all past contributors and add them to the file? >>>> >>>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles <k...@apache.org> >>>> wrote: >>>> >>>>> Nice! This will help at least temporarily. We can see if it grows too >>>>> unwieldy. It is still unfriendly to newcomers. >>>>> >>>>> Kenn >>>>> >>>>> On Tue, Jan 14, 2020 at 11:06 AM Pablo Estrada <pabl...@google.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> ASF INFRA gave us a middle-ground sort of workaround for this by >>>>>> using .asf.yaml files. Here's a change to implement it[1], and >>>>>> documentation for the .asf.yaml file[2], as well as the relevant section >>>>>> for our case[3]. >>>>>> >>>>>> I'll check the docs in [2] well before pushing to merge, just to be >>>>>> sure we're not breaking anything. >>>>>> >>>>>> [1] https://github.com/apache/beam/pull/10582 >>>>>> [2] >>>>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories >>>>>> >>>>>> [3] >>>>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-JenkinsPRWhitelisting >>>>>> >>>>>> On Mon, Jan 13, 2020 at 3:29 PM Luke Cwik <lc...@google.com> wrote: >>>>>> >>>>>>> I'm for going back to the status quo where anyone's PR ran the tests >>>>>>> automatically or to the suggestion where users marked as contributors >>>>>>> had >>>>>>> their tests run automatically (with the documentation update about how >>>>>>> link >>>>>>> your github/jira accounts). >>>>>>> >>>>>>> On Mon, Jan 13, 2020 at 2:45 AM Michał Walenia < >>>>>>> michal.wale...@polidea.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> I wanted to decouple the conversation about solutions to the issue >>>>>>>> from job execution requests. >>>>>>>> We have 131 open PRs right now and 64 committers with job running >>>>>>>> privileges. From what I counted, more than 80 of those PRs are not >>>>>>>> authored >>>>>>>> by committers. >>>>>>>> I think that having committers answer testing and retesting >>>>>>>> requests is a temporary solution and a permanent one should be decided >>>>>>>> upon >>>>>>>> soon. While it's an inconvenience for contributors familiar with the >>>>>>>> workings of the project and the community, newcomers might be put off >>>>>>>> by >>>>>>>> the fact that the tests don't run automatically on their pull requests >>>>>>>> (this is an industry standard which IMO should be upheld also in >>>>>>>> Beam). The >>>>>>>> barrier of finding one of committers who is active and willing to >>>>>>>> trigger >>>>>>>> their tests can make the entry to the project more difficult. >>>>>>>> >>>>>>>> I believe that the solution proposed by Kenneth in the Jira thread >>>>>>>> https://issues.apache.org/jira/browse/INFRA-19670 is viable. The >>>>>>>> questions are: do we want to implement this idea and what needs to be >>>>>>>> done >>>>>>>> to do it? >>>>>>>> >>>>>>>> Regards >>>>>>>> Michał >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Michał Walenia >>>>>>>> Polidea <https://www.polidea.com/> | Software Engineer >>>>>>>> >>>>>>>> M: +48 791 432 002 <+48791432002> >>>>>>>> E: michal.wale...@polidea.com >>>>>>>> >>>>>>>> Unique Tech >>>>>>>> Check out our projects! <https://www.polidea.com/our-work> >>>>>>>> >>>>>>>
