Problem with RollbackSQL - Bad output file

Liquibase Development
1

Hi,


I’m using Liquibase 3.0.2 with maven 3.0.4 and Jenkins. I want generate the rollback script by contingence.



The config lines in my pom.xml is this:

  org.liquibase

  liquibase-maven-plugin

  3.0.2

 

   

      postgresql

      postgresql

      9.2-1002.jdbc4

   

 

 

   

      generate-rollback-sql

      process-resources

     

        rollbackSQL

     

   

 



This is the configuration in Jenkins:

goals:

  liquibase:rollbackSQL

maven opts:

  -Dliquibase.driver=org.postgresql.Driver

  -Dliquibase.url=$URL

  -Dliquibase.username=$USERNAME

  -Dliquibase.password=$PASSWORD

  -Dliquibase.changeLogFile=$DBVC_DIR/changelog-master.xml

  -Dliquibase.outputFileEncoding=UTF-8

  -Dliquibase.migrationSqlOutputFile=$OUTPUT_FILE

  -Dliquibase.loggin=DEBUG

  -Dliquibase.rollbackTag=VERSION_1.0



The problem is that when I launch the task in Jenkins does not generate any errors but the output file does not have SQL statements. Each changeset has configured their rollback.


On the other hand, did the same with updateSQL and this generates the file with SQL statements without any problem.



This is the output file that generate rollbackSQL:


– *********************************************************************

– Rollback to ‘VERSION_1.0’ Script

– *********************************************************************

– Change Log: /usr/local/jenkins/jobs/Task/workspace/porject/changelog-master.xml

– Ran at: 9/26/13 3:19 PM

– Against: user@jdbc:postgresql://localhost:5432/db

– Liquibase version: 3.0.0-SNAPSHOT

– *********************************************************************


– Lock Database

– Release Database Lock



Note that at the end, in the output file, there is a line that says Lock Database, but I check the table databasechangeloglock and not locked.


Someone can help me please. Thank you!

2

It may be an issue with stdout vs stderr and where liquibase sends output. That was an issue fixed I believe after 3.0.2, could you try with the newest 3.0.5?

Nathan

3

Nobody has an answer to this problem !!! I can not believe it.

4


Thanks for you response. I solved my problem with the version 3.0.5.


However, the situation a little clearer, I think the problem was the file path to the changeset, because as I show, both the update and the generation of SQL statements file path must be preserved.