Continuous Integration Style Validator

Der CI-Stilvalidator (Continuous Integration) erzwingt LookML-Codierungsstandards, Namenskonventionen und strukturelle Best Practices in Ihrem LookML-Projekt mithilfe des LookML-Stil-Linters. Durch die Überprüfung Ihrer LookML-Dateien anhand einer konfigurierbaren Reihe von Stilregeln trägt der Style Validator dazu bei, dass Ihr Team eine saubere, einheitliche und lesbare Codebasis beibehält.

Wenn Sie den Stilvalidator ausführen möchten, müssen Sie dem Stammverzeichnis Ihres LookML-Projekt-Repositorys eine Konfigurationsdatei mit dem Namen lkmlstyle.yaml (oder lkmlstyle.yml) hinzufügen. Weitere Informationen zum Konfigurieren des Style-Linters finden Sie im Abschnitt Konfigurationsdatei auf dieser Seite.

Informationen zum Konfigurieren und Ausführen des Style Validator in einer CI-Suite und zum Ansehen der Validierungsausgabe finden Sie auf den Dokumentationsseiten Continuous Integration-Suite erstellen, Continuous Integration-Suites ausführen und Ergebnisse eines CI-Laufs ansehen.

Hinweis

Um den Style-Validator in der CI zu verwenden, benötigen Sie Folgendes:

Konfigurationsdatei

Eine Konfigurationsdatei ist erforderlich, um den Stilvalidator in Looker CI auszuführen. Wenn der Stilvalidator ausgeführt wird, sucht er automatisch im Stammverzeichnis Ihres LookML-Projekt-Repositorys nach einer Konfigurationsdatei in der folgenden Prioritätsreihenfolge:

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

Wenn beide Dateien im Stammverzeichnis vorhanden sind, hat lkmlstyle.yaml Vorrang und lkmlstyle.yml wird ignoriert.

Wenn weder lkmlstyle.yaml noch lkmlstyle.yml im Projektstammverzeichnis gefunden werden (und keine benutzerdefinierte Konfiguration über die API übergeben wird), schlägt die Stilvalidierung mit dem Fehler "No style validator configuration provided" fehl.

Wenn Sie alle 25 integrierten Standardregeln mit ihren Standardeinstellungen ausführen möchten, können Sie die folgenden minimalen Konfigurationsinformationen in Ihrer lkmlstyle.yaml-Datei verwenden:

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

Andernfalls können Sie die Konfigurationsdatei anpassen. Die Konfigurationsdatei kann die folgenden Parameter auf oberster Ebene enthalten:

Parameter Typ Erforderlich/Optional? Standard Beschreibung
schema_version Ganzzahl Ja Keine Version des Konfigurationsschemas. Version 1 ist die einzige unterstützte Version und muss explizit angegeben werden.
ruleset_version String Ja Keine Die zu übernehmende Version des Referenzregelsatzes. Unterstützte Werte: "all-v1.0" und "none".
ignore_files Liste mit Zeichenfolgen Nein [] Glob-Muster von Dateien, die vollständig von der Stilvalidierung ausgeschlossen werden sollen.
rules Karte Nein {} Globale Anpassungen (severity und version) für einzelne Regeln. Sie können auch integrierte Regeln aktivieren, die nicht im Baseline-Regelsatz enthalten sind, und den Schweregrad benutzerdefinierter Regeln ändern. Beispiele finden Sie im Abschnitt Regelanpassungen.
overrides Kartenliste Nein [] Überschreibungen von Regeln mit eingeschränktem Gültigkeitsbereich, mit denen Schweregrade für bestimmte übereinstimmende Dateipfade angepasst oder aktiviert werden.
custom_rules Kartenliste Nein [] Deklarative, benutzerdefinierte Regeln.

ruleset_version

Der Parameter ruleset_version bildet die Grundlage Ihrer Strategie zur Stilvalidierung:

  • "all-v1.0" (Empfohlen): Aktiviert alle 25 integrierten LookML-Standardstilregeln auf der Schweregradstufe error. Diese Option ist ideal für Teams, die eine umfassende Qualitätssicherung ohne zusätzlichen Aufwand wünschen.
  • "none": Es sind zu Beginn keine integrierten Regeln aktiviert. Diese Option ist ideal für Teams, die die Stilvalidierung schrittweise einführen, einzelne Regeln nacheinander aktivieren oder nur benutzerdefinierte Organisationsregeln ausführen möchten. Wenn Sie eine integrierte Regel aktivieren möchten, wenn ruleset_version gleich "none" ist, weisen Sie der Regel im Block rules oder in einem Block overrides den Schweregrad warn oder error zu.

ignore_files

Für den Parameter ignore_files kann eine Liste von Glob-Mustern für Dateien angegeben werden, die bei der Stilvalidierung vollständig ignoriert werden sollen. Dateien, die diesen Mustern entsprechen, werden nicht auf integrierte oder benutzerdefinierte Regeln geprüft.

Die unterstützte Platzhaltersyntax umfasst Folgendes:

  • *: Entspricht einer beliebigen Folge von Zeichen, die keine Trennzeichen sind, innerhalb einer einzelnen Verzeichnisebene.
  • **: Entspricht einer beliebigen Zeichenfolge über mehrere verschachtelte Verzeichnisebenen hinweg.
  • ?: Stimmt mit jedem einzelnen Zeichen überein.
  • {a,b} und [abc]: Entspricht Alternativen und Zeichenklassen (Java-Glob-Syntax).

Die folgenden Regeln für den Pfadabgleich gelten für jedes Glob-Muster in der Konfigurationsdatei, einschließlich ignore_files auf oberster Ebene sowie files und ignore_files in overrides:

  • Pfade sind relativ zum Projektstammverzeichnis. Ein führendes ./ oder / wird ignoriert.
  • Ein Muster ohne Schrägstrich (/) stimmt mit jeder Verzeichnistiefe überein. Beispielsweise führt *.ignore.lkml zu Übereinstimmungen mit x.ignore.lkml und views/x.ignore.lkml.
  • Ein Muster, das mit / endet, stimmt mit allen Elementen in diesem Verzeichnis überein.
  • Ein Muster, das mit .lkml oder .lookml endet, entspricht auch zusammengesetzten Erweiterungen. Beispielsweise führt *.ignore.lkml zu Übereinstimmungen mit x.ignore.view.lkml.

Im folgenden Beispiel werden Anbieterdateien, Legacy-LookML-Dateien und LookML-Dashboards ausgeschlossen:

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

rules

Mit dem rules-Block können Sie den Schweregrad von Diagnosen für einzelne Regeln in Ihrem gesamten Projekt anpassen:

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

Jede integrierte Regel, die in rules (oder in einem overrides-Block) mit dem Schweregrad warn oder error aufgeführt ist, ist aktiv, auch wenn ruleset_version auf "none" festgelegt ist. Die folgende Startkonfiguration beginnt beispielsweise mit ruleset_version: "none" und aktiviert nur zwei integrierte Regeln:

schema_version: 1
ruleset_version: "none"

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

Sie können auch den rules-Block verwenden, um den Schweregrad einer benutzerdefinierten Regel zu ändern, indem Sie auf ihren Namen verweisen.

severity

Für jede Regel kann einer der folgenden Schweregrade ohne Berücksichtigung der Groß-/Kleinschreibung konfiguriert werden:

  • error: Wird als schwerwiegender Verstoß behandelt. Fehler führen dazu, dass der CI-Lauf fehlschlägt.
  • warn: Wird als nicht blockierende Warnung ausgegeben. Warnungen werden in Berichten zu CI-Läufen angezeigt, führen aber nicht dazu, dass der CI-Lauf fehlschlägt.
  • disabled: Deaktiviert die Regel vollständig und überspringt sie bei der Validierung.

overrides

