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 <kirillkoz...@google.com> >> wrote: >> >>> Thanks for working on this! >>> >>> I have noticed that tests run for new PRs and force-pushed commits, but >>> if a test fails due to a flake I am unable to re-run it (ex: "Run Java >>> PreCommit"). >>> PR that has this issue: https://github.com/apache/beam/pull/10369. >>> Is this intended behaviour? >>> >>> - >>> Kirill >>> >>> On Tue, Jan 14, 2020 at 3:20 PM Luke Cwik <lc...@google.com> wrote: >>> >>>> Does the approval list live beyond the lifetime of the jenkins machine >>>> (my initial impression is that the approval list disappears on Jenkins >>>> machine restart)? >>>> >>>> Also, I imagine that ASF wants an explicit way to see who is approved >>>> and who is denied which the plugin doesn't seem to allow. >>>> >>>> On Tue, Jan 14, 2020 at 3:11 PM Pablo Estrada <pabl...@google.com> >>>> wrote: >>>> >>>>> I've merged https://github.com/apache/beam/pull/10582 to unblock >>>>> existing contributors that are having trouble getting their PRs tested >>>>> without committer help. We can discuss Kai's suggestion. >>>>> >>>>> Looking at https://github.com/jenkinsci/ghprb-plugin, it seems like >>>>> the 'add to whitelist' comment adds contributors permanently to a >>>>> whitelist. This would have more immediate results than the .asf.yaml file. >>>>> It would be harder to track who has the privilege, but it doesn't sound >>>>> like that concerns us, right? >>>>> >>>>> Thoughts from others? >>>>> -P. >>>>> >>>>> On Tue, Jan 14, 2020 at 1:43 PM Kai Jiang <jiang...@gmail.com> wrote: >>>>> >>>>>> Nice! I took a look at Beam Jenkins job properties ( >>>>>> CommonJobProperties.groovy#L108-L111 >>>>>> <https://github.com/apache/beam/blob/54e610809c87bdfba6ab94a8462e513ae17936e3/.test-infra/jenkins/CommonJobProperties.groovy#L108-L111>) >>>>>> and it uses jenkinsci/ghprb-plugin >>>>>> <https://github.com/jenkinsci/ghprb-plugin>. >>>>>> It should support the feature of comment add to whitelist from >>>>>> committer on PR for adding new contributors to whitelist. >>>>>> Adding github account to asf yaml might be a little heavy if this >>>>>> approach works. Could we also test on this method? >>>>>> >>>>>> Best, >>>>>> Kai >>>>>> >>>>>> >>>>>> On Tue, Jan 14, 2020 at 1:16 PM Pablo Estrada <pabl...@google.com> >>>>>> wrote: >>>>>> >>>>>>> I've added all the PR authors for the last 1000 merged PRs. I will >>>>>>> merge in a few minutes. I'll have a follow up change to document this on >>>>>>> the website. >>>>>>> >>>>>>> On Tue, Jan 14, 2020 at 11:29 AM Luke Cwik <lc...@google.com> wrote: >>>>>>> >>>>>>>> Should we scrape all past contributors and add them to the file? >>>>>>>> >>>>>>>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles <k...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Nice! This will help at least temporarily. We can see if it grows >>>>>>>>> too unwieldy. It is still unfriendly to newcomers. >>>>>>>>> >>>>>>>>> Kenn >>>>>>>>> >>>>>>>>> On Tue, Jan 14, 2020 at 11:06 AM Pablo Estrada <pabl...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> ASF INFRA gave us a middle-ground sort of workaround for this by >>>>>>>>>> using .asf.yaml files. Here's a change to implement it[1], and >>>>>>>>>> documentation for the .asf.yaml file[2], as well as the relevant >>>>>>>>>> section >>>>>>>>>> for our case[3]. >>>>>>>>>> >>>>>>>>>> I'll check the docs in [2] well before pushing to merge, just to >>>>>>>>>> be sure we're not breaking anything. >>>>>>>>>> >>>>>>>>>> [1] https://github.com/apache/beam/pull/10582 >>>>>>>>>> [2] >>>>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories >>>>>>>>>> >>>>>>>>>> [3] >>>>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-JenkinsPRWhitelisting >>>>>>>>>> >>>>>>>>>> On Mon, Jan 13, 2020 at 3:29 PM Luke Cwik <lc...@google.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I'm for going back to the status quo where anyone's PR ran the >>>>>>>>>>> tests automatically or to the suggestion where users marked as >>>>>>>>>>> contributors >>>>>>>>>>> had their tests run automatically (with the documentation update >>>>>>>>>>> about how >>>>>>>>>>> link your github/jira accounts). >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 13, 2020 at 2:45 AM Michał Walenia < >>>>>>>>>>> michal.wale...@polidea.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> I wanted to decouple the conversation about solutions to the >>>>>>>>>>>> issue from job execution requests. >>>>>>>>>>>> We have 131 open PRs right now and 64 committers with job >>>>>>>>>>>> running privileges. From what I counted, more than 80 of those PRs >>>>>>>>>>>> are not >>>>>>>>>>>> authored by committers. >>>>>>>>>>>> I think that having committers answer testing and retesting >>>>>>>>>>>> requests is a temporary solution and a permanent one should be >>>>>>>>>>>> decided upon >>>>>>>>>>>> soon. While it's an inconvenience for contributors familiar with >>>>>>>>>>>> the >>>>>>>>>>>> workings of the project and the community, newcomers might be put >>>>>>>>>>>> off by >>>>>>>>>>>> the fact that the tests don't run automatically on their pull >>>>>>>>>>>> requests >>>>>>>>>>>> (this is an industry standard which IMO should be upheld also in >>>>>>>>>>>> Beam). The >>>>>>>>>>>> barrier of finding one of committers who is active and willing to >>>>>>>>>>>> trigger >>>>>>>>>>>> their tests can make the entry to the project more difficult. >>>>>>>>>>>> >>>>>>>>>>>> I believe that the solution proposed by Kenneth in the Jira >>>>>>>>>>>> thread https://issues.apache.org/jira/browse/INFRA-19670 is >>>>>>>>>>>> viable. The questions are: do we want to implement this idea and >>>>>>>>>>>> what needs >>>>>>>>>>>> to be done to do it? >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Michał >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Michał Walenia >>>>>>>>>>>> Polidea <https://www.polidea.com/> | Software Engineer >>>>>>>>>>>> >>>>>>>>>>>> M: +48 791 432 002 <+48791432002> >>>>>>>>>>>> E: michal.wale...@polidea.com >>>>>>>>>>>> >>>>>>>>>>>> Unique Tech >>>>>>>>>>>> Check out our projects! <https://www.polidea.com/our-work> >>>>>>>>>>>> >>>>>>>>>>> >> >> -- >> >> Michał Walenia >> Polidea <https://www.polidea.com/> | Software Engineer >> >> M: +48 791 432 002 <+48791432002> >> E: michal.wale...@polidea.com >> >> Unique Tech >> Check out our projects! <https://www.polidea.com/our-work> >> > -- Michał Walenia Polidea <https://www.polidea.com/> | Software Engineer M: +48 791 432 002 <+48791432002> E: michal.wale...@polidea.com Unique Tech Check out our projects! <https://www.polidea.com/our-work>
