Hi Josh, There are no hurt feelings and no offense was taken personally. Thanks for checking though!
I understand most of your reasoning for the push-back and do respect differences in opinions. I was not aware of similar capabilities available within ASF infra, nor of Travis' shortfalls. Based on the jira, Travis' 'popularity' and prior email discussion, it seemed that Travis was a go. Regardless, it was good learning and I got my hands dirty too. Hopefully, better prepared for onboarding to Yetus. I've already signed-up to give it a shot. The goal to get better insights into code-quality and to increase dev-productivity is more important that what tool gets used. My only ask would be to more open to incremental improvements. CodeCov reports were nice though. Is there an ASF equivalent? If not, do you know if Yetus CI would allow to generate reports and push them to CodeCov? I used JaCoCo plugin to instrument and generate reports, looks pretty similar to HBase. It's not clear where HBase reports get pushed or visualized though. Thanks, Priyank On Mon, Jun 24, 2019 at 12:53 PM Josh Elser <[email protected]> wrote: > > Thanks Geoffrey for standing in my defense > > Hopefully this is just a passing comment, not meant to be indicative of > hurt feelings but, as VP, I feel like I should address it. Sorry for > something the heavy-handedness to follow: > > The results of votes shouldn't be taken personally. Because they are > discrete values, they have the tendency to "feel bad". It's like seeing > a bad grade on a test, but the reality is that there's a very broad > spectrum of a reason that you might get a -1 on a vote. > > To this point, Andrew's suggestion that this shouldn't have been a vote > in the first place is a good one and would've avoided any hurt feelings. > I just want to make sure it's clear that my -1 was a terse way to say > the following: > > * Your proposal would reduce the efficacy of pre-commit testing (ITs not > being run _successfully_) > * Reliance on hardware we don't control is a major impediment to getting > consistently passing tests (lots of prior-art here, Andrew alludes to it > via the work done in HBase) > * We have a solution to integration testing on pull requests with the > same setup we have today > * I've seen lots of issues running non-trivial tests on Travis > (underpowered, again, as Andrew said) > > All of this is a long way to say: thanks for trying to make testing > better/faster in Phoenix, Priyank. I hope you're not discouraged by > going back to the drawing board. Feel free to ask for review/feedback > early and often. We're all here to make things better. We will sometimes > have differing opinions on how to get there, but this is natural and > human :) > > On 6/21/19 3:41 PM, Priyank Porwal wrote: > > Thanks Geoffrey for standing in my defense and Andrew for consensus > > suggestion! > > > > We can ignore the vote for now and continue the discussion though, which > is > > great. Hopefully it will lead us to some next steps; and maybe consensus. > > > > I'll explore HBase's usage of Yetus. Does anyone have suggestions to get > to > > auto-triggered build&test runs and coverage reports other than Yetus? > > > > Thanks, > > Priyank > > > > > > On Fri, Jun 21, 2019 at 11:18 AM Priyank Porwal <[email protected] > > > > wrote: > > > >> The IT do successfully start in Travis just fine, but Travis has a time > >> limit of 50 minutes for open-source projects, and Phoenix ITs run for > >> almost 3 hours. This limit is applied per 'job' and not to the complete > >> cycle. I did attempt to break down Phoenix ITs into multiple jobs, but > >> couldn't complete that due to lack of experience with Maven and other > >> plugins. Hence, I proposed to initiate the on-boarding process which > would > >> be no-op for existing Phoneix contributors. It is not yet ready to be a > >> replace ASK infra, at least not yet. > >> > >> Ignoring TravisCI and CodeCov specifically (I have no affinity or > >> anti-affinity to either), the aim was to get a similar experience - devs > >> publishing new PRs and/or pushing new commits to existing PRs should > >> trigger automated build and test-runs; and show code-coverage reports in > >> addition to test reports. Currently, devs are required to squash all > their > >> commits into a single one and upload patches to trigger test runs. Also, > >> there is no visibility into coverage info from our test runs. If Yetus > or > >> anything else in ASF infra can support that, I can attempt onboarding to > >> them. > >> > >> On Fri, Jun 21, 2019 at 10:49 AM Andrew Purtell <[email protected]> > >> wrote: > >> > >>> Travis is underpowered compared to ASF test infrastructure. Do the > >>> integration tests run there? > >>> > >>> Recommend using ASF infra and Yetus (yetus.apache.org). HBase > provides a > >>> completely worked example of how to integrate and use it for precommit. > >>> > >>> On Fri, Jun 21, 2019 at 12:15 AM Priyank Porwal < > [email protected]> > >>> wrote: > >>> > >>>> [Converting this thread to a community vote] > >>>> > >>>> I'd like to start Travis-CI and CodeCov integration after getting some > >>>> success with both on a fork in my personal account. Checkout - > >>>> https://github.com/priyankporwal/phoenix/pull/3 > >>>> > >>>> Things to note: > >>>> 1. TravisCI kicked-off as soon as the PR is created and/or new commits > >>> are > >>>> pushed. No additional developer action is necessary. > >>>> 2. Once completed, code-coverage report is uploaded to CodeCov which > >>>> produced a nice color-coded graph of different folders/files. Detailed > >>>> reports linked from the PR as well. > >>>> 3. Confirmed that compilation and test failures resulted in CI > flagging > >>> the > >>>> PR. > >>>> 4. Currently, TravisCI only runs unit-tests. "mvn verify" takes too > long > >>>> for it to be included in Travis' scipt stage (max allowed time per job > >>> is > >>>> 50 mins) - I made several attempts to break up the tests into several > >>> jobs, > >>>> but lack of maven skills prevented me from achieving that goal. > >>>> 5. Repo-admin permissions only needed to start this integration > >>> (one-time) > >>>> and thereafter, incremental improvements can be made via any regular > PR. > >>>> Perhaps folks with maven expertise can get to it sooner. > >>>> > >>>> Please vote on proceeding with the integration with TravisCI and > >>> CodeCov. > >>>> > >>>> Thanks, > >>>> Priyank > >>>> > >>>> > >>>> On Tue, May 28, 2019 at 2:54 PM Thomas D'Silva > >>>> <[email protected]> wrote: > >>>> > >>>>> I assume we want to run all the ITs. Whevenver a PR is created Travis > >>> CI > >>>>> will automatically runs all the tests > >>>>> and post the results to the PR. > >>>>> > >>>>> > >>>>> On Tue, May 28, 2019 at 2:08 PM Geoffrey Jacoby <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> I don't know much about this particular tool, but something like > >>> this > >>>>> would > >>>>>> be good. > >>>>>> > >>>>>> Our current toolchain, with HadoopQA needing a JIRA patch and our > >>> code > >>>>>> reviews mostly migrating to Github is really awkward to deal with, > >>> so > >>>>>> TravisCI's Github integration's a definite plus. > >>>>>> > >>>>>> An example of Tephra's integration is here[1]: and on TravisCI's > >>> home > >>>>>> page[2] they mention that open source projects are free. > >>>>>> > >>>>>> Assuming there are no licensing, scalability or implementation > >>> gotchas > >>>>> I'd > >>>>>> be a +1. > >>>>>> > >>>>>> Geoffrey > >>>>>> > >>>>>> [1] https://travis-ci.org/apache/incubator-tephra > >>>>>> [2] https://travis-ci.org/ > >>>>>> > >>>>>> On Tue, May 28, 2019 at 1:31 PM William Shen < > >>>> [email protected] > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> +1 It would be awesome to be able to do this. > >>>>>>> Any concerns if we choose to run long IT as part of this setup? > >>>>>>> > >>>>>>> On Tue, May 28, 2019 at 1:00 PM Pedro Boado <[email protected]> > >>>> wrote: > >>>>>>> > >>>>>>>> What IT would you suggest to run? Testsuite (including long IT) > >>>> takes > >>>>>>> ~2h. > >>>>>>>> > >>>>>>>> On Tue, 28 May 2019, 20:40 Thomas D'Silva, < > >>> [email protected] > >>>>>>>> .invalid> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> +1 I think its a great idea. This would make it easier for new > >>>>>>>> contributors > >>>>>>>>> to run tests > >>>>>>>>> and also make it easier for committers to verify a patch > >>> doesn't > >>>>>> break > >>>>>>>>> functionality. > >>>>>>>>> > >>>>>>>>> On Tue, May 28, 2019 at 12:34 PM Priyank Porwal < > >>>>>>> [email protected] > >>>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> What do you guys think about this work to setup Travis-CI > >>> and > >>>>>>>>> CodeCoverage > >>>>>>>>>> for Phoenix? The objective would be to run unit and > >>> integration > >>>>>> tests > >>>>>>>> on > >>>>>>>>>> each PR, show code-coverage reports and perhaps also do > >>>>> checkstyle > >>>>>>>> checks > >>>>>>>>>> (after initial scrubbing effort). This would help rid of > >>> manual > >>>>>> patch > >>>>>>>>>> uploads that we need currently, plus bring visibility into > >>> code > >>>>>>> health. > >>>>>>>>>> Thoughts? > >>>>>>>>>> > >>>>>>>>>> https://issues.apache.org/jira/browse/PHOENIX-4863 > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Priyank > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Andrew > >>> > >>> Words like orphans lost among the crosstalk, meaning torn from truth's > >>> decrepit hands > >>> - A23, Crosstalk > >>> > >> > > >
