Dispatch a GitHub Actions Deploy When dbt Finishes

Connect your data pipeline to your delivery pipeline so a GitHub Actions deploy fires the moment your dbt models finish building. This blueprint closes the gap between "data is fresh" and "the app that depends on it ships", removing the manual hand-off where someone watches dbt finish and then clicks Run on a GitHub Actions workflow. A webhook from dbt starts the flow, Kestra verifies the upstream run actually succeeded, dispatches the deploy workflow with traceable inputs, and reports the outcome to Slack. The result is an event-driven, auditable bridge between dbt transformations and GitHub Actions deployments.

How it works

1. The on_dbt_complete trigger (io.kestra.plugin.core.trigger.Webhook) exposes a webhook URL guarded by a secret key. dbt POSTs to it when a run completes, and the request body becomes available as trigger.body.
2. confirm_dbt_run (io.kestra.plugin.core.http.Request) issues a GET against the dbt_status_url input to confirm the upstream run succeeded. If that request fails, the flow stops before anything is deployed.
3. dispatch_deploy (io.kestra.plugin.github.actions.RunWorkflow) dispatches the target GitHub Actions workflow on the chosen repository, workflowId, and ref, passing triggered_by: kestra and a dbt_execution reference ({{ trigger.body ?? execution.id }}) so the deploy is linked back to the dbt run that caused it.
4. notify (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a message naming the workflow, repository, and ref that were dispatched.

What you get

• Zero-touch deploys triggered by dbt completion instead of a manual click.
• A safety check that blocks the deploy if the dbt run did not succeed.
• Deploy runs tagged with the originating dbt execution for traceability.
• A Slack message confirming exactly what was dispatched and where.

Who it's for

• Analytics engineers who want downstream apps to ship as soon as models are rebuilt.
• Platform and DevOps teams standardizing how GitHub Actions deploys are triggered.
• Data teams that need an audit trail linking transformations to deployments.

Why orchestrate this with Kestra

GitHub Actions can schedule and react to repository events, but it has no native awareness of when an external dbt run finishes. Kestra fills that gap: the webhook trigger turns a dbt completion event into a deploy, the HTTP confirmation step enforces a success precondition GitHub Actions cannot see, and built-in retries, full execution lineage, and declarative YAML keep the whole hand-off versioned and observable. You describe the cross-tool workflow once instead of wiring brittle glue scripts between two schedulers.

Prerequisites

• A GitHub Actions workflow configured with a workflow_dispatch trigger and matching inputs.
• dbt (or your dbt scheduler) able to POST to a webhook on run completion.

Secrets

• GITHUB_TOKEN: token authorized to dispatch workflows on the target repository.
• DBT_COMPLETE_WEBHOOK_KEY: key guarding the webhook trigger.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL for notifications.

Quick start

1. Add GITHUB_TOKEN, DBT_COMPLETE_WEBHOOK_KEY, and SLACK_WEBHOOK_URL as secrets in your Kestra namespace.
2. Configure dbt to POST to the webhook URL when a run completes.
3. Set the repository, workflow_id, ref, and dbt_status_url inputs.
4. Trigger a dbt run and watch Kestra confirm, dispatch, and notify.

How to extend

• Add a Pause task before dispatch_deploy to require human approval on production deploys.
• Branch on the confirm_dbt_run response body to deploy only specific environments.
• Replace or supplement the Slack notification with email, PagerDuty, or a GitHub status update.
• Chain a post-deploy smoke-test task and a rollback dispatch if it fails.

Links

• Plugin docs: GitHub