Re: Jenkins job execution policy

[Kenneth Knowles]

I believe newer updates on https://issues.apache.org/jira/browse/INFRA-19836

On Thu, Apr 16, 2020 at 11:39 PM Michał Walenia 
wrote:

> Hi there,
> I'd like to revive the conversation a little. Last I heard in
> https://issues.apache.org/jira/browse/INFRA-19670 the Beam PMC were
> contacted by the INFRA team regarding a new Jenkins master only for the
> Beam project. How are we doing on that front? IIRC there was someone that
> volunteered to create a new master and experiment with it, but I'm not sure
> if this a trick of my memory or it really happened.
>
> Is Beam going to have its own Jenkins with different limitations from the
> main ASF Jenkins server? If yes, when can we expect it?
>
> Have a good day,
> Michal
>
> On Thu, Jan 16, 2020 at 1:11 PM Katarzyna Kucharczyk <
> ka.kucharc...@gmail.com> wrote:
>
>> Hi all,
>>
>> Thanks for starting this thread. I have another questions about this
>> policy change.
>>
>> I don't know If you also noticed that behaviour of Phrase Triggering
>> became really unpredictable since Policy changed. What usually happens is
>> that after "retest this please" command no tests running are shown on
>> github. After checking Jenkins they are started there.
>> Today I experienced the very same behaviour. But what's more after
>> "retest this please" finished i commented PR with "run seed job" what
>> triggered again whole tests with retesting.
>> This mainly extends review/triggering tests for someone and redundant
>> test runs what may drain resources for other users.
>>
>> Are also experiencing those strange behaviours? Or do you have any
>> solution how phrase trigger so it would behave correctly?
>>
>> Thanks,
>> Kasia
>>
>> On Wed, Jan 15, 2020 at 9:48 AM Michał Walenia <
>> michal.wale...@polidea.com> wrote:
>>
>>> 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 
>>> 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  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 
> 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  wrote:
>>
>>> Nice! I took a look at Beam Jenkins job properties (
>>> CommonJobProperties.groovy#L108-L111
>>> )
>>> and it uses 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 
>>> 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 
 wrote:

> Should we scrape all past contributors and add them to the file?
>
> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
> wrote:
>
>> Nice! This will help at least temporarily. We can see if it grows
>> too unwieldy. It is 

Re: Jenkins job execution policy

[Michał Walenia]

Hi there,
I'd like to revive the conversation a little. Last I heard in
https://issues.apache.org/jira/browse/INFRA-19670 the Beam PMC were
contacted by the INFRA team regarding a new Jenkins master only for the
Beam project. How are we doing on that front? IIRC there was someone that
volunteered to create a new master and experiment with it, but I'm not sure
if this a trick of my memory or it really happened.

Is Beam going to have its own Jenkins with different limitations from the
main ASF Jenkins server? If yes, when can we expect it?

Have a good day,
Michal

On Thu, Jan 16, 2020 at 1:11 PM Katarzyna Kucharczyk <
ka.kucharc...@gmail.com> wrote:

> Hi all,
>
> Thanks for starting this thread. I have another questions about this
> policy change.
>
> I don't know If you also noticed that behaviour of Phrase Triggering
> became really unpredictable since Policy changed. What usually happens is
> that after "retest this please" command no tests running are shown on
> github. After checking Jenkins they are started there.
> Today I experienced the very same behaviour. But what's more after "retest
> this please" finished i commented PR with "run seed job" what triggered
> again whole tests with retesting.
> This mainly extends review/triggering tests for someone and redundant test
> runs what may drain resources for other users.
>
> Are also experiencing those strange behaviours? Or do you have any
> solution how phrase trigger so it would behave correctly?
>
> Thanks,
> Kasia
>
> On Wed, Jan 15, 2020 at 9:48 AM Michał Walenia 
> wrote:
>
>> 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 
>> 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  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 
 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  wrote:
>
>> Nice! I took a look at Beam Jenkins job properties (
>> CommonJobProperties.groovy#L108-L111
>> )
>> and it uses 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 
>> 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  wrote:
>>>
 Should we scrape all past contributors and add them to the file?

 On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
 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 
> 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

Re: Jenkins job execution policy

[Katarzyna Kucharczyk]

Hi all,

Thanks for starting this thread. I have another questions about this policy
change.

I don't know If you also noticed that behaviour of Phrase Triggering became
really unpredictable since Policy changed. What usually happens is that
after "retest this please" command no tests running are shown on github.
After checking Jenkins they are started there.
Today I experienced the very same behaviour. But what's more after "retest
this please" finished i commented PR with "run seed job" what triggered
again whole tests with retesting.
This mainly extends review/triggering tests for someone and redundant test
runs what may drain resources for other users.

