[yast-devel] RFC: Updating Rubocop?
Hi all, Short version: see https://github.com/yast/yast-yast2/pull/859 Full version: The Rubocop version we currently use (0.41.2) is quite old (~2.5 years) and Github even reports a low severity security issue with this version [1]. So I'd like to propose upgrading the Rubocop to the latest version. I have created a RFC PR with the updated global configuration [2], but besides the option renames and specifying Ruby 2.5 there is nothing interesting. More interesting is the testing run in the "yast2" package (I deliberately used one of the biggest and oldest packages), see [3]. I have collected and commented some new checks which we should probably disable or at least discuss the default values. Of course, we can later fine tune the config per package, so if we decide to enable something globally we can still disable it in specific packages (even only for specific files, we can be less strict for the legacy Ruby YCP code). The newer version adds many more checks but either I find them useful so they should be enabled or at least I did not find a reason why they should be disabled. But feel free to discuss any issue not mentioned in the list. Also you might try running it in some other packages (yast2-storage-ng might be a good candidate), it might report other issues not present in yast2. But you need to install the gem manually with "gem install rubocop". No RPM yet, even devel:languages:ruby:extensions does not contain the latest one. RFC --- Please check PR [3] and discuss the possible issues there. Note ----- I started testing the upgrade with Rubocop 0.59.2 but in the meantime they released version 0.60.0. The change log [4] does not list any new checks or major changes so I expect the upgrade to 0.60.0 should be basically the same. (But maybe I'd wait with the upgrade a bit, usually after releasing the x.0 version they quite often release a bug fix version x.1 or even x.2 in few days/weeks ;-)) Integration =========== The Travis integration will be easy, we use Docker images and we install the Rubocop gem as RPM from YaST:Head. We can build a different version for Tumbleweed/Factory in OBS and keep the old version for 15.0 (and older). We run Rubocop only in Travis, that means the Jenkins autosubmission or OBS builds will not be affected by this change. Development ----------- The only problem is running Rubocop locally during development. Rubygems can be easily packaged to RPMs with multiversion support, you could install more versions in parallel. (This will possibly require a small fix in the current YaST:Head package.) The problem is how to distinguish which version to run in a Git checkout. We define "rake check:rubocop" task so we could modify it to somehow automatically find out which version to use. I think we could use a similar approach as we use for the osc target in Rakefile, something like: Yast::Tasks.rubocop_version "0.60.0" We would add this only in "master". For the backward compatibility we would assume version "0.41.2" if the option is not set so we do not have to touch all maintenance branches. Obviously if you run rubocop directly (without the rake wrapper) then you have to know which exact version to run, no magic. Any comments, ideas? [1] https://nvd.nist.gov/vuln/detail/CVE-2017-8418 [2] https://github.com/yast/yast-devtools/pull/134 [3] https://github.com/yast/yast-yast2/pull/859 [4] https://github.com/rubocop-hq/rubocop/blob/master/CHANGELOG.md#0600-2018-10-... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (1)
-
Ladislav Slezak