Dne 24.8.2016 v 16:27 Josef Reidinger napsal(a): [...]
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
There are several possibilities how to avoid this: 1) first run plain "rubocop" to see what issues it finds, if the result are reasonable run "rubocop -a", if the first scan reports hundreds issues something is very likely wrong... 2) commit your current changes first, run "rubocop -a", check the diff, if ok amend the commit, if not you can easily revert the changes 3) use Overcommit [1][2], this is basically the same as 1) but the "rubocop" part is called automatically by git hooks and additionally it runs rubocop only on the changed files so it's way faster. [...]
travis build - https://travis-ci.org/yast/yast-yast2 - currently used only for ruby modules and in other projects in other languages
Travis uses a completely different distro on the nodes (Ubuntu 12.04 or 14.04) which makes troubles when your project requires the latest compiler, Ruby, some libraries... And you cannot build the final RPM there, you can never be sure that you did not make a typo in *.spec file...
jenkins build for pull requests - http://ci.opensuse.org/job/yast-registration-github-push/586//console - currently only in few yast modules
This actually builds commits in all branches, not the pull requests, that feature is still missing. This is one step forward to replace Travis to avoid issues mentioned above, but we are still not there. In the long term we should replace Travis by Jenkins.
coveralls - https://coveralls.io/r/yast/yast-yast2?branch=master - currently in few yast modules, do not support c++
Actually there is a C++ support, it's provided by an external tool, see [3]. But I haven't tried it... You mention some other services related to code coverage below, I think we should evaluate pros&cons of each of them and stick to one solution if possible. Coveralls looks good to me, but maybe the other tools have some advantages. We will probably need to do some research here...
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
codeclimate - https://codeclimate.com/github/yast/yast-yast2 - currently for few yast modules and other ruby projects, do not support c++
Code climate is a nice tool, I like the ability to compare branches. I you do some bigger changes you can check whether the code quality improves or not before merging it. So far it's not configured to set status in Github, but I'll try it to see how it works. Additionaly they recently released a browser plugin [4] which adds the results directly into the pages at Github, but I haven't tried it yet.
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
And what is your experience with that tool? That dashboard looks a bit puzzling to me, it says "Project Certification A" and "Code Style 100%" but if you click the "Project quality" tab in the right bottom part you will see even some grade "F" parts. But I was not able to get more details like which files/methods are bad...
inch - http://inch-ci.org/github/yast/yast-registration - checker for documentation coverage, currently used only in yast2-registration
This is a completely server side service, the setup is trivial and it does not depend on Travis or Jenkins. Yardoc itself reports the documentation coverage, but the nice inch feature is that it rather suggests the places which should be improved. And it also prioritizes the issues, e.g. documenting a public method is more important than documenting a private method. See the registration example. It's not a killer tool, but if you have some time and want to improve the code documentation it can help you to find the most problematic places. But maybe some other tools can help with this as well. What do you think about it?
pullreview - https://www.pullreview.com/github/yast/yast-registration/reviews/master - sends mails to lslezak, currently only used in yast2-registration
This is similar to codeclimate, but I do not see a real value here, the codeclimate UI looks better IMHO and provides better results. After some time I stopped checking it and I ignore it now. On the other hand it runs some additional/different checks when compared to codeclimate. But we should prefer a single tool, check the link and see if it is worth trying it more...
rubylint - https://github.com/yast/yast-yast2/pull/480 - checker for errors in ruby, currently only POC
IIRC it reported too many false positives, so until it becomes usable is should stay PoC and just keep an eye on it.
rubocop - https://github.com/yast/yast-yast2/blob/master/.rubocop.yml - currently used in many yast modules, but not all
It should be used everywhere ;-)
spellchecking - https://github.com/yast/yast-yast2/blob/master/.travis.yml#L10 - currently in few yast modules
Again, IMHO this should be used more often. It's a bit annoying that you need to put many unknown words to the custom dictionary (the specific technical terms we usually use might not be covered) but on the other hand it helped me to find quite a lot of typos already. # Overcommit And here I'm adding one more tool to the list - Overcommit. I already mentioned it at the beginning, see [1] and [2] for more details. I have been using it for several months and it looks good. The only issue I found is that currently the .overcommit.yml config files are not committed to Git. When I run "rake osc:build" it complains about extra file in the checkout. So I remove it. But when I need to do some more fixes and build the package several times then I can easily forget to restore the config file back and then overcommit uses the default configuration which does not include running rubocop or running the tests. The main reason for using it is gone. Therefore I'd like to submit the .overcommit.yml file to Git. If you do not want to use overcommit then simply do not install it. By default git does not run the hooks, you have to manually enable them in the local checkout. (And you can still disable it for a single commit via "OVERCOMMIT_DISABLE=1 git commit".) What do you think about it? Ladislav [1] http://blog.ladslezak.cz/2016/06/06/overcommit/ [2] https://github.com/brigade/overcommit [3] https://github.com/eddyxu/cpp-coveralls [4] https://codeclimate.com/browser-extension -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org