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