Mit dem Parameter overrides können Sie die Schweregrade von Regeln für bestimmte Dateien oder Verzeichnisse ändern, ohne die Schweregrade für den Rest Ihres LookML-Projekts zu ändern. Sie können beispielsweise overrides verwenden, um Regeln für Staging-Ansichten oder Legacy-Modelle zu lockern, Regeln für kritische Pfade zu verschärfen oder bestimmte Regeln nur für bestimmte Verzeichnisse zu aktivieren, wenn ruleset_version "none" ist.

Jeder Eintrag in der Liste overrides unterstützt die folgenden Felder:

Feld Typ Erforderlich/Optional? Beschreibung
files Liste mit Zeichenfolgen Ja Glob-Muster, die den Dateien entsprechen, für die dieser Überschreibungsblock gilt. Das Feld darf nicht leer sein.
ignore_files Liste mit Zeichenfolgen Nein Glob-Muster, die aus diesem bestimmten Überschreibungsblock ausgeschlossen werden sollen.
rules Karte Ja Zuordnung von Regelnamen zu Konfigurationen für den Schweregrad. Das Feld darf nicht leer sein. In Überschreibungsblöcken ist nur severity zulässig (und erforderlich). Regelnamen müssen gültige integrierte oder benutzerdefinierte Regelnamen sein.

Im folgenden Beispiel werden die Prüfungen der Dimensionsreihenfolge deaktiviert und Fehler bei fehlenden Beschreibungen für Legacy-Ansichten und ‑Dashboards zu Warnungen herabgestuft:

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

Sie können deklarative benutzerdefinierte Regeln im Abschnitt custom_rules Ihrer Konfigurationsdatei definieren, um organisationsspezifische Namenskonventionen, erforderliche Architekturmuster und strukturelle Governance zu erzwingen.

Jede benutzerdefinierte Regeldefinition unterstützt die folgenden allgemeinen Parameter:

Feld Typ Erforderlich/Optional? Beschreibung
name String Ja Eindeutige Kennung im Dash-Case-Format, z. B. finance-measure-prefix. Darf nicht mit integrierten Regelnamen oder anderen benutzerdefinierten Regeln kollidieren.
title String Ja Für Menschen lesbare Meldung, die bei einem Verstoß gemeldet wird, formatiert als (<rule-name>) <title>.
rule_type String Ja Der Archetyp der Regel: pattern_match, property, order, first_child oder unique. Die Groß- und Kleinschreibung wird nicht berücksichtigt. pattern wird als Alias für pattern_match akzeptiert.
severity String Nein Diagnoseebene: error (Standard), warn oder disabled. Kann durch rules und overrides überschrieben werden.
rationale String Nein Dokumentiert, warum die Regel existiert.
select String oder Liste Nein AST-Knotenpfad zum Ziel, z. B. "view.dimension", "explore" oder ["dimension", "dimension_group"]. Wird sie weggelassen, gilt die Regel für jeden Knoten, der mit filters übereinstimmt.
filters Karte Nein Eigenschaftsfilter, die für den Zielknoten übereinstimmen müssen, z. B. primary_key: true.
parent_filters Karte Nein Attributfilter, die mit dem direkten übergeordneten Element des Zielknotens übereinstimmen müssen.

Für jeden Regeltyp sind nur die entsprechenden typspezifischen Schlüssel zulässig. Unbekannte Schlüssel oder Schlüssel, die zu einem anderen Regeltyp gehören (z. B. order_by in einer pattern_match-Regel), führen zu einem Konfigurationsfehler.

select

