[RFC] Integrate with ge.apache.org Gradle Enterprise server

[tison <wa...@gmail.com>]

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.

Re: [RFC] Integrate with ge.apache.org Gradle Enterprise server

[tison <wa...@gmail.com>]

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 <eo...@gmail.com> 于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 <wa...@gmail.com> 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.
> >
>

Re: [RFC] Integrate with ge.apache.org Gradle Enterprise server

[Enrico Olivelli <eo...@gmail.com>]

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 <wa...@gmail.com> 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.
>