Standardizing RuboCop with theforeman-rubocop

@ekohl and I have been exploring ways to maximize the benefits of RuboCop across Foreman and its plugins and we came up with a series of improvements to achieve this and we’d love to hear your thoughts.This proposal is crafted in collaboration with @ekohl (Thank you).

Use theforeman-rubocop ~> 0.1.0 in Foreman and all* plugins

RuboCop is beneficial to a codebase. While opinions differ on style, there are cops that help with deprecation.

Some examples:

  • Lint/DeprecatedClassMethods
  • Lint/DeprecatedConstants
  • Lint/DeprecatedOpenSSLConstant
  • Lint/ErbNewArguments
  • Performance/StringInclude (often prevents issues in Ruby 3.2)
  • Performance/StartWith (often prevents issues in Ruby 3.2)

Upgrade theforeman-rubocop[1] gem to the latest version (~> 0.1.0): This gem offers a central location for RuboCop configuration and dependencies, fostering consistency across projects. Foreman and plugins can then use inherit_gem[2] in .rubocop.yml to avoid duplicating an entire configuration.

Today Foreman uses theforeman-rubocop → 0.0.6 and many Foreman plugins don’t use theforeman-rubocop at all or also use 0.0.6. We want a common baseline to build on. That means aiming for the current latest release (~> 0.1.0)

Update foreman_plugin_template[3] to showcase recommended RuboCop configuration: This will provide a clear starting point for new plugin developers and encourage adoption of best practices. There we should agree on a recommended config.

Encourage plugin maintainers to adopt RuboCop: If it’s not implemented in a plugin, it’s up to the plugin maintainers if they want RuboCop. Though strongly recommended, in the end it’s still their project. If they do, they can also choose a style though we would have a recommendation from the foreman_plugin_template.

*we want to look at https://theforeman.github.io/foreman-plugin-overview/ for actively maintained plugins in theforeman namespace

Release a new version of theforeman-rubocop

After we have a common baseline, we can work on releasing a new version of theforeman-rubocop.

Upgrade RuboCop version to 1.60.0: Today it uses rubocop ~> 1.23.0 but upstream there’s rubocop 1.60.0. This version still supports Ruby 2.7 so it makes sense to update to that version and allow access to new features and improvements.

Analyze and document introduced/changes cops: Updating means bumping dependencies in theforeman-rubocop.gemspec. That implies there are new cops. To better understand the differences, it would be useful to produce a list of cops that were introduced/changed in between. One way to do so is to go over the cop documentation[4] or release notes[5] and build a list.

With that list we can better decide how to change the various configs (if at all). Analyzing existing code bases on the differences can inform us about common coding styles/preferences.

Update Foreman and all plugins to the new version

Submitting pull requests for all relevant projects: Once a new release is made, it should be used. This comes down to submitting pull requests for all reverse dependencies and working with maintainers to get them merged

Prioritize resolving configuration issues in PR: It may be OK to submit with a large TODO file, but if possible we’d prefer resolving it as part of the PR (or prerequisite PRs).

[1]: https://github.com/theforeman/theforeman-rubocop
[2]: https://docs.rubocop.org/rubocop/configuration.html#inheriting-configuration-from-a-dependency-gem
[3]: https://github.com/theforeman/foreman_plugin_template
[4]: https://docs.rubocop.org/rubocop/1.60/index.html
[5] https://github.com/rubocop/rubocop/releases/tag/v1.60.0

7 Likes

I’ve been focused on standardizing RuboCop configurations across Foreman and its plugins using the theforeman-rubocop gem for quite some time now. I would appreciate reviews from project maintainers or anyone interested. Here are the PRs and related issues to look into:

1 Like