I’m not too worried about that. I think people would learn pretty quickly. It hasn’t been an issue for the kubernetes community so I can’t imagine it being an issue for us. End-of-day, we only have a limited amount of compute power and this will increase the speed we merge the PR’s that have passed basic code quality checks.
On Thu, Oct 1, 2020 at 2:19 PM, Tomasz Urbaszek <turbas...@apache.org> wrote: I think I can agree. Especially with flaky tests, some contributors may be confused that some of the tests don't work on CI but work locally... Checking the code quality is good first step. Once there's a review we can start tests on CI. On the other hand, I can see people asking for starting the tests or being even more confused why some PRs have more CI builds than others... Cheers, Tomek On Thu, Oct 1, 2020 at 10:29 PM Daniel Imberman < daniel.imber...@gmail.com [daniel.imber...@gmail.com] > wrote: Hello all, With the recent uptick in airflow contribution and pull requests, I have a proposal that I hope will ensure that we do not find ourselves in a CI backlog hell. I noticed that on the Kubernetes project, pull requests do not run integration test until a committer submits a "ready to test" command to the CI bot. This step can prevent draft PRs or un-reviewed PRs from taking github CI resources. It is worth noting that with breeze's docker based testing system, users have the exact same testing capabilities locally as they would on our CI. I propose that we allow unverified PR's to run basic and static tests, but not perform the full test suite or integration test without first being reviewed. What does everyone think?
