I believe newer updates on https://issues.apache.org/jira/browse/INFRA-19836
On Thu, Apr 16, 2020 at 11:39 PM Michał Walenia <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Should we scrape all past contributors and add them to the file? >>>>>>>>> >>>>>>>>> On Tue, Jan 14, 2020 at 11:18 AM Kenneth Knowles <[email protected]> >>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>> 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 < >>>>>>>>>>>> [email protected]> 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: [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> 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: [email protected] >>> >>> 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: [email protected] > > Unique Tech > Check out our projects! <https://www.polidea.com/our-work> >
