You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, I understand that the GitHub action repository is not the repository of golangci-lint itself.
Yes, I've searched similar issues on GitHub and didn't find any.
Your feature request related to a problem? Please describe.
Configuration files for golangci-lint become invalid over time, as linters are added and removed and some even have their configuration schemas changed.
In cases like these, it'd be helpful, I think, to have the build break with an appropriate message if the caller opts for that.
For example, in one of the projects we use this action, when verifying the configuration file manually, we get the following:
$ golangci-lint config verify
jsonschema: "linters-settings.revive" does not validate with "/properties/linters-settings/properties/revive/additionalProperties": additionalProperties 'min-confidence' not allowed
jsonschema: "linters-settings.depguard" does not validate with "/properties/linters-settings/properties/depguard/additionalProperties": additionalProperties 'list-type', 'packages' not allowed
jsonschema: "linters-settings.errorlint" does not validate with "/properties/linters-settings/properties/errorlint/type": expected object, but got null
jsonschema: "linters-settings" does not validate with "/properties/linters-settings/additionalProperties": additionalProperties 'maligned', 'varcheck', 'gomnd' not allowed
Failed executing command with error: the configuration contains invalid elements
But, when the linter is executed, only a warning is outputted and the build ends up green.
$ golangci-lint run
WARN The linter 'exportloopref' is deprecated (since v1.60.2) due to: Since Go1.22 (loopvar) this linter is no longer relevant. Replaced by copyloopvar.
In our case, we'd much rather have the build break when the configuration file isn't valid but there's no way to instruct the action to do so, currently.
Describe the solution you'd like.
The validity of the configuration file passed to golangci-lint can be determined via executing
golangci-lint config verify
A boolean option can be introduced to the action, namely verify-config, that, when set, would execute said command before golangci-lint run, to ensure that the linting process is in fact using a valid configuration file.
Describe alternatives you've considered.
We're bypassing the above issues by installing the binary ourselves and running the aforementioned check but we'd much rather have the action do it.
Additional context.
No response
The text was updated successfully, but these errors were encountered:
Welcome
Your feature request related to a problem? Please describe.
Configuration files for
golangci-lint
become invalid over time, as linters are added and removed and some even have their configuration schemas changed.In cases like these, it'd be helpful, I think, to have the build break with an appropriate message if the caller opts for that.
For example, in one of the projects we use this action, when verifying the configuration file manually, we get the following:
But, when the linter is executed, only a warning is outputted and the build ends up green.
$ golangci-lint run WARN The linter 'exportloopref' is deprecated (since v1.60.2) due to: Since Go1.22 (loopvar) this linter is no longer relevant. Replaced by copyloopvar.
In our case, we'd much rather have the build break when the configuration file isn't valid but there's no way to instruct the action to do so, currently.
Describe the solution you'd like.
The validity of the configuration file passed to
golangci-lint
can be determined via executingA boolean option can be introduced to the action, namely
verify-config
, that, when set, would execute said command beforegolangci-lint run
, to ensure that the linting process is in fact using a valid configuration file.Describe alternatives you've considered.
We're bypassing the above issues by installing the binary ourselves and running the aforementioned check but we'd much rather have the action do it.
Additional context.
No response
The text was updated successfully, but these errors were encountered: