継続的インテグレーション スタイル バリデータ

継続的インテグレーション（CI）スタイル バリデータは、LookML スタイル リンターを使用して、LookML プロジェクト全体で LookML コーディング標準、命名規則、構造のベスト プラクティスを適用します。スタイル バリデータは、構成可能な一連のスタイルルールに照らして LookML ファイルをチェックすることで、チームがクリーンで一貫性があり、読みやすいコードベースを維持するのに役立ちます。

スタイル バリデータを実行するには、LookML プロジェクト リポジトリのルート ディレクトリに lkmlstyle.yaml（または lkmlstyle.yml）という名前の構成ファイルを追加する必要があります。スタイル リンターの構成について詳しくは、このページの構成ファイルのセクションをご覧ください。

CI スイートでスタイル バリデータの設定と実行を行い、検証出力を表示する方法については、継続的インテグレーション スイートを作成する、継続的インテグレーション スイートを実行する、CI 実行の結果を表示するのドキュメント ページをご覧ください。

始める前に

継続的インテグレーションでスタイル バリデータを使用するには、次のものが必要です。

構成ファイル

Looker CI でスタイル バリデータを実行するには、構成ファイルが必要です。スタイル バリデータが実行されると、LookML プロジェクト リポジトリのルート ディレクトリで、次の優先順位で構成ファイルが自動的にチェックされます。

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

両方のファイルがルート ディレクトリに存在する場合、lkmlstyle.yaml が優先され、lkmlstyle.yml は無視されます。

プロジェクトのルート ディレクトリに lkmlstyle.yaml も lkmlstyle.yml も見つからず（API を介してカスタム構成が渡されない場合）、スタイル検証の実行はエラー "No style validator configuration provided" で失敗します。

25 個の標準の組み込みルールをデフォルト設定で実行するには、lkmlstyle.yaml ファイルで次の最小構成情報を使用します。

schema_version: 1
ruleset_version: "all-v1.0"

それ以外の場合は、構成ファイルをカスタマイズできます。構成ファイルには、次の最上位パラメータを含めることができます。

パラメータ 種類 必須かどうか デフォルト 説明
schema_version Integer ○ なし 構成スキーマのバージョン。サポートされているバージョンは 1 のみであり、明示的に指定する必要があります。
ruleset_version 文字列 ○ なし 継承するベースライン ルールセット エディション。サポートされる値: "all-v1.0"、"none"。
ignore_files 文字列のリスト いいえ [] スタイル検証から完全に除外するファイルの glob パターン。
rules 地図 いいえ {} 個々のルールに対するグローバル カスタマイズ（severity と version）。ベースライン ルールセットに含まれていない組み込みルールを有効にしたり、カスタムルールの重大度を変更したりすることもできます。例については、ルールのカスタマイズ セクションをご覧ください。
overrides 地図のリスト いいえ [] 特定のファイルパスに一致する重大度を調整または有効にするスコープ付きルールオーバーライド。
custom_rules 地図のリスト いいえ [] 宣言型のユーザー定義カスタムルール。

ruleset_version

ruleset_version パラメータは、スタイル検証戦略の基盤を定義します。

  • "all-v1.0"（推奨）: 25 個の標準の組み込み LookML スタイルルールをすべて error の重大度レベルで有効にします。このオプションは、包括的な品質の適用をすぐに利用したいチームに最適です。
  • "none": 組み込みルールが 1 つも有効になっていない状態で開始します。このオプションは、スタイル検証を段階的に導入したいチーム、特定のルールを 1 つずつ有効にしたいチーム、カスタム組織ルールのみを実行したいチームに最適です。ruleset_version が "none" の場合に組み込みルールを有効にするには、rules ブロックまたは overrides ブロックで、ルールに warn または error の重大度を割り当てます。

ignore_files

ignore_files パラメータは、スタイル検証を完全にバイパスするファイルの glob パターンのリストを受け取ります。これらのパターンに一致するファイルは、組み込みルールまたはカスタムルールの検査対象になりません。

サポートされているワイルドカード構文は次のとおりです。

  • *: 単一のディレクトリ レベル内の区切り文字以外の任意のシーケンスに一致します。
  • **: 複数のネストされたディレクトリ レベルにまたがる任意の文字列に一致します。
  • ?: 任意の 1 文字と一致します。
  • {a,b} と [abc]: 代替と文字クラス（Java glob 構文）を照合します。

次のパス照合ルールは、最上位の ignore_files、overrides の files と ignore_files を含む、構成ファイル内のすべての glob パターンに適用されます。

  • パスはプロジェクトのルート ディレクトリからの相対パスです。先頭の ./ または / は無視されます。
  • スラッシュ（/）のないパターンは、任意のディレクトリの深さで一致します。たとえば、*.ignore.lkml は x.ignore.lkml と views/x.ignore.lkml の両方に一致します。
  • / で終わるパターンは、そのディレクトリ内のすべてのものに一致します。
  • .lkml または .lookml で終わるパターンは、複合拡張子にも一致します。たとえば、*.ignore.lkml は x.ignore.view.lkml と一致します。

次の例では、ベンダー ファイル、以前の LookML ファイル、LookML ダッシュボードが除外されています。

ignore_files:
  - "vendor/**"
  - "legacy/**/*.lkml"
  - "*.ignore.lkml"
  - "dashboards/*.dashboard.lookml"

rules

rules ブロックを使用すると、プロジェクト全体で個々のルールの診断の重大度を調整できます。

rules:
  boolean-dimension-name-prefix:
    severity: warn
  view-dimension-order:
    severity: disabled
  numeric-measure-value-format-presence:
    severity: error

rules（または overrides ブロック）にリストされている重大度が warn または error の組み込みルールは、ruleset_version が "none" に設定されている場合でも有効です。たとえば、次のスターター構成は ruleset_version: "none" で始まり、2 つの組み込みルールのみを有効にします。

schema_version: 1
ruleset_version: "none"

rules:
  join-relationship-presence:
    severity: error
  explore-label-presence:
    severity: warn

rules ブロックを使用して、カスタムルールの名前を参照して重大度を変更することもできます。

severity

各ルールは、次のいずれかの大文字と小文字を区別しない重大度レベルで構成できます。

  • error: 致命的な違反として扱われます。エラーが発生すると、CI 実行が失敗します。
  • warn: ブロックしない警告として出力されます。警告は CI 実行レポートに表示されますが、CI 実行が失敗することはありません。
  • disabled: ルールを完全に無効にし、検証時にスキップします。

overrides

overrides パラメータを使用すると、LookML プロジェクトの他の部分の重大度を変更することなく、特定のファイルまたはディレクトリのルールの重大度を変更できます。たとえば、overrides を使用して、ステージング ビューや以前のモデルのルールを緩和したり、クリティカル パスのルールを厳格にしたり、ruleset_version が "none" の場合に特定のディレクトリに対してのみ特定のルールを有効にしたりできます。

overrides リストの各エントリは、次のフィールドをサポートしています。

フィールド 種類 必須かどうか 説明
files 文字列のリスト ○ このオーバーライド ブロックが適用されるファイルに一致する glob パターン。空白にはできません。
ignore_files 文字列のリスト いいえ この特定のオーバーライド ブロックから除外する glob パターン。
rules 地図 ○ ルール名と重大度構成のマッピング。空欄にすることはできません。オーバーライド ブロックでは severity のみが許可されています（必須）。ルール名は、有効な組み込みルール名またはカスタムルール名である必要があります。

次の例では、ディメンションの順序チェックを無効にし、以前のビューとダッシュボードで説明がないエラーを警告にダウングレードしています。

overrides:
  - files:
      - "views/legacy/**"
      - "dashboards/*.dashboard.lookml"
    ignore_files:
      - "views/legacy/core_*.view.lkml"
    rules:
      view-dimension-order:
        severity: disabled
      visible-dimension-description-presence:
        severity: warn

custom_rules

構成ファイルの custom_rules セクションで宣言型のカスタムルールを定義して、組織固有の命名規則、必要なアーキテクチャ パターン、構造ガバナンスを適用できます。

すべてのカスタムルール定義は、次の共通パラメータをサポートしています。

