search

liquibase / liquibase-gradle-plugin

A Gradle plugin for Liquibase
Other
199 stars 59 forks source link

fix: input property fingerprinting #140

Closed nbrugger-tgm closed 1 month ago

nbrugger-tgm commented 7 months ago

replace a "hardcoded/real" property with a gradle style one so gradle can actually use the input as such

Closes: #120

nbrugger-tgm commented 6 months ago

@stevesaliman

nbrugger-tgm commented 6 months ago

@MalloD12

stevesaliman commented 6 months ago

The next release of the plugin is going to use the Liquibase Command API instead of a JavaExec, so this PR may not be needed anymore.

I'm just waiting on a fix in Liquibase, which will hopefully be in the next LB release.

kevin-atx commented 4 months ago

@stevesaliman - the command API fix will be released with Liquibase 4.28.0 on 5/21/2024 (today). Starting with this release, you should be able to re-implement the Gradle plugin to take advantage of the command API.

kevin-atx commented 3 months ago

@stevesaliman - were you able to test with the 4.28.0 release of Liquibase to see if this PR is still needed?

stevesaliman commented 3 months ago

Unfortunately, version 4.28.0 still has an issue with changelog parameters and the Command API, so I can't finish my testing.

MalloD12 commented 3 months ago

Hey @stevesaliman, could you please point us to the changelog parameters issue you are seeing?

Thanks, Daniel.

stevesaliman commented 3 months ago

The issue is in how the Gradle plugin interacts with the new CommandScope API. When a task executes, it creates a new ChangelogParameters object to store any parameters given to it by Gradle before calling CommandScope.execute. Since there is no database connection at this point, the database is null, so the database filters are also null.

I set a breakpoint in the ChangeLogParameters constructor and in Liquibase 4.20.0, the constructor would be called by the Gradle plugin before calling execute, but it would be called again after calling execute, this time with a database. The Groovy DSL's parse method would then be given parameters with all the parameters and databaseFilters.

But in 4.21.0, the constructor is only called once, and the the parameters made by the plugin are the parameters given to the parse method. Since the database is null, it isn't properly handling ChangeLogParameters that had the dbms attribute set.

I'm not sure what changed from 4.20 to 4.21, but something change that gets in the way of the changelog parameters working, and I haven't figured out how to work around it yet.

stevesaliman commented 2 months ago

The next version of the plugin will not be able to use the command API, because the changelog parameter issue remains. So LiquibaseTasks will continue to be JavaExec tasks, and your fix will likely need to be implemented in the new code.

I pushed the cli-api branch with the new code if you want to take a look. It shouldn't be too hard to make the required changes to that branch before it gets released.

stevesaliman commented 1 month ago

The LiquibaseCommand class is no longer part of the plugin, as of version 3.0.0, so this PR is no longer needed.