Configure Quality Checks

• ChangesetLabelCheck for labels
• ChangesetContextCheck for contexts

The checks enforce the Liquibase recommendation that labels or contexts be assigned to each changeset to provide better deployment control and to enhance traceability of efforts across changesets.

For example, you have a changelog file with at least one changeset that does not have labels or contexts defined. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with no label or context.

Additionally, see the following check variation:

• One label or context defined on a changeset
• Multiple labels or contexts defined on a changeset
• No labels or contexts defined on a changeset
• An inherited label or context from include or include all

Note: Labels are not inherited from the parent changelog, so none of the changesets in an included changelog will automatically get a label. Therefore, the quality checks will warn that the child changesets do not contain a label unless the label has been explicitly added to the child changelog’s changeset.

The check enforces the Liquibase recommendation that comments be added to each changeset to document the purpose of a changeset for other consumers of that changelog.

For example, you have a changelog file with at least one changeset that does not have a comment added to it. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with no comment.

The check detects when a changeset does not have a rollback defined so that you can deploy and revert schema changes when needed.

For example, you have a changelog file with at least one changeset that does not have a rollback added to it. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with no rollback.

Tip: Liquibase recommends writing explicit rollback code for a changeset, where possible. While Liquibase does generate automatic rollback code for many Change Types, this check triggers when rollback code is not included.

The check warns when a table is being dropped. This ensures that dropping the table will not lead to unintentional loss of data. For example, you have one of the following:

• A formatted SQL changelog file with the DROP TABLE statement
• A JSON, YAML, or XML changelog file with the dropTable changeset
• A JSON, YAML, or XML changelog file that includes the sql, sqlFile, or pro:sqlplus Change Type, and there is the statement that contains DROP TABLE

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with a table being dropped.

The check warns when a column is being dropped. This ensures that dropping the column will not lead to unintentional loss of data. For example, you have one of the following:

• A formatted SQL changelog file with the ALTER TABLE TABLE_NAME DROP COLUMN statement
• A JSON, YAML, or XML changelog file with the dropColumn changeset
• A JSON, YAML, or XML changelog file that includes the sql, sqlFile, or pro:sqlplus Change Type, and there is the statement that contains ALTER TABLE TABLE_NAME DROP COLUMN

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with a column being dropped.

Additionally, see the check variations:

• Statement does not contain the COLUMN keyword: ALTER TABLE TABLE_NAME DROP <column_name>
• Statement contains a column list: ALTER TABLE TABLE_NAME DROP (<column1_name>,<column2_name>)

The check warns when generated or raw SQL contains TRUNCATE statements. This ensures that dropping the column will not lead to an unintentional loss of data.

For example, you have a changelog file with one or more changesets that include the sql, sqlFile, or pro:sqlplus Change Type, and there is a statement with TRUNCATE TABLE table_name.

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with the TRUNCATE statement. However, the check does not affect TRUNCATE in comments or table names.

Additionally, the check will warn if the statement does not contain the TABLE keyword: TRUNCATE table_name.

The check warns when generated or raw SQL contains GRANT statements so that you can ensure that the privilege being granted will not lead to security issues.

For example, you have a changelog file with at least one changeset that includes the sql, sqlFile, or pro:sqlplus Change Type, and there is a statement that contains GRANT <privilege name>. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with privileges.

The check warns when generated or raw SQL contains REVOKE statements so that you can ensure that the privilege being revoked will not lead to data access and dependency issues.

For example, you have a changelog file with at least one changeset that includes the sql, sqlFile, or pro:sqlplus Change Type, and there is a statement that contains REVOKE <privilege name>. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with privileges.

The check warns when a changeset contains SQL that grants specific privileges to a user or role.

Uses

You may have a changelog file with one or more changesets that contain the sql, sqlFile, or pro:sqlplus Change Type and the GRANT <privilege name> to <user or role> statements.

When you execute liquibase checks run against that changelog, you will receive an alert message about the changesets with the privileges for users or roles that exist in the list provided during customization.

To enable SqlGrantSpecificPrivsWarn, you need to run the copy subcommand and customize the check:

liquibase copy --check-name=SqlGrantSpecificPrivsWarn

