Weekly Database Release Report with Liquibase History

Every migrated database keeps a perfect deployment record in its change log table, and almost nobody reads it. This blueprint turns that record into a weekly digest: io.kestra.plugin.liquibase.CLI runs liquibase history and captures the full output as a file artifact, a Python step reduces it to a change set count, and Slack receives the summary every Monday morning. The question what changed in the database this week stops requiring a database client to answer.

How it works

1. capture_history (io.kestra.plugin.liquibase.CLI) connects through the standard Liquibase environment variables filled from Kestra secrets. For the self-contained demo it first applies a small changelog so the history has entries; against a real database you remove that update command and keep only the history capture.
2. liquibase history writes the deployment record to history.txt, which outputFiles uploads to internal storage, preserving the full report alongside the execution.
3. summarize_history (io.kestra.plugin.scripts.python.Script on the Process runner) pulls the file in through inputFiles, counts the deployed change set lines, and emits the count through Kestra's output protocol.
4. post_digest interpolates the count into a Slack message pointing at the archived full report, and the errors block alerts Discord when the report cannot be produced.
5. A disabled-by-default Schedule trigger runs the report every Monday at 08:00.

What you get

• A weekly, zero-effort answer to how much the schema moved, delivered where the team already reads.
• The complete liquibase history output archived per week in internal storage, ready for audits.
• The change set count as a flow output, usable for trend dashboards or anomaly alerts.
• A pattern that scales to many databases by duplicating one task per target.

Who it's for

• Engineering managers who want schema change volume visible without asking a DBA.
• Database administrators building an audit trail of what is deployed where.
• Compliance teams that need periodic evidence of database change history.

Why orchestrate this with Kestra

The history lives in the database, but a report is a routine: run on schedule, keep the artifact, compute the summary, deliver it, and complain when it breaks. Kestra provides the schedule, internal storage for each week's full report, the output protocol that carries the Python summary into the notification, and error handling that distinguishes a quiet week from a broken pipeline.

Prerequisites

• A database reachable from the Kestra worker. For a zero-dependency demo, set the DB_URL secret to jdbc:h2:file:./demo-db with username sa and an empty password; the seeded update gives the history real entries. For production, use your real JDBC URL, such as jdbc:postgresql://db-host:5432/app, and remove the seeding update command.
• Python available on the worker for the Process-runner script, or switch its taskRunner to Docker.
• A Slack incoming webhook for the digest and a Discord incoming webhook for failure alerts.

Secrets

• DB_URL: JDBC URL of the target database.
• DB_USERNAME: database username.
• DB_PASSWORD: database password.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL for the digest.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL for failure alerts.

Quick start

1. Add the five secrets to your Kestra namespace, using the H2 URL above if you just want to see it run.
2. Execute the flow and check that Slack reports two deployed change sets from the demo changelog.
3. Point the secrets at a real database, remove the seeding update command, and enable the weekly trigger.

How to extend

• Report on several databases by adding one CLI task per target and summing the counts in the Python step.
• Diff this week's history against last week's archived artifact to list only the new change sets in the digest.
• Push the weekly count into a warehouse table to chart schema change velocity over time.
• Pair with the nightly schema drift blueprint so the digest covers both what was deployed and whether anything drifted around it.

Links

• Liquibase plugin documentation
• Liquibase history documentation