Mit dem Parameter select wird festgelegt, welche LookML-Elemente von der benutzerdefinierten Regel ausgewertet werden:

  • Direktes Element: Richten Sie die Suche auf einen bestimmten LookML-Elementtyp aus, z. B. select: "dimension", select: "measure", select: "view", select: "explore", select: "join", select: "model" oder select: "include".
  • Verschachtelter Pfad für über- und untergeordnete Elemente: Richten Sie die Ausrichtung auf Elemente aus, die in einem bestimmten unmittelbaren übergeordneten Element definiert sind, z. B. select: "view.dimension" (Dimensionen, die in Ansichten definiert sind) oder select: "explore.join" (Joins, die in Explores definiert sind). Der Elternknoten muss der unmittelbare Elternknoten sein und es werden nur die letzten beiden Segmente eines Pfads verwendet (a.b.c verhält sich also wie b.c).
  • Mehrere Ziele: Geben Sie mehrere Elementtypen mit einem kommagetrennten String oder einer Liste wie select: "dimension, dimension_group" oder select: ["dimension", "dimension_group"] an.

Selektor-, Filter- und untergeordnete Namen sind exakte, LookML-Schlüsselwörter, bei denen die Groß-/Kleinschreibung beachtet wird. Ein falsch geschriebener Name wird nicht als Konfigurationsfehler gemeldet. Stattdessen wird die Regel nie abgeglichen.

filters und parent_filters

Mit filters und parent_filters können Sie Zielknoten basierend auf den LookML-Attributen verfeinern, die in der LookML-Datei explizit deklariert sind.

  • Boolesche Gleichheit: Abgleich explizit deklarierter boolescher Attribute wie primary_key: true oder hidden: true.
  • String-Gleichheit: Es wird nach exakten String-Werten gesucht, z. B. type: "yesno" oder type: "count".
  • One-of-Liste: Stimmt mit einem beliebigen Wert in einer Liste überein, z. B. type: ["string", "number", "date"].
  • Anwesenheitsprüfung: Prüfen Sie, ob ein Block oder eine Property vorhanden ist, indem Sie einen leeren String übergeben, z. B. derived_table: "".
  • Negation: Stellen Sie dem Schlüssel oder Wert ! voran, um den Filter zu negieren. Ein negierter Schlüssel muss in Anführungszeichen eingeschlossen werden, da ein führendes ! ohne Anführungszeichen YAML-Tag-Syntax ist und dazu führt, dass die Konfigurationsdatei nicht geparst werden kann:
    • "!hidden": true oder hidden: "!true" stimmt mit sichtbaren (nicht ausgeblendeten) Elementen überein, einschließlich Feldern, in denen hidden nicht deklariert ist.
    • type: ["!yesno", "!date"] entspricht Typen, die weder yesno noch date sind.

rule_type

Für jede benutzerdefinierte Regel muss einer der folgenden fünf Regelarchetypen für den Parameter rule_type angegeben werden:

pattern_match

Erzwingt reguläre Ausdrucksmuster für LookML-Entitätsnamen oder ‑Eigenschaftswerte. Sie müssen genau eines der Attribute match oder should_not_match angeben. Wenn beide festgelegt sind, wird nur match angewendet und should_not_match wird ignoriert:

  • match (String, regulärer Ausdruck): Muster, das mit dem Ziel übereinstimmen muss.
  • should_not_match (String, regulärer Ausdruck): Muster, das nicht mit dem Ziel übereinstimmen darf.

Muster sind reguläre Java-Ausdrücke, die beim Laden der Konfigurationsdatei validiert werden. Der Abgleich ist nicht verankert (Teilstring-Abgleich). match: "fin_" wird beispielsweise für my_fin_total akzeptiert. Verwenden Sie ^ und $, um den gesamten Wert abzugleichen.

Wenn select auf ein Attribut anstelle einer Entität ausgerichtet ist (z. B. select: "measure.sql" oder select: "dimension.label"), wird der reguläre Ausdruck für den Wert des Attributs und nicht für einen Entitätsnamen ausgewertet. Die integrierten Regeln measure-sql-table-reference und dimension-label-redundant-yes-no funktionieren so.

Beispiel, in dem erzwungen wird, dass Währungs-Messwerte mit _usd oder _eur enden:

- 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)$"

Beispiel, das temporäre oder Entwurfsdimensionen verbietet:

- 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

