Re : "runalways" changesets seem to break rollback functionality

We currently have the tag being performed after the liquibase update from a Bash script in production, e.g.:

java -jar ${LIQUIBASEJAR} --driver=${LBDRIVER} --classpath=${LBCP} --url=${LBURL} --username=${LBUNAME} --changeLogFile=${LBCHANGELOG} tag ${BUILDNO}

This way, whenever we install a build, we get the tag of the build number added at the end of the update process. I tried adding in a single changeset to tag the database state in between my usual updates and my "runalways" updates using the changelog params to pass in the build number to the changelog , e.g.:

This works, but then leaves us with a single changeset that is "RERAN" each time the update is performed, so we have the same problem. One changeset that has it's "tag" column overwritten repeatedly, losing the ability to revert to previous tags.

Putting in a new changeset for each build isn't really practical, as we use a Continuous Integration server to produce the builds. I'd have to write something to manipulate the changelogs as part of the build process, which I'd like to avoid if possible.

The only thing I can thing that would satisfy my use case at this point would be to manipulate the databasechangelog table outwith liquibase, and add my tag to the most recently executed changeset that wasn't from the "always.xml" file. This seems a little overkill, and has the potential to cause me problems if the databasechangelog table schema get's altered at some point.