preConditions onSqlOutput TEST configuration does not work for nested changelogs

Liquibase Version: 3.6.3 (but same code on master)

Liquibase Integration & Version: <Pick one: CLI, maven, gradle, spring boot, servlet, etc.> maven

Description

onSqlOutput does not work, if it is used in a nested changelog.

Steps To Reproduce

• Create a config with changelog A importing changelog B.
• Add a changeset in B with a PreCondition which will always fail.
• Use the update-sql command

Actual Behavior

No error, and any SQL in B will be printed, although the condition failed

Expected/Desired Behavior

The command stopping/not outputing the SQL in B.

Workaround

Add an empty preCondition config to all “parent” changelogs, with the setting onSqlOutput: TEST

Cause

liquibase.precondition.core.PreconditionContainer#check processes preConditions in a top-down way. Nested Containers will only be evaluated, if the parent’s testPrecondtion is true:

if (testPrecondition) {
    super.check(database, changeLog, changeSet, changeExecListener);
}

As soon as one does not or is missing (and defaults to IGNORE), all nested preconditions will not be tested and all SQL will be printed.

[nvoxland]

I added a PR to fix the issue.

Your new example helped a lot, thanks

[NSC-nwest]

Hello, I ran into this issue as well. Will this allow me to generate SQL with updateSQL that ignores the failures?

parent changelog.yaml:

• include: file: child-changelog.yaml relativeToChangelogFile: true

child-changelog,yaml: databaseChangeLog:

• preConditions:
  • onSqlOutput: TEST
  • onFail: CONTINUE
  • onFailMessage: “Mocks will not be created.”
  • changeLogPropertyDefined: property: create-mocks

My goal here is to generate the SQL only if the create-mocks property is defined, when using the updateSql command. Currently this seems to blow up no matter what I do in the parent changelog (adding onSqlOutput: TEST & onFail: CONTINUE, etc).

The reason I am doing this is for our sandboxes where rebuilding the entire database every time for developers is time consuming so we generate the SQL, clean it up, and then run it as a big blob.