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

Reply via email to