> 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).

>  using rubocop via running rake from the foreman repo
Doesn't help for build automation - You can't enable automatic builds this
way.

> 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.

> 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.

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.

Reply via email to