Follow the CLI prompt to customize the check, specifying one or more privileges separated by commas. If the privilege includes spaces, enclose it in double quotes:

SELECT, "DROP ANY TABLE", INSERT

Note: See the Configurable attributes for specific privileges table for the attributes you can customize.

• SqlGrantAdminWarn, which detects GRANT WITH ADMIN OPTION
• SqlGrantWithGrantAdminWarn, which detects GRANT WITH GRANT OPTION

The checks warn when generated or raw SQL contains the GRANT statements that include the WITH ADMIN OPTION clause or the WITH GRANT OPTION class. This ensures that the privilege being granted will not lead to security issues.

For example, you have a changelog file with one or more changesets that include the sql, sqlFile, or pro:sqlplus Change Type, and there is a statement that follows the pattern of GRANT <privilege name> TO <role or user name> WITH ADMIN OPTION or GRANT <privilege name> TO <role or user name> WITH GRANT OPTION.

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with the privilege you want to grant.

Note: The privilege name and role or username can be any privileges, roles, or users. The privilege name can be multiple tokens or words, and the role and username can be a comma-separated list of roles and users.

The check warns when a change will result in modification of a data type so that you can ensure that modifying the data type will not lead to unintentional loss of data. For example, you have one of the following:

• A formatted SQL changelog file with the ALTER TABLE MODIFY COLUMN statement
• A JSON, YAML, or XML changelog file with a modifyDataType changeset
• A JSON, YAML, or XML changelog file that includes the sql, sqlFile, or pro:sqlplus Change Type, and there is the statement that contains ALTER TABLE MODIFY COLUMN

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset that may modify the data.

Additionally, see the check variations:

• Statement does not contain the COLUMN keyword: ALTER TABLE MODIFY <column_name>
• Statement contains additional ALTER instead of MODIFY: ALTER TABLE ALTER COLUMN

• ObjectNameMustMatch, which detects whether the object name matches the specified pattern
• ObjectNameMustNotMatch, which detects whether the object name does not match the specified pattern

The checks confirm that object names do or do not conform to the specified pattern.

For example, you have a changelog file with one or more changesets that include the sql, sqlFile, or pro:sqlplusChange Type, and there is a statement that follows the pattern of GRANT <privilege name> TO <role or user name> WITH ADMIN OPTION or GRANT <privilege name> TO <role or user name> WITH GRANT OPTION.

When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with the privilege you want to grant.

The check scans generated or raw SQL for the presence of specific patterns so that you can prevent security and velocity issues as early as possible.

Uses

You may have a JSON, YAML, or XML changelog file with one or more changesets that contain raw SQL or produce generated SQL that matches a regular expression. When you execute liquibase checks run against that changelog, Liquibase generates or accesses the SQL generated for the changelog and checks for a match against the defined regular expression. After this, you will receive an alert message about the changeset affected.

Note: Liquibase uses the java.util.regex engine to match regular expressions.

You may also have a formatted SQL changelog file to check changesets that have labels, but those labels do not match the check configuration.

To use the SqlUserDefinedPatternCheck check with the specific SQL, you must copy and customize it:

liquibase copy --check-name=SqlUserDefinedPatternCheck

Note: See the Configurable attributes for SQL that contains a specific pattern table for the attributes you can customize.

You cannot delete or reset the SqlUserDefinedPatternCheck check if it is an original check, not a copy of the check.

You cannot reset a customized copy of the SqlUserDefinedPatternCheck check for the initial value because the check does not have a default value for the SearchString attribute. If you no longer need to run this check, delete or disable it.

The check ensures that no table has more than a threshold number of columns.

Uses

You may have a changelog file with one or more changesets that contain a table with N columns in which N > MAX_COLUMNS. When you execute liquibase checks run against that changelog, you will receive an alert message about the changeset with the exceeded limit.

You can copy and customize the TableColumnLimit check to your specific column limit threshold by running:

liquibase copy --check-name=TableColumnLimit

Note: See the Configurable attributes for a table column count limit table for the attributes you can customize.

You cannot delete or reset the TableColumnLimit check if it is an original check, not a copy of the check.

You cannot reset a customized copy of the TableColumnLimit check for the initial value. If you no longer need to run this check, delete or disable it.