JHipster Helm Chart Configuration for Pre‑Run Liquibase Migration Job

JHipster Helm Chart Configuration for Pre‑Run Liquibase Migration Job

The goal is to guarantee that database schema updates are applied exactly once and before any new version of the application starts, while preserving the ability to run destructive change‑sets safely in a Kubernetes RollingUpdate.

Currently the generated Helm chart relies on pod‑startup Liquibase execution, which can cause overlapping schema versions when old and new replicas run concurrently, and it does not automatically add the required preConditions for column drops, leaving the decision to manually edit changelogs.

How can the chart be extended to invoke the standalone liquibase:migrate task as a pre‑upgrade hook? What mechanism ensures the migration job finishes before the Deployment creates new pods? Should the chart provide a way to inject or validate preConditions for destructive changes without requiring developers to edit each change‑set?