Skip to main content

Configure

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:

{
  "fail-fast": false,
  "ignore-context-pattern": null,
  "ignore-files-pattern": null,
  "rules": {}
}

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, where lqlint.json is stored directly under src/main/resources in lqlint-config

<plugin>
  <groupId>org.liquibase</groupId>
  <artifactId>liquibase-maven-plugin</artifactId>
  <configuration>
    <propertyFile>${liquibase.property.file}</propertyFile>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>io.github.liquibase-linter</groupId>
      <artifactId>liquibase-parser-extension</artifactId>
      <version>${liquibaselinter.version}</version>
    </dependency>
    <dependency>
      <groupId>com.your.group.id</groupId>
      <artifactId>lqlint-config</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
  ...
</plugin>

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 lqlint.config.path system property. With maven this would look like mvn resources:resources liquibase:update -Dlqlint.config.path=foo-lqlint.json

Reporting and fail-fast​

By default, lint failures are aggregated and reported at the end after all changes are scanned:

Example console output for failed rules

If you prefer, you can set fail-fast to true in your config file so that the process will exit as soon as it finds the first failure.

Ignoring certain changes​

ignore-context-pattern​

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.

Example usage:

{
  "ignore-context-pattern": "^baseline.*$",
  "rules": {}
}
(Regular expression literals aren't valid JSON, so you do need to use a string.)

ignore-files-pattern​

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.

Example usage:

{
  "ignore-files-pattern": "^src/main/resources/core/legacy/.*$",
  "rules": {}
}
To avoid issues with script file paths resolving to using either \ or /, all occurrences of \ are replaced with / (Regular expression literals aren't valid JSON, so you do need to use a string.)

"lql-ignore" comments​

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:

<changeSet id="201809061514dg" author="dgoss">
  <comment>Doing awful things to fix a problem lql-ignore</comment>

  <!-- awful things here -->
</changeSet>

You can also disable an individual rule while leaving all others on, if that's all you need:

<changeSet id="201809061514dg" author="dgoss">
  <comment>Empty this whole table lql-ignore:modify-data-enforce-where</comment>

  <delete tableName="FOO" />
</changeSet>

Importing other configuration​

The Liquibase Linter configuration can import configuration from other configuration files.

{
  "import": ["imported-lqlint.json"]
}

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.