Re: [yast-devel] services and checks unification for yast modules

On 09/01/2016 09:22 AM, Josef Reidinger wrote:

On Wed, 24 Aug 2016 16:27:03 +0200 Josef Reidinger 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.

...

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).

...

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?

...

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? Well, two questions :-) Does it support C++? I'm trying to add my fork of libstorage-ng but it's taking ages.

...

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.

...

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. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org