search

metanorma / ci

Build scripts for Metanorma, works with continuous integration
3 stars 2 forks source link

Write proper Rubocop and Hound CI configs with Cimas #64

Closed skalee closed 3 years ago

skalee commented 3 years ago

Two files must be present in every Ruby repository: .hound.yml and .rubocop.yml. Following content seems optimal for Metanorma:

Extracted from https://github.com/riboseinc/oss-guides/issues/44.

cc @skalee @opoudjis @CAMOBAP @ronaldtse

skalee commented 3 years ago

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

For now, we have two configuration repositories:

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?

skalee commented 3 years ago

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

skalee commented 3 years ago

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

ronaldtse commented 3 years ago

@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?

opoudjis commented 3 years ago

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.

CAMOBAP commented 3 years ago

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