If you run Liquibase without specifying a context then Liquibase will run changesets that have any context specified as well as those that have no context specified.
If you run Liquibase specifying a “dummy” context, then Liquibase will run changesets that have no context specified but will not run changesets that have a context specified.
If you run Liquibase specifying a valid context, then Liquibase will run changesets that have no context specified as well as those that have the context that you specified.
Bizarre, but that’s how it works. We’ve found the best bet is to set up a defaults file with a context of production, which for us is a dummy context.
I’m just trying to confirm that the documentation says what I think it does.
Given a some changesets with the context ‘dangerous-things’, or a no-context changeset called ‘do-something-dangerous’, Liquibase will always do these dangerous things unless I run it in context of ‘no-dangerous-things’.
In other words, to avoid dangerous things, I must establish a convention to always call Liquibase in the safest context (possibly a nonexistent context). If I am on a team, I must educate every team member that they must opt out of the dangerous context.
Am I interpreting this correctly? Is there an easier way to address the concern that harmful changes must be consciously opted-out ?
Yikes. Intuitively I’d think you want the most naive context (none) to do as little as possible as a guard against doing more than you expect. This makes me want to manage context in a different way (by switching changelogs entirely).
