Ivan Necas <[email protected]> writes: > Shimon Shtein <[email protected]> writes: > >>> expecing there will be foreman on `../foreman` and including >> `../foreman/.rubocop.yml`in the plugin >> I wanted to avoid hard assumptions about folders layout (since the task >> simply won't run at all if foreman folder is located elsewhere). > > It would be on plugin maintainers decision. > >> >>> using rubocop via running rake from the foreman repo >> Doesn't help for build automation - You can't enable automatic builds this >> way. > > Why? We already do this in REX > https://gitlab.cee.redhat.com/egolov/asciidoctor-ej/blob/vodafone-sat6/Vodafone-Satellite6-Capsule.adoc
Sry, the right link is https://github.com/theforeman/foreman_remote_execution/blob/master/lib/tasks/foreman_remote_execution_tasks.rake#L44 :) -- Ivan > >> >>> It would not need to require the downloading from outside. >> You are still downloading/refreshing foreman's repo. It's the same as >> getting the file by URL. > > It's not: you have the rubocop versioned and you can switch between > versions quickly. > >> >>> not needing to do anything with the current approach in the core >> If you are that concerned about core changes, we can always duplicate the >> file - core stays as is, and plugins are getting the file from development >> gem. It will just require a synchronization with the core once in a >> while. > > Not convinced about benefits of additional layer. > > -- Ivan > >> >> On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas <[email protected]> wrote: >> >>> [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.
