Hi Enrico, CURATOR-669 is not for code coverage but for reporting flaky tests and time consumption.
I come up with CURATOR-669 to understand what tests I should spend time on to improve their stability and efficiency. CURATOR-669 won't block PR from being merged but acts like flaky test reports in the Pulsar community, where I may focus on efficiency first. CURATOR-660, instead, I don't read test coverage reports, and we may bring the topic back when there is a sponsor from committers for that integration. Best, tison. Enrico Olivelli <[email protected]> 于2023年4月16日周日 22:03写道： > Tison, > > There is another open ticket about Code Coverage checks > > https://issues.apache.org/jira/browse/CURATOR-660 > > I think that we should define all together the problem that we want to fix > or the benefits that we want to achieve for our community. > > Usually I have seen successful integrations with code coverage tools only > for PR validation. > Checks like 'this patch did not lower too much the code coverage'. > > More than that is only noise for a community like ours. > > That said, as there are multiple points of view and requirements here I > would like to see what the community needs regarding tests code coverage > > Best regards > Enrico > > > Il Gio 13 Apr 2023, 05:45 tison <[email protected]> ha scritto: > > > Ref - https://github.com/apache/curator/pull/459 > > > > Recently, I noticed that Curator tests are sometimes flaky and consume > > considerable time. Thus I filed CURATOR-669 > > <https://issues.apache.org/jira/browse/CURATOR-669> to integrate with > NFRA > > provided https://ge.apache.org/ to have a test reports viewer figure out > > what tests should be improved. > > > > You can browse the result at > > > https://ge.apache.org/scans/tests?search.rootProjectNames=Apache%20Curator > > . > > > > I'm sending you this email requesting comments on whether we need such an > > integration. > > > > Looking forward to hearing from you. > > > > Best, > > tison. > > >
