Makes sure that precondition onErrorMessage and onFailMessage are logged when an error happens

[filipelautert]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Currently onErrorMessage and onFailMessage are logged only if the log-level property is set to something higher than info. As they are custom error messages they should be logged everytime an error occurs.

Things to be aware of

Things to worry about

Additional Context

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

25.0% Coverage
0.0% Duplication

[rberezen]

@tati-qalified could you validate the fix please? TIA!

[tati-qalified]

It's working for me, with no issues.
I tested this using the CLI and a simple changelog:

databaseChangeLog:
  - preConditions:
    - onError: HALT
    - onFail: HALT
    - onErrorMessage: ---- this is an error ----
    - onFailMessage: ---- this is a failure ----
    - sqlCheck:
          expectedResult: 1
          sql: SELECT 1 from myTable
  -  changeSet:  
      id:  1  
      author:  nvoxland  
      preConditions:
        - onError: HALT
        - onFail: HALT
        - onErrorMessage:  ---- this is an error ----
        - onFailMessage: ---- this is a failure ----
        - foreignKeyConstraintExists:
            foreignKeyName: columna12345
            foreignKeyTableName: json_table
      changes:  
        -  createTable:  
            tableName:  newtable  
            columns:  
              -  column:  
                  name:  id  
                  type:  int  
                  autoIncrement:  true  
                  constraints:  
                    primaryKey:  true  
                    nullable:  false  
              -  column:  
                  name:  firstname  
                  type:  varchar(50)  
              -  column:  
                  name:  lastname  
                  type:  varchar(50)  
                  constraints:  
                    nullable:  false  
              -  column:  
                  name:  state  
                  type:  char(2)  

• First I tested only the preconditions for the entire changelog. I commented out the preconditions inside the changeset.
• After that, I uncommented the changeset preconditions and commented the changelog preconditions.
• Then I used both the changelog and changeset preconditions.

For all three scenarios I followed these steps:

1. Use a precondition that will generate an error
2. Run liquibase update
3. Run liquibase update --log-level= with each log level value
4. Do the same with a precondition that will fail
5. Run liquibase update with a precondition that will work - no errors nor failures

I tested around 6 different preconditions to be sure it worked in general. I don't believe it's necessary to test each one, though I can do it if someone thinks I should.

[tati-qalified]

Apart from that, there's an error message that isn't too user-friendly:

When trying to run a changelog with an empty sqlCheck

databaseChangeLog:
  - preConditions:
    - onError: HALT
    - onFail: HALT
    - onErrorMessage: ---- this is an error ----
    - onFailMessage: ---- this is a failure ----
    - sqlCheck:

The error message is:

Unexpected error running Liquibase: Migration failed for changeset changelog.yml::1::nvoxland:
     Reason: java.lang.NullPointerException: Cannot invoke "String.replaceFirst(String, String)" because the return value of "liquibase.precondition.core.SqlPrecondition.getSql()" is null

It should probably say something along the lines of "sqlCheck attributes sql and expectedResult are required"