✨ added strict exceptions config file

[sschleemilch]

About

Idea is to be able to enable --strict and/or --aborts e.g. in CI but allowing current existing violations.

Added --strict-exceptions that should point to a YAML file defining exceptions in the following way:

Vehicle.Foo: # Allow all violations

Vehicle.Bar: # Allow name violoations
  - name-style

Vehicle.Zed: # Allow unknown attribute violations
  - unknown-attribute

Vehicle.Yada: # Allow specific violations
  - name-style
  - unknown-attribute

Refactored available strict options into an enum and using it.

[sschleemilch]

I was wondering: should we have that really in every exporter? How about a check sub command that does only validate whether the given specs are valid and nothing else?

[erikbosch]

I was wondering: should we have that really in every exporter? How about a check sub command that does only validate whether the given specs are valid and nothing else?

You mean that you need to do things in two steps, like vspec check followed by vspec export? In general we need to do some form of checks to be able to export, but the "strict" part could as I see it be a separate command, but then maybe not call it check as we need to do basic checks for all commands.

[sschleemilch]

I was wondering: should we have that really in every exporter? How about a check sub command that does only validate whether the given specs are valid and nothing else?

You mean that you need to do things in two steps, like vspec check followed by vspec export? In general we need to do some form of checks to be able to export, but the "strict" part could as I see it be a separate command, but then maybe not call it check as we need to do basic checks for all commands.

Yeah, when implementing I was wondering whether it is worth doing that for each exporter when the use case of CI could be just to run vspec validate and later vspec export. I can find arguments for both. Alright, let's stick with this or a separate command? Your opinion?

[erikbosch]

If it just contains the "optional check" I have no problems having it as a separate command. But on the other hand, there might be exporters that only can handle "strict" models, but I assume it is feasible for an exporter if neede to explicitly call the "strict check" (with default arguments) before continuing, in case it relies on that name patterns and similar limitations are followed. So no strong opinion.

[sschleemilch]

If it just contains the "optional check" I have no problems having it as a separate command. But on the other hand, there might be exporters that only can handle "strict" models, but I assume it is feasible for an exporter if neede to explicitly call the "strict check" (with default arguments) before continuing, in case it relies on that name patterns and similar limitations are followed. So no strong opinion.

Okay, then maybe leave it like it is, even though it requires adding the same arg in all exporters

[erikbosch]

LGTM, Anything more to do? I merged the other PR, do not know if the arg need to be added to that exporter as well.

[sschleemilch]

LGTM, Anything more to do? I merged the other PR, do not know if the arg need to be added to that exporter as well.

Nothing more to do. If we have a new exporter I need to rebase though and add that arg... Will do