Erzwingt das obligatorische Vorhandensein oder Verbot bestimmter untergeordneter Eigenschaften in LookML-Objekten. Sie müssen genau eines der Attribute requires_child oder forbidden_child angeben. Wenn beide festgelegt sind, wird nur requires_child angewendet und forbidden_child wird ignoriert:

  • requires_child (String oder Liste): Name oder Namen der untergeordneten Attribute, die vorhanden sein müssen. Wenn Sie eine Liste angeben, ist die Regel erfüllt, wenn eines der aufgeführten untergeordneten Elemente vorhanden ist.
  • forbidden_child (String oder Liste): Name oder Namen der untergeordneten Property, die nicht vorhanden sein dürfen. Wenn Sie eine Liste angeben, wird der Knoten gekennzeichnet, wenn eines der aufgeführten untergeordneten Elemente vorhanden ist.
  • child_filters (Karte, optional): Zusätzliche Property-Filter, die die erforderliche untergeordnete Property erfüllen muss.

Beispiel, für das Beschreibungen für alle sichtbaren Dimensionen erforderlich sind:

- 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"

Beispiel, in dem sql_table_name für abgeleitete Tabellen verboten ist:

- 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

Erzwingt die alphabetische Reihenfolge von gleichgeordneten Elementen in einem Container.

  • order_by (String, erforderlich): LookML-Typ der untergeordneten Elemente, die sortiert werden sollen, in der Regel "dimension" oder "measure". Es werden nur die direkten untergeordneten Elemente des ausgewählten Knotens verglichen und dimension_group-untergeordnete Elemente sind nicht in "dimension" enthalten.

Namen werden anhand des Zeichencodes verglichen, wobei Groß- und Kleinschreibung beachtet wird: Großbuchstaben werden vor Kleinbuchstaben sortiert und _ wird dazwischen sortiert.

Beispiel, bei dem Dimensionen in Ansichten in alphabetischer Reihenfolge aufgeführt werden müssen:

- 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

Erzwingt, dass ein Element, das einem bestimmten Filter entspricht, als erstes untergeordnetes Element seiner Kategorie angezeigt wird.

  • position (String, optional): Positionsbeschränkung. Muss "first" sein (Standardwert: "first").

Für first_child-Regeln muss select das parent.child_type-Format verwenden, z. B. "view.dimension". Der Parameter filters gibt das untergeordnete Element an, das zuerst angezeigt werden muss. Er schränkt nicht ein, welche übergeordneten Knoten geprüft werden. Der Parameter parent_filters wird vom Schema akzeptiert, aber für diesen Regeltyp ignoriert.

Beispiel, bei dem die Primärschlüsseldimension zuerst in einer Ansicht deklariert werden muss:

- 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

Erzwingt die Eindeutigkeit eines Attributwerts für alle übereinstimmenden Knoten in den Dateien, die während eines CI-Laufs validiert werden.

  • unique_property (String, erforderlich): Name des Attributs, das für übereinstimmende Knoten eindeutige Werte haben muss, z. B. "sql_table_name" oder "label".

Werte werden als exakte Strings verglichen und sowohl das erste Vorkommen als auch jedes Duplikat werden gemeldet. Wenn bei einem Validierungslauf nur eine Teilmenge der Projektdateien geprüft wird, werden Duplikate in Dateien außerhalb dieser Teilmenge nicht erkannt.

Beispiel, das für eindeutige Tabellennamen in allen Ansichten sorgt:

- 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"

Einschränkungen für benutzerdefinierte Regeln

Beachten Sie beim Erstellen benutzerdefinierter Regeln die folgenden Einschränkungen:

  1. Keine Konflikte mit integrierten Regelnamen: Für benutzerdefinierte Regeln darf kein Name aus dem integrierten Regelkatalog wiederverwendet werden, z. B. boolean-dimension-name-prefix oder sql-table-name-uniqueness.
  2. Eindeutige benutzerdefinierte Namen: Jede benutzerdefinierte Regel muss in der custom_rules-Liste einen eindeutigen Namen haben.
  3. Bindestrichformat: Für Regelnamen sollte das Bindestrichformat (lowercase-words-with-hyphens) verwendet werden.