フィールド 種類 必須かどうか 説明
name 文字列 ○ 固有識別子。慣例により、finance-measure-prefix などのダッシュケース形式。組み込みのルール名や他のカスタムルールと競合してはなりません。
title 文字列 ○ 違反が発生したときに報告される、人が読める形式のメッセージ。(<rule-name>) <title> 形式で指定します。
rule_type 文字列 ○ ルールのアーキタイプ: pattern_match、property、order、first_child、unique。大文字と小文字は区別されません。pattern は pattern_match のエイリアスとして受け入れられます。
severity 文字列 いいえ 診断レベル: error（デフォルト）、warn、disabled。rules と overrides でオーバーライドできます。
rationale 文字列 いいえ ルールの存在理由を文書化します。
select 文字列またはリスト いいえ ターゲットの抽象構文ツリー（AST）ノードパス（"view.dimension"、"explore"、["dimension", "dimension_group"] など）。省略すると、ルールは filters に一致するすべてのノードをターゲットにします。
filters 地図 いいえ ターゲット ノードで一致する必要があるプロパティ フィルタ（primary_key: true など）。
parent_filters 地図 いいえ ターゲット ノードの直近の親と一致する必要があるプロパティ フィルタ。

各ルールタイプは、独自のタイプ固有のキーのみを受け入れます。不明なキーや、別のルールタイプに属するキー（pattern_match ルールの order_by など）は、構成エラーになります。

select

select パラメータは、カスタムルールで評価する LookML 要素を決定します。

  • 直接要素: select: "dimension"、select: "measure"、select: "view"、select: "explore"、select: "join"、select: "model"、select: "include" などの特定の LookML 要素タイプをターゲットにします。
  • ネストされた親子パス: 特定の直近の親内で定義されたターゲット要素（select: "view.dimension"（ビュー内で定義されたディメンション）や select: "explore.join"（Explore 内で定義された結合）など）。親は直近の親である必要があり、パスの最後の 2 つのセグメントのみが使用されます（そのため、a.b.c は b.c のように動作します）。
  • 複数のターゲット: カンマ区切りの文字列またはリスト（select: "dimension, dimension_group" や select: ["dimension", "dimension_group"] など）を使用して、複数の要素タイプをターゲットに設定します。

セレクタ、フィルタ、子名は、大文字と小文字を区別する LookML キーワードです。名前のスペルミスは構成エラーとして報告されず、ルールが一致することはありません。

filters と parent_filters

filters と parent_filters を使用して、LookML ファイルで明示的に宣言されている LookML プロパティに基づいて、ターゲット ノードを絞り込むことができます。

  • ブール値の等価性: primary_key: true や hidden: true など、明示的に宣言されたブール値プロパティを照合します。
  • 文字列の等価性: type: "yesno" や type: "count" などの文字列値を正確に照合します。
  • One-of リスト: type: ["string", "number", "date"] などのリスト内の任意の値と一致します。
  • 存在チェック: derived_table: "" などの空の文字列を渡して、ブロックまたはプロパティが存在するかどうかを確認します。
  • 否定: キーまたは値の前に ! を付けると、フィルタが否定されます。否定キーは引用符で囲む必要があります。引用符で囲まれていない先頭の ! は YAML タグ構文であり、構成ファイルの解析が失敗します。
    • "!hidden": true または hidden: "!true" は、hidden を宣言しないフィールドを含む、表示されている（非表示でない）項目に一致します。
    • type: ["!yesno", "!date"] は、yesno でも date でもない型に一致します。

rule_type

各カスタムルールでは、rule_type パラメータに次の 5 つのルール アーキタイプのいずれかを指定する必要があります。

pattern_match

LookML エンティティ名またはプロパティ値に正規表現パターンを適用します。match または should_not_match のいずれか 1 つのみを指定する必要があります（両方が設定されている場合は、match のみが適用され、should_not_match は無視されます）。

  • match（文字列、正規表現）: ターゲットが一致する必要があるパターン。
  • should_not_match（文字列、正規表現）: ターゲットが一致してはならないパターン。

パターンは、構成ファイルの読み込み時に検証される Java の正規表現です。マッチングはアンカーなし（部分文字列の一致）です。たとえば、match: "fin_" は my_fin_total と一致します。^ と $ を使用して、値全体を照合します。

select がエンティティではなくプロパティ（select: "measure.sql" や select: "dimension.label" など）をターゲットにしている場合、正規表現はエンティティ名ではなくプロパティの値に対して評価されます。組み込みの measure-sql-table-reference ルールと dimension-label-redundant-yes-no ルールは、このように動作します。

