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
While it's well-documented and easy to ignore linter rule violations via a project's .regal/config.yaml file, some users have told us that issues reported by Regal in the context of authoring policies in a supported (LSP) editor — can be somewhat annoying when:
working with code that belongs to someone else (like a customer, client, someone you support)
just messing around with some Rego in a temporary scratch directory
It's possible to achieve this today already, as Regal will traverse the directory tree upwards looking for configuration, using the first one it finds. But in addition to this, we could easily support a user-level ~/.config/regal/config.yaml too. This configuration would only apply when none of the above methods found a config, and config files should not be "merged". I.e. a project-level config always takes precedence.
The text was updated successfully, but these errors were encountered:
While it's well-documented and easy to ignore linter rule violations via a project's
.regal/config.yaml
file, some users have told us that issues reported by Regal in the context of authoring policies in a supported (LSP) editor — can be somewhat annoying when:It's possible to achieve this today already, as Regal will traverse the directory tree upwards looking for configuration, using the first one it finds. But in addition to this, we could easily support a user-level
~/.config/regal/config.yaml
too. This configuration would only apply when none of the above methods found a config, and config files should not be "merged". I.e. a project-level config always takes precedence.The text was updated successfully, but these errors were encountered: