@Romain - Idea/IntelliJ is great with Gradle, way better than Maven, and what I mean is that I have added enough hints that it works OOTB already. The rest of my instructions are just how you should override IntelliJ's defaults to have a proper dev env - mostly just about storing files outside the git clone.
@Łukasz - yea I just mean the ones that I find in my email and browsing https://builds.apache.org/view/A-D/view/Beam/ which are the ones you classify as "totally not working". I would love to disable these. On the subject of running things on a pending PR - we should not run postcommit jobs on PRs. We should make separate (optional) precommit jobs that run the same build commands. That will give a more clear history and allow trivial configuration of which jobs deserve alert emails and which are not a problem. This is easy but I've been waiting to do it after Gradle migration. On Thu, Mar 8, 2018 at 11:37 AM Lukasz Cwik <[email protected]> wrote: > Romain, would you like to host/plan/run the Gradle fixit day? > > On Thu, Mar 8, 2018 at 11:24 AM, Chamikara Jayalath <[email protected]> > wrote: > >> +1 for the general idea of fixit day/week for Gradle. >> >> Agree with what Łukasz said. Some of these performance tests are new and >> are flaky due to other issues that were discovered during the process of >> adding the test. >> >> I think the high level blocker is updating performance testing framework >> to use Gradle. This will involve adding Gradle-based logic for invoking >> PerfKitBenchmaker, for example [1], and updating PerfKitBenchmarker to >> issue a Gradle command for running the benchmark [2]. First task will be to >> find the work needed here and updating the relevant JIRA [3]. >> >> Thanks, >> Cham >> >> [1] >> https://github.com/apache/beam/blob/master/sdks/java/io/google-cloud-platform/pom.xml#L79 >> [2] >> https://github.com/GoogleCloudPlatform/PerfKitBenchmarker/blob/master/perfkitbenchmarker/beam_benchmark_helper.py >> [3] https://issues.apache.org/jira/browse/BEAM-3251 >> >> On Thu, Mar 8, 2018 at 3:10 AM Łukasz Gajowy <[email protected]> >> wrote: >> >>> 2018-03-07 22:29 GMT+01:00 Kenneth Knowles <[email protected]>: >>> >>>> >>>> Based on https://builds.apache.org/view/A-D/view/Beam/ and our failure >>>> spam level the performance tests are mostly not healthy anyhow. So is there >>>> any high level blocker to switching them or is it just someone sitting down >>>> with each one? >>>> >>>> >>> I thought I could share my point of view here as I am working on the >>> Performance Test part for a while now. I wouldn't say those are "mostly not >>> healthy". The situation is as follows: >>> >>> - totally not working: Python, Spark performance tests (don't know why, >>> I'm not maintaining those tests. Should we disable them?) >>> - flaky: the recently re-enabled JDBC Performance Test. It's seems to be >>> flaky mostly due to: https://issues.apache.org/jira/browse/BEAM-3798 >>> - working well, rarely failing: AvroIO, TextIO, Compressed Text, >>> TFRecordIO >>> >>> Also, some test failures are caused due to pending PRs (we sometimes run >>> concrete tests to check if PRs won't break them). This also causes failures >>> sometimes. >>> >>> I can help with switching the Performance tests to Gradle as this part >>> seems to be free to take. >>> >>> >>> Łukasz >>> >>> >
