dbt-plan

dbt-plan

dbt run の前にリスクのある DDL 変更を警告する静的解析ツールです。

dbt 向けの terraform plan のようなもので、使い方も同じです。ウェアハウスを変更する処理の前に実行します。後から CI で実行するだけではありません。

Snowflake、BigQuery、Redshift、Postgres、DuckDB などのウェアハウスのコンパイル済み SQL ファイルを、単一のコードパスで解析します。SQL 方言のサポート状況は異なります。詳しくは解析の制限をご覧ください。

表示例

$ dbt-plan check

dbt-plan -- 4 model(s) changed
  dialect: snowflake (default; adapter: unknown)
  baseline: unknown revision, unknown snapshot time


Review required: DESTRUCTIVE (before policy; exit policy is separate)
Next: Review the finding evidence and affected source files before running dbt.
Next: Resolve the unreadable downstream SQL and recompile before rerunning check.

DESTRUCTIVE  int_order_enriched (incremental, sync_all_columns)
  ADD COLUMN  billing_method
  ADD COLUMN  shipping_city
  DROP COLUMN  billing_info
  DROP COLUMN  shipping_info
  Downstream: dim_customers, fct_daily_sales (2 model(s))
  >> BROKEN_REF  fct_daily_sales: reads dropped column(s): shipping_info

SAFE  dim_customers (table)
  CREATE OR REPLACE TABLE

SAFE  dim_publishers (table)
  CREATE OR REPLACE TABLE

SAFE  fct_daily_sales (incremental, append_new_columns)
  ADD COLUMN  total_sales

Causal explanations (before policy)

- DESTRUCTIVE cascade.broken_ref: source model.sample.int_order_enriched; affected model.sample.fct_daily_sales
  reads dropped column(s): shipping_info
  Source change: added billing_method, shipping_city; removed billing_info, shipping_info
  Affected/evidence columns: (not recorded); evidence: legacy_cascade / unknown / provenance_unavailable; raw risk: broken_ref; waiver eligible: false
  Review: provenance_unavailable
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None
  Step: model.sample.int_order_enriched -> model.sample.fct_daily_sales; exact direct compiled read; root attribution not established; removed shipping_info
    Config: materialized=incremental; on_schema_change=None

- DESTRUCTIVE ddl.drop_column: source model.sample.int_order_enriched; affected model.sample.int_order_enriched
  DROP COLUMN; column: billing_info
  Source change: added billing_method, shipping_city; removed billing_info, shipping_info
  Affected/evidence columns: billing_info, billing_method, customer_id, order_date, order_id, revenue, shipping_city, shipping_info; 1 columns omitted; evidence: compiled_sql / exact / column_diff_checked; raw risk: destructive; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/int_order_enriched.sql
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None

- DESTRUCTIVE ddl.add_column: source model.sample.int_order_enriched; affected model.sample.int_order_enriched
  ADD COLUMN; column: billing_method
  Source change: added billing_method, shipping_city; removed billing_info, shipping_info
  Affected/evidence columns: billing_info, billing_method, customer_id, order_date, order_id, revenue, shipping_city, shipping_info; 1 columns omitted; evidence: compiled_sql / exact / column_diff_checked; raw risk: destructive; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/int_order_enriched.sql
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None

- DESTRUCTIVE ddl.add_column: source model.sample.int_order_enriched; affected model.sample.int_order_enriched
  ADD COLUMN; column: shipping_city
  Source change: added billing_method, shipping_city; removed billing_info, shipping_info
  Affected/evidence columns: billing_info, billing_method, customer_id, order_date, order_id, revenue, shipping_city, shipping_info; 1 columns omitted; evidence: compiled_sql / exact / column_diff_checked; raw risk: destructive; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/int_order_enriched.sql
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None

- DESTRUCTIVE ddl.drop_column: source model.sample.int_order_enriched; affected model.sample.int_order_enriched
  DROP COLUMN; column: shipping_info
  Source change: added billing_method, shipping_city; removed billing_info, shipping_info
  Affected/evidence columns: billing_info, billing_method, customer_id, order_date, order_id, revenue, shipping_city, shipping_info; 1 columns omitted; evidence: compiled_sql / exact / column_diff_checked; raw risk: destructive; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/int_order_enriched.sql
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None

- WARNING input.refusal: source model.sample.dim_customers; affected model.sample.dim_customers
  Unresolved compiled SQL read from int_order_enriched while checking int_order_enriched; affected columns: billing_info, shipping_info
  Source change: not recorded
  Affected/evidence columns: (not recorded); evidence: input / unknown / read_unresolved; raw risk: warning; waiver eligible: false
  Review: read_unresolved
  Source config: materialized=table; on_schema_change=None
  Affected config: materialized=table; on_schema_change=None

- SAFE ddl.replace_table: source model.sample.dim_customers; affected model.sample.dim_customers
  CREATE OR REPLACE TABLE
  Source change: not recorded
  Affected/evidence columns: country, created_at, customer_id, customer_tier; evidence: compiled_sql / exact / column_diff_checked; raw risk: safe; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/dim_customers.sql
  Source config: materialized=table; on_schema_change=None
  Affected config: materialized=table; on_schema_change=None

- SAFE ddl.replace_table: source model.sample.dim_publishers; affected model.sample.dim_publishers
  CREATE OR REPLACE TABLE
  Source change: not recorded
  Affected/evidence columns: end_date, publisher_id, publisher_name, start_date; evidence: compiled_sql / exact / column_diff_checked; raw risk: safe; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/dim_publishers.sql
  Source config: materialized=table; on_schema_change=None
  Affected config: materialized=table; on_schema_change=None

- SAFE ddl.add_column: source model.sample.fct_daily_sales; affected model.sample.fct_daily_sales
  ADD COLUMN; column: total_sales
  Source change: added total_sales; removed (not recorded)
  Affected/evidence columns: order_count, order_date, shipping_info, store_id, total_sales, unique_customers; evidence: compiled_sql / exact / column_diff_checked; raw risk: safe; waiver eligible: true
  Compiled SQL (not a source/Jinja line): target/compiled/sample/models/fct_daily_sales.sql
  Source config: materialized=incremental; on_schema_change=None
  Affected config: materialized=incremental; on_schema_change=None

  Observation: model.sample.int_order_enriched -> model.sample.dim_customers; unknown read check; not a column-flow edge; columns (not recorded); read_unresolved
Explanation detail omitted: 0 associations; 0 graph edges not displayed. Full relevant graph and findings: JSON.
External consumer coverage: unknown. Exposures are declared consumers only.

dbt-plan: 4 checked, 3 safe, 0 warning, 1 destructive, 1 cascade risk(s); overall review: DESTRUCTIVE (before policy)

できること

dbt-plan はコンパイル済み SQL の差分を解析し、PR 作成時に危険なスキーマ変更を検出します。

• カラムの変更：SQL の差分から ADD/DROP COLUMN を検出します
• リスク評価：マテリアライゼーションと on_schema_change のルールに基づいて安全性を判断します
• カスケード解析：削除されたカラムによって影響を受ける下流モデルを検出します。該当カラムを指定しているモデルは、テキストとして照合するのではなく、プロジェクト独自のスキーマに照らして解決します。ファイル自体に変更がなくても、* を選択してそのカラムを失うモデルも検出します。また、そのカラムを固定するテストのフィクスチャも検出します。担当者への連絡が必要なエクスポージャーも特定します
• コントラクト：強制適用されたコントラクトが変更を拒否する場合、変更の方向を問わず報告します
• 設定の変更：マテリアライゼーションまたは on_schema_change ポリシーの変更を検出します
• 型の変更：リビジョン間で明示的な CAST の型を比較します
• SELECT * の解決：同じステートメント内の CTE からカラムを読み取り、ref() を参照先モデルのコンパイル済み SQL まで追跡します

解析ではファイルを読み取って比較し、警告を出します。ウェアハウスには接続せず、dbt run をシミュレートすることもありません。オプションの dbt-plan run ワークフローはコンパイルコマンドを実行します。このコマンドでは、認証情報が必要になったり、マクロが実行されたりする場合があります。

クイックスタート

ウェアハウスなしで結果を確認する

リポジトリには変更前後のコンパイル済み SQL とマニフェストが含まれているため、dbt のインストールやウェアハウスの認証情報の設定なしで解析を試せます。

git clone --depth 1 https://github.com/PresentJay/dbt-plan
cd dbt-plan
python -m pip install dbt-plan
bash examples/sample-project/run-example.sh

サンプルでは、テキスト、GitHub Markdown、JSON の出力が表示されます。意図的にカラムを削除しているため、内部チェックでは終了コード 1（destructive）が返されます。サンプルスクリプト自体は正常に完了します。想定される検出結果については、サンプルシナリオをご覧ください。

dbt プロジェクトで使う

python -m pip install dbt-plan
dbt-plan run               # compile baseline → compile current → check

dbt-plan run はすべての処理を 1 つのコマンドで実行し、通常の dbt compile に必要な認証情報を使用します。プロジェクトにすでにコンパイル済みアーティファクトがある場合は、dbt-plan check を直接使ってください。ローカルファイルを読み取るだけで、ウェアハウスには接続しません。

想定されている反復作業

ベースラインを用意すれば、内側のループは 1 秒未満で完了する単一のコマンドです。モデルまたはマクロを編集して再コンパイルし、dbt run を実行する前に、実行した場合の結果を確認できます。

dbt-plan snapshot          # once, on the revision you are changing from
                           # ... edit models, edit macros ...
dbt compile && dbt-plan check

dbt-plan check はローカルのコンパイル済みアーティファクトを読み取ります。その所要時間は、アダプター、マクロ、ウェアハウスによって変わる場合がある dbt compile とは別です。測定したワークロード、未加工のサンプル、お使いのマシンで測定するコマンドについては、再現可能な CLI ベンチマークをご覧ください。

コーディングエージェントとの連携

モデルを編集するエージェントは、差分を目視して判断をためらうことはできません。チェック方法と、その理由を伝えてください。

dbt-plan agent-setup       # writes dbt-plan guidance into your AGENTS.md
dbt-plan check --format json

このガイダンスでは、エージェントが最もよく誤る点を最初に説明しています。モデルをignore_modelsに追加したり、on_schema_changeをsync_all_columnsからignoreに引き下げたりすると、実際の問題を変更の安全性を確保しないまま見えなくしてしまいます。

または、MCP ツールとしてチェックを提供します。

pip install 'dbt-plan[mcp]'
dbt-plan-mcp                # stdio MCP server exposing `plan` and `snapshot`

planは、判定、モデルごとの操作、そして別個のrefusalsリストを返します。このリストには、dbt-planが判定を拒否した項目がすべて記載されます。この区別が重要です。「安全」と読んだ人は差分を確認するかもしれませんが、そう読んだエージェントはそのまま処理を進めます。そのため、空でないrefusalsを判定にまとめてしまってはなりません。

dbtがデフォルトのtarget/以外の場所にアーティファクトを書き出す場合は、どちらのツールでもtarget_dirを指定できます。たとえば、plan(project_dir=".", target_dir="build")のように指定します。

サーバーは分析コアとは別のパッケージです。コアはオフラインで同期的に動作するよう設計されており、tests/test_invariants.pyはコア内部のどこかにasyncioまたはネットワーク関連のインポートがあると、ビルドを失敗させます。MCP サーバーはその両方を使用するため、両者を分離することで、この保証を検証可能にしています。

レジストリーのエントリー — 以下の行は、エントリーを公開する人がこのPyPIパッケージの所有者でもあることをMCPレジストリーが検証するためのものです。そのため、配布するREADMEに記載したままにする必要があります。

mcp-name: io.github.PresentJay/dbt-plan

その他のコマンド

dbt-plan init              # Generate .dbt-plan.yml config + update .gitignore
dbt-plan stats             # Analyze project readiness
dbt-plan ci-setup          # Generate GitHub Actions workflow
dbt-plan check --format github   # GitHub markdown output
dbt-plan check --format json     # JSON for CI pipelines
dbt-plan run --against main           # compare with where this branch left main
dbt-plan check --select fct_orders    # one model
dbt-plan check --select fct_orders+   # it and everything downstream