通貨の測定値が _usd または _eur で終わることを強制する例:

- name: currency-measure-suffix
  title: "Currency measures must end with a currency code like _usd or _eur"
  rule_type: pattern_match
  severity: error
  select: "view.measure"
  filters:
    value_format_name: ["usd", "usd_0", "eur", "eur_0"]
  match: "^.*_(usd|eur)$"

一時ディメンションまたは下書きディメンションを禁止する例:

- name: forbid-temporary-dimensions
  title: "Dimensions must not start with 'tmp_' or 'test_'"
  rule_type: pattern_match
  severity: error
  select: "dimension"
  should_not_match: "^(tmp|test)_.*"
property

LookML オブジェクト内の特定の子プロパティの必須の存在または禁止を適用します。requires_child または forbidden_child のいずれか 1 つのみを指定する必要があります（両方が設定されている場合は、requires_child のみが適用され、forbidden_child は無視されます）。

  • requires_child（文字列またはリスト）: 存在する必要がある子プロパティの名前。リストを指定した場合、リストに記載されている子のいずれかが存在すれば、ルールは満たされます。
  • forbidden_child（文字列またはリスト）: 存在してはならない子プロパティの名前。リストを指定すると、リストに記載されている子ノードがいずれか存在する場合に、ノードにフラグが設定されます。
  • child_filters（マップ、省略可）: 必須の子が満たす必要がある追加のプロパティ フィルタ。

表示されるすべてのディメンションの説明が必要な例:

- name: require-visible-dimension-description
  title: "Visible dimensions must specify a description"
  rule_type: property
  severity: warn
  select: "view.dimension"
  filters:
    "!hidden": true
  requires_child: "description"

派生テーブルで sql_table_name を禁止する例:

- name: forbid-sql-table-name-on-derived-views
  title: "Derived table views cannot specify sql_table_name"
  rule_type: property
  severity: error
  select: "view"
  filters:
    derived_table: ""
  forbidden_child: "sql_table_name"
order

コンテナ内の兄弟要素のアルファベット順を強制します。

  • order_by（文字列、必須）: 順序付けする兄弟子要素の LookML タイプ。通常は "dimension" または "measure" です。選択したノードの直接の子のみが比較され、dimension_group の子は "dimension" に含まれません。

名前は文字コードで大文字と小文字を区別して比較されます。大文字は小文字の前に並べ替えられ、_ はその間に並べ替えられます。

ビュー内でディメンションをアルファベット順に並べる必要がある例:

- name: custom-alphabetical-dimensions
  title: "Dimensions must be kept in alphabetical order within views"
  rule_type: order
  severity: error
  select: "view"
  order_by: "dimension"
first_child

特定のフィルタに一致する要素が、そのカテゴリの最初の子として表示されるようにします。

  • position（文字列、省略可）: 位置の制約。"first" にする必要があります（デフォルトは "first"）。

first_child ルールの場合、select は parent.child_type 形式（"view.dimension" など）を使用する必要があります。filters パラメータは、最初に表示する必要がある子を識別します。どの親ノードをチェックするかを絞り込むことはありません。parent_filters パラメータはスキーマで受け入れられますが、このルールタイプでは無視されます。

ビューで主キー ディメンションを最初に宣言する必要がある例:

- name: custom-primary-key-first-dimension
  title: "Primary key dimension must be the first dimension in the view"
  rule_type: first_child
  severity: error
  select: "view.dimension"
  filters:
    primary_key: true
  position: first
unique

CI 実行中に検証されたファイル内のすべての一致するノードで、プロパティ値の一意性を強制します。

  • unique_property（文字列、必須）: 一致するノード間で一意の値を持つ必要があるプロパティの名前（"sql_table_name" や "label" など）。

値は完全一致の文字列として比較され、最初に出現した値と重複するすべての値がレポートされます。検証実行でプロジェクトのファイルの一部のみがチェックされる場合、そのサブセット外のファイル内の重複は検出されません。

すべてのビューでテーブル名が一意になるようにする例:

