Set --strict mode from configuration file

[jamesquilty]

I've just found that there I would like yamllint to always run in pre-commit with the --strict option and looked to see if this option could be set in the .yamllint configuration file. As far as I can tell, it can't, but the alternative of specifying the option as an argument in the pre-commit config file is good enough.

A nice-to-have would be if the command line options could be set in the config file so behaviour is consistent between command line and pre-commit and the config is in one place.

I realise this would add complication, so I'd completely understand if this wasn't at all a priority. Thanks for writing yamllint and making it available, it's helped avoid trouble on more than one occasion!

[andrewimeson]

As another alternative: you can override a rule that defaults as a warning to be an error

extends: default

rules:
  comments:
    level: error

I do like the idea of adding top level configuration key like strict: true.

[adrienverge]

Hello,

I allowed myself to rename the issue title, because most command-line flags (-h, -c, -d, -v, --list-files...) aren't meant for that.

Related to https://github.com/adrienverge/yamllint/pull/348.

I'm still not a fan of allowing strict: true or no-warnings: true in configuration, because in my opinion these are flags for temporarily altering the output (using command line), while static customizations should define level: error|warning permanently in the configuration file. But I note you and @andrewimeson like the idea! I'm curious to know how many people would use this feature.

[jamesquilty]

I'm happy with the Issue title change to focus on the strict flag. What I would like to to is permanently set the exit code behaviour of yamllint. My context is for use with pre-commit, but it would also apply to other contexts where the exit code is tested.

Setting level: error for the four rules in the default configuration which have level: warning set is an indirect way of influencing the exit code behaviour and has some undesirable features from my point-of-view:

• I agree with the idea of level:, that some rule violations are more severe than others, and making everything an error for the purpose of influencing the exit code will remove that distinction.
• When a new rule with level: warning is added to the default configuration any violations won't be detected by automated processes if --strict is not used.
• If/when I happen to notice a new rule with level: warning has been introduced then I'll have to manually update every .yamllint file which will be error-prone toil.

Setting level: error is certainly feasible, but due to the three points above I would still find myself motivated to permanently set the --strict flag.

Adrien, there's only one rigorous way to satisfy your curiosity: implement a config file setting for strict and then survey public repos to see how many people use it 😄