Changelog CI Validation with Liquibase Update-Testing-Rollback

A changelog that applies but cannot roll back is a one-way door, and you usually discover it during the incident that needed the rollback. This blueprint closes that gap at review time: a webhook fired from your pull request pipeline runs liquibase validate to prove the changelog is well formed, then liquibase update-testing-rollback to prove every change set applies, rolls back, and re-applies cleanly. It all happens on a disposable H2 file database created inside the task's working directory, so the check needs no external infrastructure and leaves nothing behind. Discord gets the verdict either way.

How it works

1. ci_webhook (io.kestra.plugin.core.trigger.Webhook) starts the flow when your CI pipeline calls it on a pull request. Replace change-me-strong-webhook-key with a strong random value before use.
2. test_changelog (io.kestra.plugin.liquibase.CLI) receives the changelog through inputFiles and targets jdbc:h2:file:./ci-db, an H2 file database that exists only inside this task run. The plugin image bundles the H2 driver, so no database server is involved.
3. liquibase validate catches malformed changelogs first with a fast, clear error.
4. liquibase update-testing-rollback then applies every change set, rolls all of them back, and applies them again, failing loudly if any change set lacks a working rollback.
5. report_verdict posts the passing verdict to Discord, and the errors block posts the do-not-merge verdict when any step fails.

What you get

• Proof before merge that every change set both applies and reverts, not just that the YAML parses.
• A completely disposable test database per run, with zero external dependencies and zero cleanup.
• A merge verdict in Discord that reviewers can act on without opening logs.
• A webhook contract any CI system can call with one HTTP request.

Who it's for

• Teams whose changelog reviews currently check style but never execution.
• Database administrators enforcing that every change set ships with a working rollback.
• Platform engineers adding database checks to pull request pipelines without provisioning test databases.

Why orchestrate this with Kestra

You could script these two commands in CI, but then every repository re-implements the container image, the secret handling, the notification, and the log retention. As a Kestra flow, the check is one webhook call from any pipeline, the Liquibase environment is the plugin's maintained container image, every run is preserved in the execution history, and the verdict routing lives in one place instead of scattered CI configs.

Prerequisites

• Nothing beyond Kestra itself for the database side: the H2 file database is created and discarded inside the task run. In production you keep H2 here on purpose, because this flow tests the changelog, not your database server.
• A Discord incoming webhook for verdicts.

Secrets

• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the DISCORD_WEBHOOK_URL secret to your Kestra namespace.
2. Execute the flow manually; Discord should report a passing verdict within a minute.
3. Replace the webhook key with a strong value and call the webhook from your pull request pipeline.

How to extend

• Pass the pull request's changelog in through namespaceFiles synced from the repository branch instead of the inline demo changelog.
• Test against your real database engine by swapping the H2 URL for a throwaway Postgres or MySQL instance and adding credentials from secrets.
• Report back to the pull request itself by replacing Discord with an HTTP task calling your Git provider's status API.
• Chain the pre-deploy gate blueprint after merge so the same changelog is checked again against the real target before release.

Links

• Liquibase plugin documentation
• Liquibase update-testing-rollback documentation