Reihenfolge der Konfigurationsauswertung

Wenn der Stilvalidator eine LookML-Datei auswertet, werden die Konfigurationsregeln in der folgenden Reihenfolge angewendet:

  1. Dateiausschluss: Wenn die Datei mit einem Muster in ignore_files übereinstimmt, wird sie vollständig übersprungen.
  2. Aktive Regeln: Die aktiven Regeln für die Datei bestehen aus den Regeln aus ruleset_version (all-v1.0 oder none) sowie allen integrierten Regeln, denen in rules oder in einem übereinstimmenden overrides-Block der Schweregrad warn oder error zugewiesen ist, sowie allen in custom_rules definierten Regeln.
  3. Schweregradauflösung: Für jede aktive Regel hat die erste der folgenden Einstellungen, die einen Schweregrad angibt, Vorrang: der letzte übereinstimmende overrides-Block, dann der globale rules-Block, dann der eigene severity-Block der benutzerdefinierten Regel und schließlich der Standardschweregrad (error).
  4. Deaktivierte Regeln: Regeln, deren behobener Schweregrad disabled ist, werden für diese Datei übersprungen.

Beispiel: Konfigurationsdatei

Das folgende Beispiel zeigt eine vollständige lkmlstyle.yaml-Datei, in der die Auswahl von Baseline-Regelsätzen, Dateiausschlüsse, globale Regelanpassungen, bereichsbezogene Überschreibungen und benutzerdefinierte Regeln veranschaulicht werden:

# 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"

Validierungsumfang und ‑ergebnisse

In den folgenden Abschnitten wird beschrieben, welche Dateien vom Style-Validator geprüft werden und wie die Validierungsergebnisse gemeldet werden:

Validierte Dateien

  • Es werden nur .lkml- und .lookml-Dateien im Stammprojekt validiert. Importierte (lokale oder Remote-)Abhängigkeitsprojekte werden nicht validiert.
  • Jede Datei wird anhand ihres eigenen Inhalts validiert. include:-Anweisungen werden nicht befolgt und Objekte, die über eine include:-Anweisung abgerufen werden, werden nicht als Teil der einschließenden Datei validiert.
  • CI-Ausführungen, die durch dbt Cloud-CI-Jobs ausgelöst werden, validieren den LookML-Produktionszweig und nicht einen Entwicklungszweig.

Verhalten und Ausgabe bei Erfolg oder Fehler

  • Ein Style Validator-Lauf schlägt nur fehl, wenn mindestens eine Diagnose den Schweregrad error hat. Warnungen allein führen nicht dazu, dass der Lauf fehlschlägt.
  • Auf der Seite CI-Lauf-Ergebnisse enthält jedes Diagnoseergebnis den Namen der Regel, den Pfad, die Zeilennummer, einen Kontext-Snippet und einen Link zur Regeldokumentation. Weitere Informationen zum Ausführen von Test-Suites und zum Ansehen von Ergebnissen finden Sie unter Continuous Integration-Suites ausführen und Ergebnisse eines CI-Laufs ansehen.
  • Eine ungültige Konfigurationsdatei führt zu einem einzelnen invalid-config-Fehler in der Konfigurationsdatei in Zeile 1 und die Validierung schlägt fehl.

Inkrementelle Validierung

Sie können die inkrementelle Validierung für den Style Validator aktivieren, indem Sie beim Erstellen oder Bearbeiten einer Continuous Integration-Suite im Bereich Style Validator das Kästchen Nur inkrementelle Fehler (standardmäßig aktiviert) anklicken.

Wenn die inkrementelle Validierung aktiviert ist, werden im Style Validator nur Verstöße gemeldet, die neu in Ihrem Entwicklungszweig sind:

  1. Sie validiert den Entwicklungszweig.
  2. Dabei wird der Ziel-Branch mit der Konfigurationsdatei des Entwicklungs-Branch validiert.
  3. Es werden nur die Verstöße gemeldet, die noch nicht im Ziel-Branch vorhanden sind.

