You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Michał Walenia <mi...@polidea.com> on 2020/01/13 10:45:06 UTC
Jenkins job execution policy
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.walenia@polidea.com
Unique Tech
Check out our projects! <https://www.polidea.com/our-work>
Re: Jenkins job execution policy
Posted by Kenneth Knowles <ke...@apache.org>.
I believe newer updates on https://issues.apache.org/jira/browse/INFRA-19836
On Thu, Apr 16, 2020 at 11:39 PM Michał Walenia <mi...@polidea.com>
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.kucharczyk@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.walenia@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 <ki...@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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <
>>>>>>>>>> pabloem@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.walenia@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.walenia@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.walenia@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.walenia@polidea.com
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>
Re: Jenkins job execution policy
Posted by Michał Walenia <mi...@polidea.com>.
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.kucharczyk@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 <mi...@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 <ki...@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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@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.walenia@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.walenia@polidea.com
Unique Tech
Check out our projects! <https://www.polidea.com/our-work>
Re: Jenkins job execution policy
Posted by Katarzyna Kucharczyk <ka...@gmail.com>.
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 <mi...@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 <ki...@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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@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.walenia@polidea.com
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>
Re: Jenkins job execution policy
Posted by Michał Walenia <mi...@polidea.com>.
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 <ki...@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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@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.walenia@polidea.com
Unique Tech
Check out our projects! <https://www.polidea.com/our-work>
Re: Jenkins job execution policy
Posted by Kirill Kozlov <ki...@google.com>.
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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>>>>>>
>>>>>>>>> Unique Tech
>>>>>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>>>>>>
>>>>>>>>
Re: Jenkins job execution policy
Posted by Luke Cwik <lc...@google.com>.
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 <pa...@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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>>>>>
>>>>>>>> Unique Tech
>>>>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>>>>>
>>>>>>>
Re: Jenkins job execution policy
Posted by Pablo Estrada <pa...@google.com>.
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 <ji...@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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>>>>
>>>>>>> Unique Tech
>>>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>>>>
>>>>>>
Re: Jenkins job execution policy
Posted by Kai Jiang <ji...@gmail.com>.
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 <pa...@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 <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>>>
>>>>>> Unique Tech
>>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>>>
>>>>>
Re: Jenkins job execution policy
Posted by Pablo Estrada <pa...@google.com>.
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 <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>>
>>>>> Unique Tech
>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>>
>>>>
Re: Jenkins job execution policy
Posted by Luke Cwik <lc...@google.com>.
Should we scrape all past contributors and add them to the file?
On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles <ke...@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 <pa...@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.walenia@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.walenia@polidea.com
>>>>
>>>> Unique Tech
>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>>
>>>
Re: Jenkins job execution policy
Posted by Kenneth Knowles <ke...@apache.org>.
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 <pa...@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.walenia@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.walenia@polidea.com
>>>
>>> Unique Tech
>>> Check out our projects! <https://www.polidea.com/our-work>
>>>
>>
Re: Jenkins job execution policy
Posted by Pablo Estrada <pa...@google.com>.
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 <mi...@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.walenia@polidea.com
>>
>> Unique Tech
>> Check out our projects! <https://www.polidea.com/our-work>
>>
>
Re: Jenkins job execution policy
Posted by Luke Cwik <lc...@google.com>.
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 <mi...@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.walenia@polidea.com
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>