Liquibase Linter doesn't have a standard configuration, so it's up to you to decide what you want it to enforce and how on your project.
JSON config file
You do this by providing a
lqlint.json file at the root of your project. Here's how it's structured:
From the classpath
It is also possible for Liquibase Linter to load the
lqlint.json file from the classpath. This can be useful when you have many different
projects using Liquibase and want to share the rule config between them. With maven this would be done in the following way,
lqlint.json is stored directly under
Custom lint config file path
There is also support for changing the default path that the config file is loaded from. This is done by specifying the
system property. With maven this would look like
mvn resources:resources liquibase:update -Dlqlint.config.path=foo-lqlint.json
By default, lint failures are aggregated and reported at the end after all changes are scanned:
If you prefer, you can set
true in your config file so that the process will exit as soon as it finds the first failure.
Ignoring certain changes
This config entry is an optional regular expression for contexts that, if found on a changeSet, will cause the linter to skip checking that changeSet. This can be useful when you have scripts in your project that were generated by a tool and wouldn't pass your normal quality checks for hand-rolled scripts.
This config entry is an optional regular expression for file patterns that, if matched on a changeSet, will cause the linter to skip checking that changeSet.
Sometimes you might have to do something less than perfect to get you out of a jam, and it might break some of your usual quality rules. In these cases, you can include the text "lql-ignore" at the end of the changeSet's
<comment> tag and it will be skipped by the linter:
You can also disable an individual rule while leaving all others on, if that's all you need:
Importing other configuration
The Liquibase Linter configuration can import configuration from other configuration files.
In this way, common configuration can be centralized. For example, common
configuration could be published as a Maven artifact and included in the
Liquibase plugin dependencies in the same way
liquibase-linter is included.
If multiple configurations are imported, their rules are combined. Any named rules in the main configuration will replace all rules of the same name from the imported configuration. In this way, rules can be easily overridden.