Wenn die inkrementelle Validierung aktiviert ist, gilt Folgendes:

  • Bereits vorhandene Verstöße im Ziel-Branch führen nicht dazu, dass der Lauf fehlschlägt.
  • Da die Konfigurationsdatei des Entwicklungszweigs verwendet wird, um beide Zweige zu validieren, können durch eine Konfigurationsänderung im Entwicklungszweig keine bereits vorhandenen Verstöße verborgen werden und bereits vorhandenes LookML kann nicht von selbst als neuer Verstoß angezeigt werden.
  • Der Entwicklungszweig muss eine Konfigurationsdatei lkmlstyle.yaml (oder lkmlstyle.yml) enthalten. Andernfalls schlägt der Lauf mit einem Fehler wegen fehlender Konfiguration fehl.

Wenn Nur inkrementelle Fehler deaktiviert ist, wird jeder Verstoß gemeldet, der im validierten Branch gefunden wird.

Integrierter Regelkatalog

In der folgenden Tabelle sind alle 25 Standardregeln aufgeführt, die im Regelsatz all-v1.0 verfügbar sind:

Regelname Zielentität Regelzusammenfassung
average-measure-name-prefix Messen Messwerte mit type: average oder average_distinct müssen mit avg_ oder average_ beginnen.
boolean-dimension-name-prefix Dimension Ja/Nein-Dimensionen müssen mit is_, has_ oder does_ beginnen.
count-measure-name-prefix Messen Messwerte mit type: count oder count_distinct müssen mit count_ beginnen.
dimension-group-name-suffix Dimensionsgruppe Dimensionsgruppen dürfen nicht mit _at, _date oder _time enden.
dimension-label-redundant-yes-no Dimension „Ja/Nein“-Dimensionslabels dürfen keine „Ja/Nein“-Markierung wie (Yes / No) oder (yes/no) enthalten (unabhängig von Groß-/Kleinschreibung oder Leerzeichen).
dimension-name-snake-case Dimension Namen von Dimensionen und Dimensionsgruppen müssen in Kleinbuchstaben snake_case angegeben werden.
explore-fields-presence Erkunden In Explores sollte das Attribut fields: definiert sein.
explore-label-presence Erkunden In Explores muss eine explizite label:-Property definiert sein.
includes-wildcard-usage Einschließen In include:-Anweisungen sollten keine Platzhalter für Ansichtsdateien wie *.view.lkml oder /views/*.view verwendet werden. Andere Platzhalter werden nicht gekennzeichnet.
join-relationship-presence Beitreten Für Explorejoin:-Deklarationen muss ein relationship: angegeben werden.
measure-name-snake-case Messen Messwertnamen müssen in Kleinbuchstaben snake_case angegeben werden.
measure-sql-table-reference Messen Messwerte müssen mit ${dimension_name} auf Dimensionen verweisen, nicht mit ${TABLE}.column.
numeric-measure-value-format-presence Messen Für Messungen mit type: count, sum, average oder number muss value_format: oder value_format_name: angegeben werden.
pdt-view-name-prefix Ansehen Persistente abgeleitete Tabellen (PDTs) sollten mit pdt_ beginnen. Eine Ansicht gilt als PDT, wenn für ihr derived_table datagroup_trigger, sql_trigger_value, interval_trigger oder persist_for festgelegt ist oder wenn materialized_view: yes festgelegt ist.
primary-key-first-dimension Dimension Die Primärschlüsseldimension muss die erste Dimension sein, die in der Ansicht definiert ist.
primary-key-visibility Dimension Primärschlüsseldimensionen sollten ausgeblendet (hidden: yes) sein.
sql-table-name-uniqueness Ansehen Mehrere Ansichten sollten nicht auf genau dieselbe sql_table_name verweisen.
sum-measure-name-prefix Messen Messwerte mit type: sum oder sum_distinct müssen mit sum_ oder total_ beginnen.
view-dimension-order Ansehen Dimensionen in einer Ansicht müssen in alphabetischer Reihenfolge organisiert sein.
view-label-presence Ansehen Für Ansichten muss ein explizites label: definiert werden.
view-measure-order Ansehen Die Messwerte in einer Ansicht müssen in alphabetischer Reihenfolge organisiert sein.
view-name-snake-case Ansehen Ansichtsnamen müssen in Kleinbuchstaben angegeben werden snake_case (ein führendes + für Verfeinerungen ist zulässig).
view-primary-key-presence Ansehen Für Ansichten mit sql_table_name oder derived_table (und ohne extends) muss ein Primärschlüssel definiert werden.
visible-dimension-description-presence Dimension Sichtbare Dimensionen müssen einen description: haben.
visible-measure-description-presence Messen Sichtbare Messwerte müssen einen description: haben.

Fehlerbehebung

In den folgenden Abschnitten werden häufige Konfigurationsprobleme und unterstützte Syntaxvarianten bei der Fehlerbehebung des Style Validators beschrieben:

Konfigurationsfehler

Die folgenden Probleme werden beim Laden der Konfigurationsdatei abgelehnt und als invalid-config-Fehler gemeldet:

  • Unbekannte Schlüssel der obersten Ebene oder unbekannte Schlüssel in einer Regelkonfiguration.
  • Ein fehlender schema_version- oder ruleset_version-Parameter oder ein nicht unterstützter Wert für einen der beiden Parameter.
  • Kurzschreibweise für skalare Schweregrade, z. B. rule-name: warn.
  • Ein Überschreibungsblock mit fehlendem oder leerem files oder rules oder eine Regelkonfiguration in einem Überschreibungsblock ohne severity.
  • Ein unbekannter Regelname in einem Überschreibungsblock.
  • Eine benutzerdefinierte Regel, deren Name mit dem einer anderen benutzerdefinierten Regel oder einer integrierten Regel identisch ist.
  • Ein typspezifischer Schlüssel, der für die falsche rule_type verwendet wird (z. B. order_by für eine pattern_match-Regel).
  • Ein ungültiger regulärer Ausdruck.
  • Ein fehlender order_by-Parameter (für order-Regeln) oder unique_property-Parameter (für unique-Regeln).
  • Ein position-Wert, der nicht first ist (für first_child-Regeln).
  • Ein nicht in Anführungszeichen gesetztes führendes ! in einem Filterschlüssel, z. B. !hidden: true. Dies ist eine ungültige YAML-Tag-Syntax und führt dazu, dass die Konfigurationsdatei nicht geparst werden kann.

Stille Konfigurationsprobleme

  • Falsch geschriebene Regelnamen im globalen rules-Block werden stillschweigend ignoriert.
  • Falsch geschriebene LookML-Typnamen in select, filters, parent_filters, requires_child, forbidden_child oder order_by führen nicht zu einem Fehler. Stattdessen wird die Regel nie abgeglichen (oder schlägt bei requires_child immer fehl).
  • Wenn Sie sowohl match als auch should_not_match oder sowohl requires_child als auch forbidden_child angeben, wird nur der erste Parameter jedes Paars angewendet und der zweite ignoriert.
  • Die Angabe von parent_filters für eine first_child-Regel hat keine Auswirkungen und wird ignoriert.
  • Filter stimmen nur mit Attributen überein, die explizit in der LookML-Datei deklariert sind, nicht mit LookML-Standardwerten (siehe Filtersyntax).
  • Reguläre Ausdrucksmuster in pattern_match-Regeln sind nicht verankerte Teilstring-Übereinstimmungen, sofern Sie sie nicht mit ^ und $ verankern (siehe pattern_match).

Zulässige Syntaxvarianten

  • Bei den Werten für severity und rule_type wird die Groß- und Kleinschreibung nicht berücksichtigt.
  • rule_type: pattern wird als Alias für pattern_match akzeptiert.
  • Voran- und nachgestellte Leerzeichen in ruleset_version werden ignoriert.