Are also experiencing those strange behaviours? Or do you have any solution
how phrase trigger so it would behave correctly?

Thanks,
Kasia

On Wed, Jan 15, 2020 at 9:48 AM Michał Walenia 
wrote:

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

> Nice! I took a look at Beam Jenkins job properties (
> CommonJobProperties.groovy#L108-L111
> )
> and it uses 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 
> 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  wrote:
>>
>>> Should we scrape all past contributors and add them to the file?
>>>
>>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
>>> 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 
 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 
> wrote:
>
>> I'm for going back to the status quo where anyone's PR ran the
>> 

Re: Jenkins job execution policy

[Michał Walenia]

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 
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  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  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  wrote:
>>>
 Nice! I took a look at Beam Jenkins job properties (
 CommonJobProperties.groovy#L108-L111
 )
 and it uses 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 
 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  wrote:
>
>> Should we scrape all past contributors and add them to the file?
>>
>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
>> 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 
>>> 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  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, 

Re: Jenkins job execution policy

[Kirill Kozlov]

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  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  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  wrote:
>>
>>> Nice! I took a look at Beam Jenkins job properties (
>>> CommonJobProperties.groovy#L108-L111
>>> )
>>> and it uses 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 
>>> 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  wrote:

> Should we scrape all past contributors and add them to the file?
>
> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
> 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 
>> 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  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
> 

Re: Jenkins job execution policy

[Luke Cwik]

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  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  wrote:
>
>> Nice! I took a look at Beam Jenkins job properties (
>> CommonJobProperties.groovy#L108-L111
>> )
>> and it uses 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  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  wrote:
>>>
 Should we scrape all past contributors and add them to the file?

 On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
 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 
> 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  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  | Software Engineer

 M: +48 791 432 002 <+48791432002>
 E: michal.wale...@polidea.com

 Unique Tech
 Check out our 

Re: Jenkins job execution policy

[Pablo Estrada]

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

> Nice! I took a look at Beam Jenkins job properties (
> CommonJobProperties.groovy#L108-L111
> )
> and it uses 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  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  wrote:
>>
>>> Should we scrape all past contributors and add them to the file?
>>>
>>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles 
>>> 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 
 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  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  | Software Engineer
>>>
>>> M: +48 791 432 002 <+48791432002>
>>> E: michal.wale...@polidea.com
>>>
>>> Unique Tech
>>> Check out our projects! 
>>>
>>

Re: Jenkins job execution policy

[Kai Jiang]

Nice! I took a look at Beam Jenkins job properties (
CommonJobProperties.groovy#L108-L111
)
and it uses 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  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  wrote:
>
>> Should we scrape all past contributors and add them to the file?
>>
>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles  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 
>>> 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  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  | Software Engineer
>>
>> M: +48 791 432 002 <+48791432002>
>> E: michal.wale...@polidea.com
>>
>> Unique Tech
>> Check out our projects! 
>>
>

Re: Jenkins job execution policy

[Pablo Estrada]

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

> Should we scrape all past contributors and add them to the file?
>
> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles  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 
>> 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  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  | Software Engineer
>
> M: +48 791 432 002 <+48791432002>
> E: michal.wale...@polidea.com
>
> Unique Tech
> Check out our projects! 
>

Re: Jenkins job execution policy

[Luke Cwik]

Should we scrape all past contributors and add them to the file?

On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles  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  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  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  | Software Engineer

 M: +48 791 432 002 <+48791432002>
 E: michal.wale...@polidea.com

 Unique Tech
 Check out our projects! 

>>>

Re: Jenkins job execution policy

[Kenneth Knowles]

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  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  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  | Software Engineer
>>>
>>> M: +48 791 432 002 <+48791432002>
>>> E: michal.wale...@polidea.com
>>>
>>> Unique Tech
>>> Check out our projects! 
>>>
>>

Re: Jenkins job execution policy

[Pablo Estrada]

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  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 
> 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  | Software Engineer
>>
>> M: +48 791 432 002 <+48791432002>
>> E: michal.wale...@polidea.com
>>
>> Unique Tech
>> Check out our projects! 
>>
>

Re: Jenkins job execution policy

[Luke Cwik]

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 
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  | Software Engineer
>
> M: +48 791 432 002 <+48791432002>
> E: michal.wale...@polidea.com
>
> Unique Tech
> Check out our projects! 
>

Jenkins job execution policy

[Michał Walenia]

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

M: +48 791 432 002 <+48791432002>
E: michal.wale...@polidea.com

Unique Tech
Check out our projects!