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