rules: support inverted path match

[pohly]

It is not possible to use exclude-rules: path to exclude issues for non-test files because it is impossible to write a regexp that reliably matches those (#2440). The new not-path check solves that by inverting the meaning: it excludes if the pattern does not match.

Besides test files, this is also useful for large code bases where some specific code paths have additional constraints. For example, in Kubernetes the usage of certain functions is forbidden in test/e2e/framework but okay elsewhere. Without not-path path-except, a regular expression that carefully matches all other paths has to be used, which is very cumbersome:

- path: ^(api|cluster|cmd|hack|pkg|plugin|staging|test/(cmd|conformance|e2e/(apimachinery|apps|architecture|auth|autoscaling|chaosmonkey|cloud|common|dra|instrumentation|kubectl|lifecycle|network|node|perftype|reporters|scheduling|storage|testing-manifests|upgrades|windows)|e2e_kubeadm|e2e_node|fixtures|fuzz|images|instrumentation|integration|kubemark|list|soak|typecheck|utils)|third_party|vendor)/
  msg: "E2E framework:"
  linters:
  - forbidigo

With path-except, this becomes much simpler:

- path-except: ^test/e2e/framework/
  msg: "E2E framework:"
  linters:
  - forbidigo

Fixes: #2440

[ldez]

Hello,

not-path seems really ambiguous as a name.

[pohly]

not-path seems really ambiguous as a name.

Let's brainstorm, perhaps we can come up with something better.

• issues: exclude-rules: not-path = "exclude, but not in path ..."
• issues: exclude-rules: except-for-path = "exclude, except when the path matches"
• issues: exclude-rules: allow-issues-for-path = "exclude issues, allow them for certain paths"

cc @ashanbrown

[ashanbrown]

xpath? inverse-path?

[ashanbrown]

Thinking a bit more about this, path-except seems like it might be clearer name. Furthermore, adding both paths (plural) as an inclusive list as well as paths-except as an exclusive list (applied after pathandpaths`), might be ideal.

[pohly]

I'm fine with path-except. I'll defer to @ldez here.

Regarding paths and paths-except, do you want those to be lists of regexps instead of the single regexp for path and (soon?) path-except? That doesn't add any new capabilities (a regexp can already match multiple different paths), so I would prefer to not add those.

[pohly]

Semantically, all of the conditions are AND and there's no implied ordering. That more complex conditions get checked after others is merely an implementation detail.

[ashanbrown]

My only reason for suggesting paths and paths-except is that they could make it easier to express intent and keep completely unrelated cases separately (and potentially comment them in yaml as well). I agree it isn't technically necessary to implement the desired behavior.

[pohly]

I suspect that it is already possible to keep such separate cases also separated in the YAML with different exclude-rules: they might share other common attributes (linter, message), but if the intent is different, then perhaps those are also different?

[ldez]

path-except seems right.
Keep it as a string.

[pohly]

Renamed to path-except.

[ldez]

Sorry for the delay, I will handle the PR very soon.