Thanks for adding the whitelist! I have the same issue as Kirill, the tests run when I push commits, phrase triggering works in a strange way - the jobs don't run after a comment, but after a push following the comment. Is there a ghprb config that was changed, limiting the range of github triggers for the jobs? Michal
On Wed, Jan 15, 2020 at 1:55 AM Kirill Kozlov <kirillkoz...@google.com> wrote: > Thanks for working on this! > > I have noticed that tests run for new PRs and force-pushed commits, but if > a test fails due to a flake I am unable to re-run it (ex: "Run Java > PreCommit"). > PR that has this issue: https://github.com/apache/beam/pull/10369. > Is this intended behaviour? > > - > Kirill > > On Tue, Jan 14, 2020 at 3:20 PM Luke Cwik <lc...@google.com> wrote: > >> 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> >>>>>>>>>> >>>>>>>>> -- 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>
