Originally posted by: rbijkerk
We are running into the same problem. Even though the precondition fails, the changeset is still running.
Yes, but Nathan just said that CONTINUE, which if I am reading right is what you are using, is for the case when that’s exactly what you want. You clearly don’t want this behavior, so don’t use CONTINUE.
I did find the bug where it was executing onFail=CONTINUE changesets. It should now be following the documented behavior on http://liquibase.org/manual/preconditions of:
HALT Immediately halt execution of entire change log [default]
CONTINUE Skip over change set. Execution of change set will be attempted again on the next update. Continue with change log.
MARK_RAN Skip over change set, but mark it as ran. Continue with change log
WARN Output warning and continue executing change set as normal.
Originally posted by: rbijkerk
We are running into the same problem. Even though the precondition fails, the changeset is still running.
Yes, but Nathan just said that CONTINUE, which if I am reading right is what you are using, is for the case when that’s exactly what you want. You clearly don’t want this behavior, so don’t use CONTINUE.
Or am I missing something?
Best,
Laird
As I understand it cotinued executing that same changeSet when it should continue with the next one, right?
If you have “CONTINUE” it will skip the failing changeset but continue with execution. “WARN” will execute the failing changeset and continue with execution. “MARK_RAN” will skip the failing changeset like "CONTINUE does, but with the added feature of marking it as ran so liquibase will never attempt to run it again.
Why can’t CONTINUE be used for preConditions on changelogs?
The documentations says explicitly “Outside a changeset (e.g. at the beginning of the change log), only HALT and WARN are possible values.”, but there is no explanation why.
I would like to have a “master” changelog which includes other “sub-changelogs”. In these ones I would like to have a precondition check with CONTINUE or MARK_RAN, so that a whole sub-changelog can be skipped. Writing the precondition in every changeset would be much more work and has the risk of forgetting it on a changeset.
The reason is because preconditions on child changelogs are considered global to the entire changelog. There is a feature request in jira to support preconditions that cause the changelog it is in to be skipped, but the current functionality is that if a changelog has a top level precondition it is checked before anything is run, even changeSets in other changelogs.