Validate Releases with a Sifflet Rule Run

Code review and unit tests catch broken logic, but a transformation change that quietly halves a table sails through both. The regression usually surfaces the next morning, when the scheduled monitor finally runs and nobody remembers which deploy caused it. This blueprint closes that gap: the last step of your CI deploy job calls a Kestra webhook, io.kestra.plugin.sifflet.RunRule launches the rule guarding the affected data domain, and Discord shows the outcome right next to the release announcement, minutes after the merge.

How it works

1. The on_deploy trigger (io.kestra.plugin.core.trigger.Webhook) exposes an HTTP endpoint guarded by a secret key. A curl step at the end of a GitHub Actions or GitLab CI deploy job fires the flow.
2. validate_release (io.kestra.plugin.sifflet.RunRule) authenticates with the API key, targets your tenant through baseUrl, and launches a run of the rule named by the rule_id input, the monitor covering the models or tables the release touched.
3. The task exposes status, statusCode, ruleId, and the raw response; notify_channel posts the status to Discord so the validation lands in the same channel as the deploy.
4. The errors block posts a distinct alert when the validation fails to launch, telling the team to treat the deploy as unvalidated.
5. The execution history maps releases to validations one-to-one, so "which deploy broke the data" becomes a lookup instead of an investigation.

What you get

• A data check that runs minutes after each deploy, while the change is still fresh and revertable.
• Validation outcomes posted where releases are announced, so the two are read together.
• Loud failure when the check itself cannot run, keeping "unvalidated" and "validated" honestly separate.
• An execution trail linking each release to its data validation for audits and postmortems.

Who it's for

• Analytics engineers shipping dbt or SQL changes that can silently damage downstream tables.
• Platform teams who want data validation in the deploy pipeline without teaching CI to talk to Sifflet directly.
• Release managers who need evidence that every production change was followed by a data check.

Why orchestrate this with Kestra

Wiring CI to Sifflet directly means API keys in CI secrets, retry logic in shell, and results that vanish with the job log. Routing through Kestra keeps the Sifflet credentials in one namespace, gives the validation its own execution with logs and state, and lets the same flow serve every repository, each CI job just posts to the webhook. Changing which rule guards a domain is an input edit, not a CI change.

Prerequisites

• The Sifflet rule ID covering the data domain your releases affect.
• A Sifflet API key with permission to run rules.
• A CI pipeline able to POST to a URL after deployment.
• A Discord incoming webhook posting into the release channel.

Secrets

• SIFFLET_API_KEY: Sifflet API bearer token used to run the rule.
• SIFFLET_BASE_URL: base URL of your Sifflet tenant API.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.
• SIFFLET_RELEASE_WEBHOOK_KEY: secret key guarding the webhook endpoint.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Execute the flow manually with a real rule_id and confirm the Discord message arrives.
3. Add a curl step to the end of your CI deploy job that POSTs to the webhook URL, and ship a release to see the validation fire.

How to extend

• Validate a whole domain instead of one rule by adding a ForEach, as shown in the Sifflet rule pack fan-out blueprint.
• Pass the affected domain in the CI webhook body and select the rule from it, keeping one flow for many services.
• Gate a promotion step behind the validation, as shown in the Sifflet pre-dashboard gate blueprint, to hold canary releases until the rule run launches cleanly.
• Add retry on the rule task so a transient API blip does not mark a good release as unvalidated.

Links

• Sifflet plugin documentation
• Sifflet documentation