Docs
amfelt sql check
Renders the SQL again and reports every file whose contents would change, without writing the generated SQL tree itself. Exits non-zero when anything differs, so a pull request that leaves generated SQL stale is caught before it is merged.
Rendering needs the same target connection sql generate does — there is no way
to ask a plugin what it would render without connecting to it first, using your
target’s real, configured connection details. That connection is real, not
simulated: rendering itself runs in dry-run mode, so no statement is ever
executed against your warehouse, but a target that keeps its data as a local
file (DuckDB, for one) can still have that file created or written to, inside
your own project directory, purely from being asked to render — the same as it
would for sql generate. This is not something to run in a CI runner that
cannot reach your target — it fails the same way sql generate’s own connection
would.
Usage
amfelt sql check [flags]Examples
sql check
Reports any generated SQL that is out of date, and fails if there is any.Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--path | string | amfelt.yaml | path of the Amfelt project file |
Global flags
| Flag | Type | Default | Description |
|---|---|---|---|
--amfelt-dir | string | .amfelt | directory for workspace files (such as plugins); does not move agent identity (controlled by AMFELT_DIR) |
--config | string | — | directory or filename of the application configuration |
-f, --format | string | default | log format to use; either default, pretty, or json |
-l, --level | string | info | minimum log level to display; either error, warn, info, or debug |
-v, --verbose | bool | false | trigger to use verbose logging |
See also
sql— the parent command
Generated from amfelt v5.6.3.
Last updated on November 1, 2026