--selectではモデル名と、任意の上流／下流+演算子を指定できます。カンマ区切りの項目は和集合になります。次のマイナーリリースでは、サポートされていない選択や不明な選択を指定すると、終了コード3で失敗します。fct_orders_v2のような明示的なバージョン名を使用してください。選択の仕様と例を参照してください。

対象範囲

dbt-planは、静的解析による警告ツールであり、実行時シミュレーターではありません。

対象範囲内	対象範囲外
コンパイル済みSQLからの列の追加／削除の検出	dbt runのシミュレーション
materialization × on_schema_change のリスクルール	ウェアハウスへの接続
カスケード：参照切れ、ビルド失敗、継承された列の損失	seed／sourceの変更検出
設定変更の検出（materialization、osc）	pre_hook／post_hookのDDL分析
ユニットテストのフィクスチャと、下流のexposureオーナー	dbt-planが読み取れないseed／sourceのフィクスチャ
適用される契約の違反：名前、およびファミリー単位の型	ファミリー単位より細かい契約型の比較
明示的なCASTによる型変更	キャストされていない列の型変更
CTEとref()を通じて解決されるSELECT *	sourceまたは生テーブルに対するSELECT *
CIの終了コード＋構造化出力	full_refreshモードの判定

設計原則：誤った警告は許容しますが、誤って安全と判定することは決して許容しません。

使用する場面

dbt-planが答えるのは、ウェアハウスに接続するツール（Recce、 SQLMesh、data-diff）よりも限定的な質問であり、実行コストもかかりません。そのため、これらのツールを使う前の手軽なゲートとして利用できます。また、ウェアハウスへの接続なしでコンパイルできるFusionエンジンでは、これらのツールをまったく実行できないフォークからのプルリクエストにも対応できます。比較、実際の実行時間、誤判定する内容については、ユースケースを参照してください。

意図的に計画対象外とした項目

有用に見えても、このツールの方針に反するアイデアを示します。

アイデア	対象外とする理由
INFORMATION_SCHEMAへのクエリ	ウェアハウスへの接続が必要です。dbt-planはファイルだけを読み取り、それ以外は読みません。そのため、入力が存在する場所ならどこでも実行できます。プロジェクトをFusionでコンパイルできれば、フォークからのプルリクエストも含まれます。
明示的なCASTがない列の型変更	型はウェアハウスが割り当てるため、変更を検出するにはウェアハウスに問い合わせる必要があります。両側で明示的にキャストされている列は比較されます。詳しくは以下を参照してください。

DDL 予測ルール

マテリアライゼーション	on_schema_change	予測される DDL	安全性
table	any	CREATE OR REPLACE TABLE	SAFE
view	any	CREATE OR REPLACE VIEW	SAFE
ephemeral	any	(物理オブジェクトなし)	SAFE
snapshot	any	REVIEW REQUIRED	WARNING
incremental	ignore	スキーマ DDL なし。既存のターゲットは列変更時に失敗する可能性があります	変更または不明な列がある場合は WARNING
incremental	fail	ビルド失敗	WARNING
incremental	append_new_columns	ADD COLUMN のみ	SAFE
incremental	sync_all_columns	ADD + DROP COLUMN	列が削除された場合は DESTRUCTIVE
any	(モデルが削除された場合)	MODEL REMOVED	DESTRUCTIVE
any	(不明な osc)	UNKNOWN on_schema_change	WARNING
materialized_view / custom	(自分で設定していない場合)	UNKNOWN materialization	WARNING
materialized_view / custom	(自分で設定した場合)	incremental のルールに従う	osc に応じる
any	(contract: {enforced: true})	CONTRACT VIOLATION	WARNING

コントラクトでは、列の宣言された data_type と明示的な CAST を、型の系統ごとに比較します。テキスト、数値、日付／時刻、ブール値の間で比較します。varchar と text は同じ系統であり、問題にはなりません。varchar と integer の場合はビルドに失敗します。より細かく比較するにはアダプターごとの型テーブルが必要です。型について誤った判定をするより、判定しないほうが適切です。