- name: custom-sql-table-name-uniqueness
  title: "Each view must reference a unique sql_table_name"
  rule_type: unique
  severity: error
  select: "view"
  unique_property: "sql_table_name"

カスタムルールの制約

カスタムルールを作成する際は、次の制約に従ってください。

  1. 組み込みルール名との競合がない: カスタムルールでは、boolean-dimension-name-prefix や sql-table-name-uniqueness などの組み込みルール カタログの名前を再利用できません。
  2. 一意のカスタム名: 各カスタムルールには、custom_rules リスト内で一意の名前が必要です。
  3. ダッシュケース形式: ルール名にはダッシュケース形式（lowercase-words-with-hyphens）を使用する必要があります。

構成の評価順序

スタイル バリデータが LookML ファイルを評価する際、構成ルールは次の順序で適用されます。

  1. ファイルの除外: ファイルが ignore_files のいずれかのパターンに一致する場合、ファイルは完全にスキップされます。
  2. 有効なルール: ファイルの有効なルールは、ruleset_version（all-v1.0 または none）のルールと、rules または一致する overrides ブロックで warn または error の重大度が割り当てられた組み込みルールと、custom_rules で定義されたすべてのルールで構成されます。
  3. 重大度の解決: 各アクティブ ルールについて、重大度を指定する次の設定のうち、最初に一致したものが優先されます。最後に一致した overrides ブロック、グローバル rules ブロック、カスタムルールの severity、デフォルトの重大度（error）。
  4. 無効なルール: 解決済みの重大度が disabled のルールは、そのファイルに対してスキップされます。

構成ファイルの例

次の例は、ベースライン ルールセットの選択、ファイルの除外、グローバル ルールのカスタマイズ、スコープ設定されたオーバーライド、カスタムルールを示す完全な lkmlstyle.yaml ファイルを示しています。

# Schema version
schema_version: 1

# Baseline ruleset edition (all-v1.0 or none)
ruleset_version: "all-v1.0"

# Files completely ignored by the style validator
ignore_files:
  - "vendor/**"
  - "*.ignore.lkml"
  - "legacy_dashboards/*.dashboard.lookml"

# Built-in rule customizations
rules:
  view-dimension-order:
    severity: warn
  numeric-measure-value-format-presence:
    severity: warn
  sql-table-name-uniqueness:
    severity: error
  # Replaced by the custom first_child rule below
  primary-key-first-dimension:
    severity: disabled

# Directory/file scoped overrides
overrides:
  - files:
      - "views/staging/**"
    rules:
      visible-dimension-description-presence:
        severity: disabled
      primary-key-visibility:
        severity: warn

# Custom rules catalog
custom_rules:
  # 1. Pattern Match: Finance dimensions must start with fin_
  - name: finance-dimension-prefix
    title: "Finance dimensions must be prefixed with fin_"
    rule_type: pattern_match
    severity: error
    rationale: "Ensures clarity in the field picker for finance metrics."
    select: "view.dimension"
    filters:
      view_label: "Finance"
    match: "^fin_[a-z0-9_]+$"

  # 2. Pattern Match: Forbid draft or test views
  - name: forbid-draft-views
    title: "Views cannot be named with draft_ or test_ prefixes"
    rule_type: pattern_match
    severity: error
    select: "view"
    should_not_match: "^(draft|test)_.*"

  # 3. Property: Require explicit relationship on joins
  - name: require-join-relationship
    title: "All joins must declare an explicit relationship"
    rule_type: property
    severity: error
    select: "explore.join"
    requires_child: "relationship"

  # 4. Property: Explores must not use sql_always_where
  - name: forbid-sql-always-where
    title: "Explores should use always_filter instead of sql_always_where"
    rule_type: property
    severity: warn
    select: "explore"
    forbidden_child: "sql_always_where"

  # 5. Order: Dimension groups inside views must be alphabetical
  - name: view-dimension-groups-alphabetical
    title: "Dimension groups must appear in alphabetical order within views"
    rule_type: order
    severity: warn
    select: "view"
    order_by: "dimension_group"

  # 6. First Child: Primary key must be the first dimension
  - name: custom-primary-key-first-dimension
    title: "The primary key must be defined as the first dimension in the view"
    rule_type: first_child
    severity: error
    select: "view.dimension"
    filters:
      primary_key: true
    position: first

  # 7. Unique: Views must not share the same label
  - name: unique-view-labels
    title: "Views must have unique labels"
    rule_type: unique
    severity: warn
    select: "view"
    unique_property: "label"

検証の範囲と結果

以降のセクションでは、スタイル バリデータがチェックするファイルと、検証結果のレポート方法について説明します。

検証済みのファイル

  • ルート プロジェクトの .lkml ファイルと .lookml ファイルのみが検証されます。インポートされた（ローカルまたはリモート）依存関係プロジェクトは検証されません。
  • 各ファイルは、そのコンテンツに基づいて検証されます。include: ステートメントは追跡されず、include: ステートメントで取り込まれたオブジェクトは、インクルード ファイルの一部として検証されません。
  • dbt Cloud CI ジョブによってトリガーされる CI 実行では、開発ブランチではなく本番環境の LookML ブランチが検証されます。

合格または不合格の動作と出力

  • スタイル バリデータは、1 つ以上の診断で重大度が error の場合にのみ失敗します。警告だけでは実行は失敗しません。
  • CI 実行結果ページでは、各診断結果にルール名、パス、行番号、コンテキスト スニペット、ルール ドキュメントへのリンクが含まれます。スイートの実行と結果の表示について詳しくは、継続的インテグレーション スイートの実行と CI 実行の結果を表示するをご覧ください。
  • 無効な構成ファイルでは、構成ファイルの 1 行目に 1 つの invalid-config エラーが生成され、検証実行が失敗します。

増分検証

スタイル バリデータで増分検証を有効にするには、継続的インテグレーション スイートを作成または編集するときに、[スタイル バリデータ] セクションで [増分エラーのみ] チェックボックス（デフォルトで有効）をオンにします。

増分検証が有効になっている場合、スタイル バリデータは開発ブランチの新しい違反のみをレポートします。

  1. 開発ブランチを検証します。
  2. ターゲット ブランチは、開発ブランチの構成ファイルを使用して検証されます。
  3. ターゲット ブランチにまだ存在しない違反のみが報告されます。

増分検証が有効になっている場合、次の動作に注意してください。

  • ターゲット ブランチに既存の違反があっても、実行は失敗しません。
  • 開発ブランチの構成ファイルは両方のブランチの検証に使用されるため、開発ブランチの構成を変更しても、既存の違反を隠したり、既存の LookML を新しい違反として表示したりすることはできません。
  • 開発ブランチには lkmlstyle.yaml（または lkmlstyle.yml）構成ファイルが含まれている必要があります。含まれていない場合、実行は失敗し、構成が見つからないというエラーが発生します。

[増分エラーのみ] が無効になっている場合、検証済みのブランチで見つかったすべての違反が報告されます。

組み込みルールのカタログ

次の表に、all-v1.0 ルールセットで使用可能な 25 個の標準組み込みルールを示します。

