feat(db): use flyway for migrations #590
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Welcome to Cryostat! 👋
Before contributing, make sure you have:
main
branch[chore, ci, docs, feat, fix, test]
To recreate commits with GPG signature
git fetch upstream && git rebase --force --gpg-sign upstream/main
Related to #549
Related to cryostatio/cryostat-operator#814
Description of the change:
Adds the Flyway extension for database schema versioning and migration management. The initial schema file was created using the Quarkus Flyway/Hibernate extension integration and matches the existing schema that was previously generated by Hibernate.
Motivation for the change:
This separates the database initialization from the Cryostat container's lifecycle, and provides us easy versioned hooks for data model migrations. This will allow more robust application version upgrades in the future. Combined with cryostatio/cryostat-operator/issues/814, the database's lifecycle is fully decoupled from the Cryostat server's lifecycle, so the Cryostat container can crash/restart/be upgraded without risking inadvertent data loss due to table drop-and-create.
How to manually test:
./smoketest.bash -OXb
I also tested this in OpenShift so that I could kill the Cryostat container individually (by running a shell in its container and simply doing
kill 1
) to test the behaviour when Cryostat restarts and reconnects to an existing database, to simulate cryostatio/cryostat-operator#923 where Cryostat and its database are in separate Pods with separate lifecycles.Run 1 (logs taken from a podman smoketest run, but the behaviour in OpenShift was the same - I just forgot to capture the logs):
Run 2: