On Thu, 1 Sep 2016 10:39:08 +0200 Ancor Gonzalez Sosa <[email protected]> wrote:
> On 09/01/2016 09:22 AM, Josef Reidinger wrote: > > On Wed, 24 Aug 2016 16:27:03 +0200 > > Josef Reidinger <[email protected]> wrote: > > > >> Hi, > >> in last year we play a lot with different services and various > >> automatic checks for yast modules. I think it make sense that we > >> after SP2 and 42.2 branching start looking and discussing, what is > >> useful, what not and what is promissing. > >> Ideally if something is useful, then use it everywhere, if > >> something is not useful, then remove POC and if something is > >> promising, then try to invest time in its POC. > >> Reason why I mention it is, that I face it in last days few times, > >> e.g. that some modules do not use rubocop, so when I call rubocop > >> --auto-correct it basically destroy my changes, some modules do not > >> have spellchecker, so when we update in one module > >> CONTRIBUTING.md, it pass, but in other modules it cause crash as > >> osc vc do not pass spellchecker. > >> So I think we can start with discussion what is useful, what not > >> now, even before branching, so we can make conclusion and start > >> working on it. I will write down all projects I am aware of > >> together with its POC to see how it works. Feel free to react to > >> any project how you see it or add project if I forget any. > >> > >> projects: > > > > Hi, > > I do not see any response, so I will write my view and noone will > > object, I will start implementing it. > > Sorry. I forgot. > > First of all, I wonder about the relation of those hosted services > with our mid-term goal of having code quality and code coverage > history in a self-hosted fashion. > https://trello.com/c/TVjjdrkn/506-yast-metrics > > IMHO, it would be nice to use the exact same metric for that and for > checking incoming pull requests. So far, that means rubycritics for > ruby quality (the only locally-runnable that will offer a global > rate), simplecov for coverage and yardoc for documentation coverage. Well, we should at first discuss that goals, how to measure it and so on. And if we agreed on some tool and really invest time into its deployment, we should use it. Also that reports should be publicly visible so non-SUSE employees see metrics and we can have badges on github :) So this sounds like we probably should use some public cloud service for it? > > >> travis build - https://travis-ci.org/yast/yast-yast2 - currently > >> used only for ruby modules and in other projects in other > >> languages > > > > keep travis until jenkins one is ready > > +1. Keeping Travis alive is quite some work (it was an endless source > of pain for storage-ng), but we should not drop it before having > support for pull requests in our Jenkins setup. > > >> jenkins build for pull requests - > >> http://ci.opensuse.org/job/yast-registration-github-push/586//console > >> - currently only in few yast modules > > > > Until we can deploy it for all modules I suggest to keep it in POC > > state. > > This should probably be our main focus as a next step in this area. > With jenkins we can potentially check everything (rubocop, test > status, test coverage, documentation coverage with yardoc and test > quality with rubycritics). Most of these tools are less cool than > their hosted counterparts but, as already explained before, this > would align Jenkins (CI) with https://github.com/mvidner/metrics > (history view). well, what I am missing probably most is comments to github, that says something like "code coverage decrease by 0.07%", "documentation: +1 documented method, -2 undocumented method" or comments to code what is not so nice or comment to given line that it break rubocop rule ( which I found in some services and sees it very useful ). Maybe it can be also added to jenkins as github have public API, but it is non-trivial work, so we should be sure we have time to do it. If not, we should look for easy to deploy existing solutions. > > >> coveralls - https://coveralls.io/r/yast/yast-yast2?branch=master - > >> currently in few yast modules, do not support c++ > > > > my impression is that similar code coverage provide also code > > quality services, so we can drop this service and report coverage > > to quality service. > > Fine with me. > > >> codecov - > >> https://codecov.io/gh/yast/yast-bootloader/pull/355?src=pr and > >> https://codecov.io/gh/jreidinger/libstorage-ng/pull/1?src=pr - > >> currently only POC for bootloader and libstorage-ng > > > > C++ support is promissing for our C++ projects, so I think we should > > start checking coverage there. > > Doesn't this contradict the previous statement about using a quality > service to also check the coverage? yes, but I do not find any such C++ service, also there is not much tools for c++ for checking quality of code ( probably due to high complexity of c++ code ). > > >> codeclimate - https://codeclimate.com/github/yast/yast-yast2 - > >> currently for few yast modules and other ruby projects, do not > >> support c++ > > > > Currently codacy looks more promissing for me, as it integrate also > > test coverage ( so we have everything in place ). > > +1 > > >> codacy - > >> https://www.codacy.com/app/YaST_Team/yast-bootloader/dashboard > >> - similar to codeclimate, only POC for bootloader, can integrate > >> test coverage, comment pull requests > > > > I suggest to use this service to integrate all of it and due to its > > commenting ability. > > +1 > > Just one question, is there bi-directional sync between comments in > Github and in that thing or will we have different sets of comments in > each place? I do not get question. I expect we do not write comments in that service, only on github in pull requests. > > Well, two questions :-) Does it support C++? I'm trying to add my fork > of libstorage-ng but it's taking ages. no, Codacy supports JavaScript, Scala, Java, PHP, Python, CoffeeScript, CSS and Ruby so no perl and no c++. > > >> inch - http://inch-ci.org/github/yast/yast-registration - checker > >> for documentation coverage, currently used only in > >> yast2-registration > > > > as other services do not check this part I suggest to use it > > everywhere where service works. > > Jenkins + yardoc could do it. well, we need somehow parse it and track progress. > > >> pullreview - > >> https://www.pullreview.com/github/yast/yast-registration/reviews/master > >> - sends mails to lslezak, currently only used in > >> yast2-registration > > > > I think if we use codacy also for pull request commenting, then this > > one is duplicite. > > +1 > > >> rubylint - https://github.com/yast/yast-yast2/pull/480 - checker > >> for errors in ruby, currently only POC > > > > for me it is still not usable, so I propose to keep it as POC > > +1 > > >> rubocop - > >> https://github.com/yast/yast-yast2/blob/master/.rubocop.yml > >> - currently used in many yast modules, but not all > > > > Suggest to use it everywhere where applicable. > > +1 > > >> spellchecking - > >> https://github.com/yast/yast-yast2/blob/master/.travis.yml#L10 - > >> currently in few yast modules > > > > We should use it everywhere. > > +1 (although sometimes it's a little bit annoying). > > Cheers. Thanks for answers. Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
