[email protected] writes: > As we all know, foreman core uses rubocop for enforcing style rules. Many > plugins, especially those that are in theforeman organization, use rubocop > too. > The problem is, that the rules are not unified between foreman core and > plugins. In addition to that when rubocop version changes in core, core's > rules change accordingly, but plugins remain often with the old ruleset for > no reason. > > I am suggesting inheriting foreman's ruleset as a base ruleset for plugins. > I have found two ways to accomplish that: > > 1. Rubocop has an option to inherit a remote URL [1] > > <https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url>, > > so we can point a plugin to github URL for foreman master ruleset [2] > > <https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml>. > > Advantages: it's simple. > Disadvantages: You have to be connected in order to download the file > (Although rubocop has caching mechanism for it) > 2. We can utilize another Rubocop config option: inheriting the settings > from a gem [3] > > <https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem>. > > This will require us to create a special development gem, that would be > used by foreman core and plugins. This gem will contain a proper ruleset. > I am a bit biased, since I have already started foreman_devel plugin [4] > <https://github.com/ShimShtein/foreman_devel> that should help plugin > developers in multiple tasks. > Advantages: It's a plugin that can do a lot more than just ruleset repo. > It's versioned properly. It's offline, once you have the gem installed. > Disadvantages: Extra gem. Installation is more complicated. Affects the > core too > > I would like to hear your opinions about the issue. Both whether you like > the basic idea of inheriting the same ruleset and if so, which is the > preferred way to go.
Another approach could be, in the .rubocop.yml of the plugin, expecing there will be foreman on `../foreman` and including `../foreman/.rubocop.yml`in the plugin and using rubocop via running rake from the foreman repo (we already have `rake foreman_remote_execution:rubocop` for example). I guess this assumption of the layout of plugin development is reasonable to make (it would work also with the CI). The benefits would be not needing to do anything with the current approach in the core (that I guess works for the core), while the plugins using it as base. It would not need to require the downloading from outside. Also it would take into account the versioning and we would not have issues with running rubocop against foreman/plugin stable branches, that I guess should stay with the configuration there was at the time of branching. -- Ivan > > Shim, > > > > [1] > https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url > [2] > https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml > [3] > https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem > [4] https://github.com/ShimShtein/foreman_devel > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
