Terragrunt HCL Quality Gate with hclfmt and hclvalidate

Broken or unformatted HCL should never reach a plan, let alone an apply. Terragrunt ships two purpose-built checks for this: hclfmt --check fails when any .hcl file deviates from canonical formatting, and hclvalidate fails when the configuration contains invalid constructs. This blueprint wires both into a webhook-triggered Kestra flow that CI, a Git provider, or a curl call can invoke, and posts exactly one verdict message to Discord whether the gate passes or fails.

The demo ships a small, correctly formatted repository inline through inputFiles, so the first execution demonstrates the passing path with no setup beyond two secrets.

How it works

1. The ci_webhook trigger (io.kestra.plugin.core.trigger.Webhook) starts the flow on demand, secured by a webhook key from a secret, so a pipeline step or a push webhook can invoke the gate.
2. hcl_checks (io.kestra.plugin.terragrunt.cli.TerragruntCLI) materializes the repo and runs terragrunt hclfmt --check --working-dir live, then terragrunt hclvalidate --working-dir live. Each command's result is captured into a flag with || fmt_ok=0 style guards instead of failing the task, so both checks always run and the verdict is always produced.
3. Both flags are emitted through Kestra's outputs protocol as {{ outputs.hcl_checks.vars.fmt_ok }} and {{ outputs.hcl_checks.vars.val_ok }}.
4. verdict (io.kestra.plugin.core.flow.If) posts a Discord pass message when both flags are 1, and a fail message naming which check broke otherwise.
5. The errors block posts a separate crash alert, distinguishing "the code failed the gate" from "the gate itself did not run".

What you get

• Formatting and validity enforced before any plan or apply spends time or touches state.
• Both checks always run, so authors see the complete picture in one pass instead of fixing issues serially.
• A single, unambiguous Discord verdict per invocation, pass, fail with details, or crash.
• A webhook interface any CI system can call with one HTTP request.

Who it's for

• Platform teams enforcing HCL hygiene across a Terragrunt mono-repo touched by many contributors.
• Teams that want configuration linting centralized in the orchestrator rather than copy-pasted into every repository's CI file.
• Reviewers who want formatting arguments settled by a bot before the human review starts.

Why orchestrate this with Kestra

Running these checks in scattered CI scripts means every repository re-implements the same steps, and the results vanish with the CI run. In Kestra, the gate is one flow with a stable webhook URL, every invocation is an execution with logs and structured outputs, and the same flow can grow richer steps, a plan on success, a ticket on repeated failures, without touching any repository's pipeline definition.

Prerequisites

• A Discord incoming webhook for verdicts and crash alerts.
• A webhook key of your choosing stored as a secret.
• No cloud credentials are needed, the gate only parses and formats HCL.

Secrets

• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.
• WEBHOOK_KEY: key that authorizes calls to the webhook trigger.

Quick start

1. Add the DISCORD_WEBHOOK_URL and WEBHOOK_KEY secrets to your Kestra namespace.
2. Execute the flow manually once and check Discord for the PASSED verdict.
3. Call the webhook URL from your CI step or Git provider on every push to run the gate automatically.

How to extend

• Replace the inline inputFiles with namespaceFiles or a io.kestra.plugin.git.Clone task that checks out the commit referenced in the webhook body.
• Add terragrunt run-all validate as a third, deeper check once the fast gates pass.
• Fail the flow on a red verdict by adding an exit after the outputs echo, if your CI waits on the execution state instead of the Discord message.
• Post the verdict back to the pull request with an HTTP Request task against your Git provider's API.

Links

• Terragrunt plugin documentation
• Terragrunt documentation