We are online ! https://coveralls.io/github/apache/bookkeeper/
I will create issues in order to increase code coverage for 4.8 Enrico Il mar 27 feb 2018, 18:28 Enrico Olivelli <eolive...@gmail.com> ha scritto: > > > Il mar 27 feb 2018, 18:17 Aaron Coburn <acob...@amherst.edu> ha scritto: > >> Hello Enrico, >> >> I have a number of projects that make use of Coveralls.io< >> http://Coveralls.io>, and I believe that the only way to clean up or >> reset the build history of a project is to completely delete the project >> (in Coveralls.io<http://Coveralls.io>) and then re-add the repository. >> >> That is to say, someone with write access to the bookkeeper repository >> would need to go to the page at: >> https://coveralls.io/github/apache/bookkeeper/settings and click the >> "Delete repo" button at the bottom of the page. You should then be able to >> re-add the repository with a completely empty history. I don't know if >> INFRA would need to be involved, but that's the basic process. >> > > Thank you Aaron > Our repo is managed by ASF infra I will take a look > > Enrico > > >> Aaron >> >> >> >> On Feb 27, 2018, at 9:55 AM, Enrico Olivelli <eolive...@gmail.com<mailto: >> eolive...@gmail.com>> wrote: >> >> Everything is up and running. >> We have to clean up the history of the project on Coveralls.io< >> http://Coveralls.io> because of >> the strange integration with Jenkins. Coveralls.io<http://Coveralls.io> >> uses the build #n as ID >> for the history: as I started a new Jenkins Job now we re-started from #1 >> and the history is very messy. >> >> I can't find any solution, I have asked on Coveralls Plugin GitHub >> BugTracker. >> >> I will ask INFRA if no one objects, maybe they will reset the account >> and/or we will start from a brand new Coveralls.io<http://Coveralls.io> >> account >> >> If anyone has experience about Coveralls.io<http://Coveralls.io> please >> contact me >> >> Enrico >> >> 2018-02-23 10:21 GMT+01:00 Sijie Guo <guosi...@gmail.com<mailto: >> guosi...@gmail.com>>: >> >> Change lgtm. Merged. You are unblocked for updating the jenkins job. >> Please >> remember deleting the wip jenkins job after you update the jenkins dsl. >> >> - Sijie >> >> On Fri, Feb 23, 2018 at 1:12 AM, Enrico Olivelli <eolive...@gmail.com >> <mailto:eolive...@gmail.com>> >> wrote: >> >> Patch is ready forto review >> https://github.com/apache/bookkeeper/pull/1129 >> >> Once all is working okay in master I will submit patch for standard >> jenkins >> job >> >> Il lun 19 feb 2018, 10:45 Sijie Guo <guosi...@gmail.com<mailto: >> guosi...@gmail.com>> ha scritto: >> >> On Mon, Feb 19, 2018 at 12:23 AM, Enrico Olivelli <eolive...@gmail.com >> <mailto:eolive...@gmail.com> >> >> wrote: >> >> News: >> I am struggling to create an aggregate code coverage report, but >> actually I >> have troubles with (I suspect) PowerMock, which is changing classes >> at >> runtime. >> >> The goal of an aggregate report is to consider in the report test >> cases >> which "test" classes which are not bundled within the same maven >> project. >> >> After running thru the codebase many times I have some points: >> - there is no much value in having unit tests which test code outside >> the >> same module and it is a bad practice >> - bookkeeper does not contain many cases (I cannot directly find any, >> but I >> did not spend time on this), I think that most of the cases are about >> classes moved to utility modules. >> >> Given these points I think we can step over the 'aggregate code >> coverage >> report" and move forward with 'classic' code coverage reporting for >> Maven/JaCoCo: each module report must be self contained, >> With this approach we are at 72% code coverage (given Coverall.io< >> http://Coverall.io> >> KPIs) >> and >> there is already much work to do in order to tidy up our codebase. >> >> So my proposal: >> - setup a definitive code coverage system, with classic code-coverage >> report >> - tidy up (during 4.8) >> - when we are okay we can see if there is real need to introduce >> multi-project report (I hope it won't be needed after tidying up) >> >> If my proposal is good I will clean up the patch: >> - remove aggregate reporting >> - enable the report on DL part of code base >> >> - submit patch for review >> >> Then once the patch is merged: >> - setup final CI test jobs >> - submit patch for final Jenkins CI jobs using Jenkins DSL >> >> Thoughts ? >> >> >> sgtm. >> >> >> >> >> Enrico >> >> 2018-02-15 13:47 GMT+01:00 Sijie Guo <guosi...@gmail.com<mailto: >> guosi...@gmail.com>>: >> >> ack >> >> On Thu, Feb 15, 2018 at 2:15 PM, Enrico Olivelli < >> eolive...@gmail.com<mailto:eolive...@gmail.com>> >> wrote: >> >> Il mer 14 feb 2018, 23:35 Sijie Guo <guosi...@gmail.com<mailto: >> guosi...@gmail.com>> ha >> scritto: >> >> Well done, Enrico! >> >> It seems the CI job seems to be ready to get in. Can you make >> the >> Jenkins >> job as part of .test-infra? >> >> >> No, it s not working well. >> I am working on a new maven module which will aggregate the >> reports >> of >> all >> upstream projects but actually it is failing. I have some idea >> but >> not >> much >> time, I am moving on but it will time some other iteration >> >> Enrico >> >> >> - Sijie >> >> On Thu, Feb 15, 2018 at 5:55 AM, Enrico Olivelli < >> eolive...@gmail.com<mailto:eolive...@gmail.com>> >> wrote: >> >> I have to clean up the patch but actually code coverage >> report >> makes >> sense >> and it is reporting a 72% code coverage (using coveralls.io< >> http://coveralls.io> >> KPI). >> Most cases of non covered code are about: >> - classes which do not have test cases in the same module (I >> am >> working >> on >> this) >> - classes which are not abstact but contains only constants >> or >> utility >> methods >> - interfaces, default methods >> - Circe and NativeIO >> >> Please note that generated code like protobuf, nar or lombok >> is >> already >> excluded in the current WIP patch. >> >> See https://coveralls.io/builds/15432041 >> >> I think that with little work we can fill most of the gaps, >> at >> least >> cleaning up the noise. >> >> I need to finish the work about classes not tested in the >> same >> package >> then >> we will be able to draw a roadmap, creating subtask for >> missing >> test >> cases, >> cleaning up interfaces..... >> >> Enrico >> >> Il dom 11 feb 2018, 17:43 Enrico Olivelli < >> eolive...@gmail.com<mailto:eolive...@gmail.com> >> >> ha >> scritto: >> >> Created this job on CI >> >> https://builds.apache.org/job/ >> bookkeeper-code-coverage-wip/ >> >> I am working on a way to create a better report, using this >> suggestion >> >> http://www.lorenzobettini.it/2017/02/jacoco-code-coverage- >> and-report-of-multiple-eclipse-plug-in-projects/ >> >> Build takes really long time with JaCoCo instrumentation, >> so >> I >> will >> use >> Apache CI >> >> Enrico >> >> >> 2018-02-07 17:24 GMT+01:00 Enrico Olivelli < >> eolive...@gmail.com >> : >> >> >> >> 2018-02-05 22:33 GMT+01:00 Sijie Guo <guosi...@gmail.com >> : >> >> On Mon, Feb 5, 2018 at 1:04 PM, Enrico Olivelli < >> eolive...@gmail.com >> >> wrote: >> >> Il lun 5 feb 2018, 18:11 David Rusek <d...@streaml.io> >> ha >> scritto: >> >> It sounds like we didn't do anything with the info >> for >> a >> long >> time. >> Enrico, >> I'm glad you're looking at it! Are you planning on >> filing >> some >> issues >> related to interpreting the coverage data and >> improving >> it? >> >> >> >> It was long time ago when I started to experiment with >> bookkeeper >> codebase. >> We had some problems and I had other priorities. >> I will try to resume this thread on next weeks I think >> that >> the >> culprit of >> our problems was the way we were performing BC tests. >> I have not much time so I will go on one step at a >> time, >> if >> you >> have >> time >> any help is appreciated. >> >> First step will be to test locally jacoco and then to >> restore >> the >> CI >> jobs >> >> >> just one suggestion when you are trying to restore CI >> jobs, >> please >> start >> with a separate CI job and let the CI job run for a while >> to >> ensure >> it >> doesn't have any side efforts before enforcing it on the >> other >> jobs. >> >> >> >> Create a new PR to upgrade Code Coverage configuration >> https://github.com/apache/bookkeeper/pull/1129 >> >> This is an example of current master report: >> https://coveralls.io/jobs/33538314 >> >> we are at 61 % (using default metrics) >> >> Enrico >> >> >> >> >> Ideally I would like to have some automated way to keep >> an >> eye >> on >> BK >> and >> maybe (not sure it is a big deal) to perform code >> coverage >> analysis >> even on >> PRs. >> >> One big problem is that our corpus of tests is very >> heavy >> as >> most >> of >> the >> tests start a new cluster. >> Recently we started to use mockito in order to perform >> narrower >> unit >> testing. >> >> Stay tuned >> >> Enrico >> >> Enrico >> >> >> -Dave >> >> >> >> -- >> >> >> -- Enrico Olivelli >> >> >> -- >> >> >> -- Enrico Olivelli >> >> >> >> >> -- >> >> >> -- Enrico Olivelli >> >> >> >> -- > > > -- Enrico Olivelli > -- -- Enrico Olivelli
