Yes, this would be a good choice for the fixit. The tracking issue exists 
already too:

https://issues.apache.org/jira/browse/BEAM-1132

On 2020/05/26 14:00:00, Kenneth Knowles <k...@apache.org> wrote: 
> We tried coveralls (I also used it in a few past projects) and it did not
> really work for us. A service that I really like is codecov.io (and they
> have a chrome plugin to overlay coverage on PRs) but the granularity of
> GitHub permissions was a problem in the past (most GitHub apps require
> blanket "write" permission because finer granularity is not offered).
> 
> The truth is that the local coverage data/reports are quite usable
> HTML-based things and just need to be uploaded somewhere. The services are
> nice-to-have, and only really matter if they add something beyond a
> presentation of the data.
> 
> For a multi-module gradle project, the coverage data is per module. You
> will need to gather it together to get a holistic view. There are some
> gradle plugins to do this.
> 
> All of the above would be a good choice for the fixit week, perhaps?
> 
> Kenn
> 
> On Wed, May 20, 2020 at 9:41 AM Tyson Hamilton <tyso...@google.com> wrote:
> 
> > Hello,
> >
> > I noticed on the github page, there is a badge that reports 100% coverage.
> > This seems suspect, and sure enough after a couple clicks coverall shows
> > that only one file is tracked. A more interesting page is the Builds page
> > [1] that shows the impact of specific PRs.
> >
> > It would be really nice if there was a way to get a coverage breakdown for
> > Beam by directory, even nicer if that could be displayed like the
> > post-commit test coverage table (though that may be a bit much). I'd also
> > love to see these build coverage feel metrics in the actual PRs if possible.
> >
> > I'm not familiar with coverall, didn't find any information on cwiki
> > regarding the configuration for Beam, and was wondering if anyone has
> > information?
> >
> >
> > [1]: https://coveralls.io/repos/140391/builds
> >
> 

Reply via email to