Shimon Shtein <[email protected]> writes: >> 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...
That is matter of opinion: people already need to run unit tests from the foreman directory. Anyway, I've tried to express my opinions on this. For me the original proposal doesn't work very well and given nobody else joined discussion, there is not much interested in changing this in the ecosystem itself. -- Ivan > > > > 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. -- 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.