「自分で設定していない」とは、作成者がモデルにも dbt_project.yml にも on_schema_change を記述していないことを意味します。dbt はすべてのモデルについて値を解決するため、解決済みの値からは何も断定できません。明示的な設定は、そのマテリアライゼーションの動作に関する宣言であり、その内容に従います。dbt-plan は unrendered_config を読み取り、両者を区別します。

強制されたコントラクトでは、上記のルールが逆になります。dbt はすべての列を宣言するよう求めるため、SQL に列を追加すると、列を削除した場合と同様にビルドに失敗します。名前だけが対象です。dbt は宣言された data_type をウェアハウスの型と比較しますが、dbt-plan はウェアハウスを読み取りません。

CI との統合（GitHub Actions）

name: dbt-plan
on:
  pull_request:

jobs:
  plan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    env:
      # Whatever your profiles.yml reads. `dbt compile` connects; dbt-plan does not.
      UV_PROJECT_ENVIRONMENT: ${{ runner.temp }}/project-venv
      SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
      SNOWFLAKE_USER: ${{ secrets.SNOWFLAKE_USER }}
      SNOWFLAKE_PRIVATE_KEY: ${{ secrets.SNOWFLAKE_PRIVATE_KEY }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0          # the base revision has to be in the clone
          persist-credentials: false
      - uses: actions/setup-python@v5
        with: { python-version: '3.12' }
      - run: pip install uv
      - run: uv sync --locked

      - uses: PresentJay/dbt-plan@v1
        with:
          compile-command: uv run --no-sync dbt compile

この例では、dbt アダプターを含む uv.lock がリポジトリにコミットされていることを前提としています。仮想環境はチェックアウトの外部に配置されるため、リビジョンを切り替えても置き換えられません。pip／requirements.txt を使う場合は、Action の前にアダプターをインストールし、デフォルトの dbt compile コマンドを使用してください。プロジェクトで dbt パッケージを使用している場合は、先に dbt deps を実行してください。

pull_request トリガーはそのままにしてください。pull_request_target には絶対に切り替えないでください。dbt compile は、プルリクエスト内に記述された Jinja とマクロを実行するため、切り替えると、あらゆるフォークのコードにウェアハウスの認証情報を渡すことになります。

入力	デフォルト
compile-command	dbt compile	リビジョンごとに 1 回、合計 2 回実行します。
base-ref	PR のベース	比較対象のリビジョンです。
project-dir	.	dbt プロジェクトのディレクトリです。
target-dir	target	project-dir からの相対パスで指定する dbt アーティファクトのディレクトリです。dbt の出力先が build などのカスタムパスの場合に設定します。
dialect	空	CLI の設定と manifest によるアダプター検出を維持し、その後 snowflake にフォールバックします。プロジェクトの設定を上書きする場合のみ指定してください。
version	最新	dbt-plan のリリースを固定します。
fail-on	destructive	warning または never も指定できます。
summary	true	レポートをジョブステップのサマリーに書き込みます。

verdict（safe／destructive／warning）、exit-code、report（JSON レポートへのパス）を出力します。後続のステップで PR にコメントしたり、チケットを作成したりできます。

ラップされた Action ではなく、自分で全面的に管理するワークフローの場合、dbt-plan ci-setup は認証情報の設定と最小権限に関する注記をインラインで含むワークフローを生成します。次のマイナーバージョンのジェネレーターは pyproject.toml／uv.lock と requirements.txt に対応しており、dbt と dbt-plan を 1 つの環境にインストールし、サマリーのレンダリングとゲート処理を分離します。デフォルトの FAIL_ON: destructive では警告は許可されますが、実行エラーは常にブロックされます。この機能を利用するには、既存のワークフローを再生成してください。詳細は docs/ci-integration.md を参照してください。

終了コード

次のマイナーリリースでは、実行エラーとレビュー結果を分離します（0.15.x からの破壊的変更です）。この仕様は main に実装済みですが、まだリリースされていません。

コード	意味
0	設定されたポリシーのもとで、ブロック対象の指摘事項はありません。
1	破壊的な指摘事項があります。
2	レビューが必要です：SQL の不確実性、またはビルド／テスト失敗の可能性があります。
3	実行に失敗しました：入力が無効、成果物が不足、コンパイル／復旧に失敗、または内部エラーが発生しました。判定は完了していません。

warning_exit_code は引き続きレビュー結果を制御します。デフォルトは 2 のままです。 これを 0 に設定しても、実行エラーは抑制されません。コード 3 は予約済みで、警告には使用できません。fail-on: never を指定していても、実行エラーが発生すると Action は失敗します。CI スクリプトまたは固定バージョンの Action をアップグレードする前に、移行ガイドを参照してください。

仕組み

flowchart TD
    A[dbt-plan snapshot] --> B[Save compiled SQL + manifest.json]

    C[dbt-plan check] --> D[diff_compiled_dirs]
    D --> E[base compiled SQL]
    D --> F[current compiled SQL]
    E --> G[extract_columns]
    F --> H[extract_columns]
    G --> I[base columns]
    H --> J[current columns]
    I --> K[column diff]
    J --> K
    K --> L[predict_ddl + manifest config]
    L --> M{Safety?}
    M -->|SAFE| N[exit 0]
    M -->|WARNING| O[exit 2]
    M -->|DESTRUCTIVE| P[exit 1 — block merge]
    L --> Q[find_downstream]
    Q --> R[format_text / format_github]

コントリビューション

開発環境のセットアップ、TDD ワークフロー、コーディング規則については、CONTRIBUTING.mdを参照してください。

初めてのコントリビューションですか？ 小さく、すぐに着手できるタスクを選んでください： SQL フィクスチャ、ドキュメントやサンプルスクリプトの修正など、期待される結果が明確で、ウェアハウスの認証情報も不要なタスクです。

コントリビューター向けの CI フィードバック： このリポジトリへの PR には、テスト済みのコミット、承認待ちの状態、失敗したジョブへのリンクを含むステータスコメントが自動で 1 件投稿され、最新の情報に更新されます。/ci とコメントすると更新でき、/ci retry とコメントすると一時的な失敗を再試行できます。外部からのコントリビューションでは、引き続きメンテナーによる実行承認が必要です。再試行しても承認は不要になりません。コマンドと制限を参照してください。このヘルパーは dbt-plan 自体へのコントリビューション向けであり、ご自身の dbt プロジェクトにインストールする GitHub Action とは別のものです。

アーキテクチャ

src/dbt_plan/
├── columns.py      # SQLGlot column extraction (multi-dialect)
├── config.py       # .dbt-plan.yml + env var configuration
├── predictor.py    # DDL risk assessment rules + cascade analysis
├── manifest.py     # manifest.json parsing + downstream BFS
├── diff.py         # compiled SQL directory comparison
├── formatter.py    # text / GitHub markdown / JSON output
└── cli.py          # CLI: snapshot, check, init, stats, run, ci-setup

コントリビューションの方法

まずはこちらから： 未解決の Issue、特に good first issue ラベルの付いた Issue をご覧ください。 各スターター Issue には、合意済みの範囲、期待される結果、検証コマンドが記載されています。着手する前に、担当者と最近のコメントを確認し、担当することを伝えてください。

設計上の決定事項： docs/design-notes.mdを参照してください。

サポート対象

• dbt-core 1.7 以降、および dbt Fusion エンジン（2.0.0-preview.218 で検証済み）
• Snowflake、BigQuery、Redshift、Postgres、DuckDB、その他のマッピング済みアダプター：方言はマニフェストから推定されます。マッピングされていないアダプターは Snowflake にフォールバックします。分析の制限を参照してください。
• Python 3.10 以降
• CTE、UNION ALL、QUALIFY、ウィンドウ関数、VARIANT アクセス

ライセンス

Apache-2.0

アダプターの方言フォールバック、dbt Mesh の利用者、ソースやシードに対するスターについては、分析の制限を参照してください。CLI の compile_command の argv セマンティクス、Action のシェルコマンド入力、dbt deps のセットアップについては、コンパイルコマンドを参照してください。