Re: MXNet Bot Demo

I tried to gather some data for us to discuss this topic in this thread. I tried to count number of un-necessary builds by looking at most recent (as of 12, March 9 PM PST) 50 PRs merged to master and 50 PRs. Identifying un-necessary builds is bit subjective. I tried to be more conservative where

Re: MXNet Bot Demo

Is it possible for re-triggering a single job to be abused? For example, the author spends two days re-triggering a flaky job to make it pass. But other jobs which have passed the validation may be broken by other commits during the two day without being noticed. And finally the PR is merged with

Re: MXNet Bot Demo

In the end it only comes down to money, considering that the system is auto scaling, making the execution time constant. If we're trading money for usability, I certainly would prefer usability. I'd rather recommend to spend time on parallelizing test execution or getting rid of integration tests

Re: MXNet Bot Demo

Btw you forgot to set a date and time for the metting On Thu, Mar 12, 2020 at 10:18 PM Marco de Abreu wrote: > Thanks Chai, I generally like the idea of the bot. But I'm not a supporter > of the idea to disable any automatic triggering (disabling the webhook is > also not an option,

Re: MXNet Bot Demo

Thanks Chai, I generally like the idea of the bot. But I'm not a supporter of the idea to disable any automatic triggering (disabling the webhook is also not an option, considering that this will disable master triggers). The CI system has to support the community without requiring people to

Re: MXNet Bot Demo

Chai, Awesome work. When do we expect this bot to be deployed? Best, Lin On Thu, Mar 12, 2020 at 2:00 PM Chaitanya Bapat wrote: > Hello MXNet community, > > I have built an MXNet Bot that allows PR > Authors, Committers and Jenkins Admins to trigger CI

MXNet Bot Demo

Hello MXNet community, I have built an MXNet Bot that allows PR Authors, Committers and Jenkins Admins to trigger CI manually. It handles 2 problems 1. Manual CI trigger instead of existing automated CI trigger 2. Gives permissions to PR Authors (in addition to

Re: Workflow proposal

+1 to Leonard’s suggestion for just staging individual PRs and running nightly tests. This seems like a good compromise between maintaining stability (keeping master from failing as often) and responsibility (nightlies failing on a single PR are the responsibility of the PR author only). This

Re: Workflow proposal

The biggest issue in an open source project in my opinion is to find someone responsible for keeping these two branches in sync. And I don't mean technically but in the sense of somebody who chases after the issues that arise in that develop branch. Looking at this situation today, we regularly