Write proper Rubocop and Hound CI configs with Cimas about ci HOT 6 CLOSED

@CAMOBAP wrote in riboseinc/oss-guides#44:

For now, we have two configuration repositories:

• https://github.com/metanorma/metanorma-build-scripts - metanomra org, and one repo from plurimath org
• https://github.com/relaton/support - relaton org

Should we create a separate repo for each organization?

As an alternative: we can use 'groups' feature of cimas config and list all repositories in a single place https://github.com/metanorma/metanorma-build-scripts/blob/master/cimas-config/cimas.yml#L850 I think this may be easier to maintain

No idea, really, I haven't worked with Cimas before. The question is if both organizations will have the same settings, especially requirement for Ruby 2.4 support. @opoudjis can you confirm?

from ci.

@CAMOBAP wrote in riboseinc/oss-guides#44:

It feels like cimas tool by itself still not friendly, so I would like to ask you if you have a chance to try it please share your feedback:

Well, I must admit that I'm just keeping myself away from that thing, that's all. :)

I seldom work on Metanorma or Relaton, so I don't have much contact with Cimas, I just know that it exists. Gems that I currently maintain are more diverse than these from aforementioned organizations, so I'm not even sure if they could even benefit from Cimas. Also, some of them are used outside of Ribose projects, so adding yet another tool may be contributors-unfriendly.

from ci.

@CAMOBAP wrote in riboseinc/oss-guides#44:

One more question in case if I will find some project-specific configuration, should I just drop it or move to some .local.rubocop.yml and include .rubocop.yml in this .local.rubocop.yml ?

Personally I don't see much reason in adding yet another file to that setup which is overcomplicated already. I prefer to keep local overrides in .rubocop.yml.

Also, Rubocop does have the concept of local configuration files. Obviously, you can still have .rubocop.yml like this one:

inherit_from:
  - ...
  - ...
  - .rubocop.local.yml

and this will work locally, provided that .rubocop.local.yml exists. But unfortunately, this will break in Hound because Hound is buggy. Not going into details, our stylebook will take precedence over intended overrides…

But do we really need per project overrides in Metanorma or Relaton? I don't want to answer that, cause I don't know what's required in some helper projects.

from ci.

@skalee

But do we really need per project overrides in Metanorma or Relaton? I don't want to answer that, cause I don't know what's required in some helper projects.

Probably not. Can we use a single set of configuration rules across all the orgs/repos?

from ci.

Sorry, I too have not responded. I agree that different configs for different orgs is undesirable. The Ruby 2.4 is a current restriction in the Metanorma stack, but that's the only substantive discrepancy.

from ci.

cimas 's configuration update to update those files in our metanorma repos

from ci.