Daniel,
Thanks for your help, that is certainly a lot better than what I currently have!
There is still a small issue with the functionality, but I am convinced that it should not pose to much of a problem for my usage
The databasechangelog record for the tag operation will not be removed when performing a rollback operation unless I make sure I pass the same ${build.number} value in to the liquibase command. Otherwise, liquibase would perform in the same way as if it couldn't find the changeset in my changelog, and skip it during rollback.
Take the following scenario as an example:
- Update to build 1
- Update to build 2
- Update to build 3
- Rollback to build 1
- Update to build 3
At step 4, I would only have 3 databasechangelog records, one for each of the tag commands.
At step 5, the changeset for tagging build 3 would be bumped to the top/end again, but the changesets for tag 1 and 2 would be left at the bottom/start of the databasechangelog.
If I now attempt to rollback to build 2, It would rollback all of the changesets (or at least the same amount as trying to rollback to build 1).
As I said, not a big deal to me, but thought it worth adding here.
Thanks again.