Hi Benoit, Thanks for your feedback.
I made some more effort regarding your feedback. My answers are inlined. > What is the impact on the build time? There is only 1 successful build on the PR. Its time is 4h50m which equals the longest recently build on the master branch. However, 1 sample can not say much about the impact IMO. > A quick review of your work on github led me to think that code coverage (especially the scala one) is under-evaluated. CF http://timezra.blogspot.com/2013/10/jacoco-and-scala.html It does not work sadly. The plugin is too old (10 years old) and based on the legacy Jacoco version 0.6.3 (the latest version is 0.8.9). The most important issue is that its repository artifact no longer exists. I see a PR trying to upgrade it to a newer version, but it has been stale for a few years. Actually, this plugin is a custom version of Jacoco that exposes some Scala filters (for better Scala coverage results) that are available on Jacoco. However, I do not see how to explicitly specify the filters: https://github.com/jacoco/jacoco/wiki/FilteringOptions > Would there be a way to connect it to github (code coverage badge, havea comment regarding code coverage) Jacoco has integration with some code coverage registries e.g Coveralls, Codecov... However, the biggest issue is managing the secret token to update the coverage result. If we manage our own CI for James, it would be easy to set a secret env on the CI. But it is not the case with Apache CI which we do not have much control. Quan Vào Th 6, 21 thg 4, 2023 vào lúc 15:22 Benoit TELLIER <btell...@apache.org> đã viết: > Hello Quan, > > Thanks for putting this effort together. > > This also gives us a glance at one quality metric. Your report shows a > code coverage of 72%. > > -> What is the impact on the build time? > > -> A quick review of your work on github led me to think that code > coverage (especially the scala one) is under-evaluated. > > CF http://timezra.blogspot.com/2013/10/jacoco-and-scala.html > > By taking into account that scala code coverage is under-evaluated it is > reasonable to think that Apache James code coverage is more in the > 80-85% range. Not bad! > > -> How accessible is the report? > > I see that it is accessible as an archive on Jenkins, as a build artifact. > > Would there be a way to connect it to github (code coverage badge, have > a comment regarding code coverage) > > Best regards, > > Benoit > > On 21/04/2023 09:56, Quan tran hong wrote: > > Hi folks, > > > > I think the code coverage report for James would be a helpful factor to > > acknowledge how good enough of the tests have been written and will be > > written. > > > > Therefore I am experimenting and working on a POC for this adoption. The > > first goal is to generate an aggregate report for James modules and then > > based on the result we can observe and discuss more about actions to take > > e.g: write more tests where are needed and helpful, or even set a code > > coverage level for some specific modules. > > > > Jira ticket: > > > https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3903?filter=allissues > > PR: https://github.com/apache/james-project/pull/1522 > > > > Feedback and opinions are very welcome on this topic. > > > > Best regards, > > > > Quan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
