Shimon Shtein <ssht...@redhat.com> 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 > >> 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 <ine...@redhat.com> wrote: > >> ssht...@redhat.com 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 foreman-dev+unsubscr...@googlegroups.com. >> > 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 foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