ルール名 ターゲット エンティティ ルールの概要
average-measure-name-prefix 測定 type: average または average_distinct を含むメジャーは、avg_ または average_ で始まる必要があります。
boolean-dimension-name-prefix ディメンション Yesno ディメンションは is_、has_、does_ で始まる必要があります。
count-measure-name-prefix 測定 type: count または count_distinct を含むメジャーは count_ で始まる必要があります。
dimension-group-name-suffix ディメンション グループ ディメンション グループは _at、_date、_time で終わってはなりません。
dimension-label-redundant-yes-no ディメンション 「はい / いいえ」ディメンションのラベルには、(Yes / No) や (yes/no) などの「はい / いいえ」マーカーを含めないでください（大文字と小文字、スペースは任意）。
dimension-name-snake-case ディメンション ディメンションとディメンショングループの名前は、小文字の snake_case にする必要があります。
explore-fields-presence 探索 探索では fields: プロパティを定義する必要があります。
explore-label-presence 探索 探索では、明示的な label: プロパティを定義する必要があります。
includes-wildcard-usage 含める include: ステートメントでは、ビューファイル（*.view.lkml や /views/*.view など）にワイルドカードを使用しないでください。他のワイルドカードはフラグ設定されません。
join-relationship-presence 参加 Explore join: 宣言では relationship: を指定する必要があります。
measure-name-snake-case 測定 指標名は小文字の snake_case にする必要があります。
measure-sql-table-reference 測定 メジャーは ${TABLE}.column ではなく ${dimension_name} を使用してディメンションを参照する必要があります。
numeric-measure-value-format-presence 測定 type: count、sum、average、または number を含む指標では、value_format: または value_format_name: を指定する必要があります。
pdt-view-name-prefix 表示 永続的な派生テーブル（PDT）は pdt_ で始める必要があります。ビューの derived_table で datagroup_trigger、sql_trigger_value、interval_trigger、persist_for のいずれかが設定されているか、materialized_view: yes が設定されている場合、そのビューは PDT と見なされます。
primary-key-first-dimension ディメンション 主キー ディメンションは、ビューで定義される最初のディメンションでなければなりません。
primary-key-visibility ディメンション 主キーのディメンションは非表示（hidden: yes）にする必要があります。
sql-table-name-uniqueness 表示 複数のビューでまったく同じ sql_table_name を参照することはできません。
sum-measure-name-prefix 測定 type: sum または sum_distinct を含むメジャーは、sum_ または total_ で始まる必要があります。
view-dimension-order 表示 ビュー内のディメンションはアルファベット順に整理する必要があります。
view-label-presence 表示 ビューでは、明示的な label: を定義する必要があります。
view-measure-order 表示 ビュー内の指標はアルファベット順に並べる必要があります。
view-name-snake-case 表示 ビュー名は小文字の snake_case にする必要があります（絞り込みの先頭の + は許可されます）。
view-primary-key-presence 表示 sql_table_name または derived_table（extends なし）を含むビューでは、主キーを定義する必要があります。
visible-dimension-description-presence ディメンション 表示されるディメンションには description: が必要です。
visible-measure-description-presence 測定 表示される測定値には description: が必要です。

トラブルシューティング

以降のセクションでは、スタイル バリデータでトラブルシューティングを行う際に発生する一般的な構成の問題と、サポートされている構文のバリエーションについて説明します。

構成エラー

構成ファイルの読み込み時に次の問題が拒否され、invalid-config エラーとして報告されます。

  • 不明なトップレベル キー、またはルール構成内の不明なキー。
  • schema_version または ruleset_version が欠落しているか、いずれかのパラメータの値がサポートされていません。
  • rule-name: warn などのスカラー重大度の短縮形。
  • files または rules が欠落しているか空のオーバーライド ブロック、または severity のないオーバーライド ブロック内のルール構成。
  • オーバーライド ブロック内の不明なルール名。
  • 名前が別のカスタムルールまたは組み込みルールと重複しているカスタムルール。
  • 間違った rule_type で使用された型固有のキー（たとえば、pattern_match ルールでの order_by）。
  • 無効な正規表現。
  • order_by パラメータ（order ルールの場合）または unique_property パラメータ（unique ルールの場合）がありません。
  • first 以外の position 値（first_child ルールの場合）。
  • フィルタキーの先頭に引用符で囲まれていない !（!hidden: true など）。これは無効な YAML タグ構文であり、構成ファイルの解析が失敗します。

サイレント構成に関する問題

  • グローバル rules ブロック内のルール名が誤って入力されている場合は、通知なく無視されます。
  • select、filters、parent_filters、requires_child、forbidden_child、order_by で LookML 型名が誤って入力されていても、エラーは発生しません。代わりに、ルールは一致しません（または、requires_child の場合は常に失敗します）。
  • match と should_not_match の両方、または requires_child と forbidden_child の両方を指定した場合: 各ペアの最初のパラメータのみが適用され、2 番目のパラメータは無視されます。
  • first_child ルールで parent_filters を指定しても効果はなく、無視されます。
  • フィルタは、LookML ファイルで明示的に宣言されたプロパティのみに一致し、LookML のデフォルト値には一致しません（フィルタリング構文を参照）。
  • pattern_match ルールの正規表現パターンは、^ と $ でアンカーしない限り、アンカーなしの部分文字列一致になります（pattern_match を参照）。

使用できる構文のバリエーション

  • severity と rule_type の値では大文字と小文字が区別されません。
  • rule_type: pattern は pattern_match のエイリアスとして使用できます。
  • ruleset_version の先頭と末尾の空白は無視されます。