> It would be on plugin maintainers decision. What would be a maintainers decision? The fact that the task will run only on some setups? IMHO It's a bit annoying.
About the automation, my solution basically removes both foreman_remote_execution:rubocop and the enhancement (And deleting code is even better than writing one ;) ). Plus you get a straight forward way of running rubocop as a developer: You don't have to run a rake task from a parent project, you just run `rubocop` from your current folder. IMHO, It's simpler solution for devs... On Tue, Jan 24, 2017 at 6:37 PM, Ivan Necas <[email protected]> wrote: > 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.
