search

OSGeo / grass

GRASS GIS - free and open-source geospatial processing engine
https://grass.osgeo.org
Other
791 stars 288 forks source link

CI(super-linter): Specify linter rules path to pick up configuration files #3915

Closed echoix closed 1 week ago

echoix commented 1 week ago

yamllint in pre-commit fails while yamllint from super-linter doesn't. Adds the config file to the super-linter config, as surprisingly super-linter defaults to .yaml-lint.yml, which wasn't a default known config file name in yamllint in all versions of the docs I looked at, going back to v1.0.0 too.

echoix commented 1 week ago

Not working as expected yet

echoix commented 1 week ago

Ready to merge.

echoix commented 1 week ago

I'd prefer to move the linter file away from root, if that is possible. There are sooo much there already.

My point of view is a little different and founded on other practical reasons. I'm more in favor of sticking as close as possible to each tools defaults and to existing conventions of the respective languages/ecosystems. This way, we easily have everything "just work", across environments, computers, IDEs, IDE plugins, etc. and we keep the flexibility to change implementations, or ways to use the same tool. We avoid requiring each new or existing contributor to do a bunch of configuration tuning just for this project. In that sense, I was quite surprised that super-linter broke these conventions and rather using 1) a path that only makes sense for projects running on GitHub (meaningless otherwhere, in the past and the future), and 2) that our config file wasn't picked up and super-linter didn't apply our conventions as picked up by yamllint in pre-commit. To see how hard it is to impose a configuration on each dev's environment, see the current state of pre-commit that is still hard to impose, and why CI is needed to enforce conventions.

Then, I'm still able to understand the desire of having less files at the root of the repo as an aesthetic "nice to have", but I don't see how it can ever offset the practical benefits of staying within conventions. Configuration files starting or not with a dot for a repo is quite ubiquitous and accepted. That's why I think Python tools integrating their config inside pyproject.toml isn't a bad idea, and the ones outside of Python that manage to store most or all their config inside .editorconfig files. (We should really have one at the root and for other file types, ie: move the one from the .github/workflows folder and populate for more file types).

Bref, I'm more in favor of standardisation rather than specialization, so we don't get stuck in our corner and have difficulty evolving with others later on.

echoix commented 1 week ago

I've also added the markdownlint configuration file name to super-linter, as the default file name isn't the default one used here (super-linter didn't follow that name too)