Outil de validation de style d'intégration continue

Le validateur de style d'intégration continue (CI) applique les normes de codage LookML, les conventions de nommage et les bonnes pratiques structurelles à l'ensemble de votre projet LookML à l'aide du linter de style LookML. En vérifiant vos fichiers LookML par rapport à un ensemble configurable de règles de style, le validateur de style aide votre équipe à maintenir une base de code propre, cohérente et lisible.

Pour exécuter le validateur de style, vous devez ajouter un fichier de configuration nommé lkmlstyle.yaml (ou lkmlstyle.yml) au répertoire racine du dépôt de votre projet LookML. Pour savoir comment configurer le vérificateur de style, consultez la section Fichier de configuration de cette page.

Pour savoir comment configurer et exécuter le validateur de style dans une suite CI, et comment afficher les résultats de la validation, consultez les pages de documentation Créer une suite d'intégration continue, Exécuter des suites d'intégration continue et Afficher les résultats d'une exécution CI.

Avant de commencer

Pour utiliser le validateur de style dans l'intégration continue, vous avez besoin des éléments suivants :

Fichier de configuration

Un fichier de configuration est requis pour exécuter le validateur de style dans Looker CI. Lorsque le validateur de style s'exécute, il recherche automatiquement un fichier de configuration dans le répertoire racine du dépôt de votre projet LookML, dans l'ordre de priorité suivant :

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

Si les deux fichiers existent dans le répertoire racine, lkmlstyle.yaml est prioritaire et lkmlstyle.yml est ignoré.

Si ni lkmlstyle.yaml ni lkmlstyle.yml ne sont trouvés dans le répertoire racine du projet (et qu'aucune configuration personnalisée n'est transmise via l'API), la validation du style échoue et l'erreur "No style validator configuration provided" s'affiche.

Pour exécuter les 25 règles intégrées standards avec leurs paramètres par défaut, vous pouvez utiliser les informations de configuration minimales suivantes dans votre fichier lkmlstyle.yaml :

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

Sinon, vous pouvez personnaliser votre fichier de configuration. Le fichier de configuration peut contenir les paramètres de premier niveau suivants :

Paramètre Type Obligatoire ? Par défaut Description
schema_version Integer Oui Aucun Version du schéma de configuration. La version 1 est la seule version compatible et doit être spécifiée explicitement.
ruleset_version Chaîne Oui Aucun Édition du groupe de règles de référence à hériter. Valeurs autorisées : "all-v1.0", "none".
ignore_files Liste de chaînes Non [] Modèles glob des fichiers à exclure complètement de la validation du style.
rules Carte Non {} Personnalisations globales (severity et version) pour les règles individuelles. Vous pouvez également activer des règles intégrées qui ne sont pas incluses dans l'ensemble de règles de référence et modifier le niveau de gravité des règles personnalisées. Pour obtenir des exemples, consultez la section Personnalisation des règles.
overrides Liste des cartes Non [] Remplacements de règles à portée limitée qui ajustent ou activent les niveaux de gravité pour des chemins d'accès aux fichiers spécifiques.
custom_rules Liste des cartes Non [] Règles personnalisées déclaratives définies par l'utilisateur.

ruleset_version

Le paramètre ruleset_version définit la base de votre stratégie de validation du style :

  • "all-v1.0" (recommandé) : active les 25 règles de style LookML standards intégrées au niveau de gravité error. Cette option est idéale pour les équipes qui souhaitent appliquer une qualité complète prête à l'emploi.
  • "none" : aucune règle intégrée n'est activée par défaut. Cette option est idéale pour les équipes qui souhaitent adopter la validation du style de manière incrémentielle, activer des règles spécifiques une par une ou n'exécuter que des règles organisationnelles personnalisées. Pour activer une règle intégrée lorsque ruleset_version est défini sur "none", attribuez-lui un niveau de gravité warn ou error dans le bloc rules ou dans un bloc overrides.

ignore_files

Le paramètre ignore_files accepte une liste de modèles globaux pour les fichiers que vous souhaitez ignorer complètement lors de la validation du style. Les fichiers correspondant à ces modèles ne sont pas inspectés pour les règles intégrées ou personnalisées.

La syntaxe de caractères génériques acceptée inclut les éléments suivants :

  • * : correspond à n'importe quelle séquence de caractères non séparateurs dans un même niveau de répertoire.
  • ** : correspond à n'importe quelle séquence de caractères sur plusieurs niveaux de répertoires imbriqués.
  • ? : correspond à n'importe quel caractère.
  • {a,b} et [abc] : correspondent aux alternatives et aux classes de caractères (syntaxe glob Java).

Les règles de correspondance de chemin d'accès suivantes s'appliquent à chaque modèle glob du fichier de configuration, y compris ignore_files de premier niveau, ainsi que files et ignore_files dans overrides :

  • Les chemins d'accès sont relatifs au répertoire racine du projet. Un ./ ou un / en début de chaîne est ignoré.
  • Un format sans barre oblique (/) correspond à n'importe quelle profondeur de répertoire. Par exemple, *.ignore.lkml correspond à la fois à x.ignore.lkml et à views/x.ignore.lkml.
  • Un modèle se terminant par / correspond à tout ce qui se trouve dans ce répertoire.
  • Un motif se terminant par .lkml ou .lookml correspond également aux extensions composées. Par exemple, *.ignore.lkml correspond à x.ignore.view.lkml.

L'exemple suivant exclut les fichiers de fournisseurs, les anciens fichiers LookML et les tableaux de bord LookML :

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

rules

Vous pouvez utiliser le bloc rules pour ajuster la gravité des diagnostics de règles individuelles dans l'ensemble de votre projet :

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

Toute règle intégrée listée dans rules (ou dans un bloc overrides) avec un niveau de gravité warn ou error est active, même lorsque ruleset_version est défini sur "none". Par exemple, la configuration de démarrage suivante commence par ruleset_version: "none" et n'active que deux règles intégrées :

schema_version: 1
ruleset_version: "none"

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

Vous pouvez également utiliser le bloc rules pour modifier le niveau de gravité d'une règle personnalisée en référençant son nom.

severity

Chaque règle peut être configurée avec l'un des niveaux de gravité suivants (non sensibles à la casse) :

  • error : considérée comme un cas de non-respect majeur. Les erreurs entraînent l'échec de l'exécution de l'IC.
  • warn : émis en tant qu'avertissement non bloquant. Les avertissements s'affichent dans les rapports d'exécution de l'intégration continue, mais n'entraînent pas l'échec de l'exécution de l'intégration continue.
  • disabled : désactive complètement la règle et l'ignore lors de la validation.

overrides

Vous pouvez utiliser le paramètre overrides pour modifier le niveau de gravité des règles pour des fichiers ou des répertoires spécifiques sans modifier le niveau de gravité dans le reste de votre projet LookML. Par exemple, vous pouvez utiliser overrides pour assouplir les règles concernant les vues intermédiaires ou les anciens modèles, renforcer les règles concernant les chemins critiques ou activer des règles spécifiques uniquement pour certains répertoires lorsque ruleset_version est défini sur "none".

Chaque entrée de la liste overrides accepte les champs suivants :

Champ Type Obligatoire ? Description
files Liste de chaînes Oui Modèles globaux correspondant aux fichiers auxquels s'applique ce bloc de remplacement. Ce champ doit être renseigné.
ignore_files Liste de chaînes Non Schémas globaux à exclure de ce bloc de remplacement spécifique.
rules Carte Oui Mappage des noms de règles avec les configurations de gravité. Ce champ doit être renseigné. Seul severity est autorisé (et requis) dans les blocs de remplacement. Les noms de règles doivent être des noms de règles intégrées ou personnalisées valides.

L'exemple suivant désactive les vérifications de l'ordre des dimensions et rétrograde les erreurs de description manquante en avertissements pour les anciens tableaux de bord et vues :

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

Vous pouvez définir des règles personnalisées déclaratives dans la section custom_rules de votre fichier de configuration pour appliquer des conventions de dénomination spécifiques à l'organisation, des modèles architecturaux requis et une gouvernance structurelle.

Chaque définition de règle personnalisée accepte les paramètres communs suivants :

Champ Type Obligatoire ? Description
name Chaîne Oui Identifiant unique, au format dash-case par convention, tel que finance-measure-prefix. Ne doit pas entrer en conflit avec les noms de règles intégrés ni avec d'autres règles personnalisées.
title Chaîne Oui Message lisible par un humain qui s'affiche en cas de non-respect, au format (<rule-name>) <title>.
rule_type Chaîne Oui Archétype de la règle : pattern_match, property, order, first_child ou unique. Non sensible à la casse ; pattern est accepté comme alias pour pattern_match.
severity Chaîne Non Niveau de diagnostic : error (par défaut), warn ou disabled. Peut être remplacé par rules et overrides.
rationale Chaîne Non Explique pourquoi la règle existe.
select Chaîne ou liste Non Chemin d'accès au nœud de l'arbre de syntaxe abstraite (AST) à cibler, tel que "view.dimension", "explore" ou ["dimension", "dimension_group"]. Si elle est omise, la règle cible tous les nœuds correspondant à filters.
filters Carte Non Filtres de propriété qui doivent correspondre au nœud cible, tels que primary_key: true.
parent_filters Carte Non Filtres de propriété qui doivent correspondre au parent immédiat du nœud cible.

Chaque type de règle n'accepte que ses propres clés spécifiques. Les clés inconnues ou appartenant à un autre type de règle (par exemple, order_by sur une règle pattern_match) entraînent une erreur de configuration.

select

Le paramètre select détermine les éléments LookML que la règle personnalisée évalue :

  • Élément direct : ciblez un type d'élément LookML spécifique, tel que select: "dimension", select: "measure", select: "view", select: "explore", select: "join", select: "model" ou select: "include".
  • Chemin parent-enfant imbriqué : ciblez les éléments définis dans un parent immédiat spécifique, comme select: "view.dimension" (dimensions définies dans les vues) ou select: "explore.join" (jointures définies dans les explorations). Le parent doit être le parent immédiat, et seuls les deux derniers segments d'un chemin d'accès sont utilisés (a.b.c se comporte donc comme b.c).
  • Cibles multiples : ciblez plusieurs types d'éléments à l'aide d'une chaîne ou d'une liste séparées par une virgule, comme select: "dimension, dimension_group" ou select: ["dimension", "dimension_group"].

Les noms de sélecteurs, de filtres et d'enfants sont des mots clés LookML exacts et sensibles à la casse. Une faute d'orthographe dans un nom n'est pas signalée comme une erreur de configuration. La règle ne correspondra jamais.

filters et parent_filters

Vous pouvez utiliser filters et parent_filters pour affiner les nœuds ciblés en fonction des propriétés LookML déclarées de manière explicite dans le fichier LookML.

type: "string"
  • Égalité booléenne : correspond aux propriétés booléennes déclarées explicitement, telles que primary_key: true ou hidden: true.
  • Égalité de chaîne : faites correspondre les valeurs de chaîne exactes, telles que type: "yesno" ou type: "count".
  • Liste "un parmi" : correspond à n'importe quelle valeur d'une liste, comme type: ["string", "number", "date"].
  • Vérification de la présence : vérifiez si un bloc ou une propriété est présent en transmettant une chaîne vide, telle que derived_table: "".
  • Négation : ajoutez le préfixe ! à la clé ou à la valeur pour nier le filtre. Une clé négative doit être placée entre guillemets, car un ! en début de ligne sans guillemets est une syntaxe de balise YAML qui empêche l'analyse du fichier de configuration :
    • "!hidden": true ou hidden: "!true" correspond aux éléments visibles (non masqués), y compris les champs qui ne déclarent pas hidden.
    • type: ["!yesno", "!date"] correspond aux types qui ne sont ni yesno ni date.

rule_type

Chaque règle personnalisée doit spécifier l'un des cinq archétypes de règles suivants pour le paramètre rule_type :

pattern_match

Applique des modèles d'expressions régulières aux noms d'entités ou aux valeurs de propriétés LookML. Vous devez spécifier exactement une des valeurs match ou should_not_match (si les deux sont définies, seule match est appliquée et should_not_match est ignorée sans notification) :

  • match (chaîne, expression régulière) : modèle auquel la cible doit correspondre.
  • should_not_match (chaîne, expression régulière) : modèle auquel la cible ne doit pas correspondre.

Les modèles sont des expressions régulières Java qui sont validées lorsque le fichier de configuration est chargé. La correspondance est non ancrée (correspondance de sous-chaîne). Par exemple, match: "fin_" correspond à my_fin_total. Utilisez ^ et $ pour faire correspondre la valeur entière.

Si select cible une propriété au lieu d'une entité (par exemple, select: "measure.sql" ou select: "dimension.label"), l'expression régulière est évaluée par rapport à la valeur de la propriété plutôt qu'à un nom d'entité. Les règles measure-sql-table-reference et dimension-label-redundant-yes-no intégrées fonctionnent de cette manière.

Exemple qui impose que les mesures monétaires se terminent par _usd ou _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)$"

Exemple interdisant les dimensions temporaires ou brouillons :

- 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

Applique la présence obligatoire ou l'interdiction de propriétés enfants spécifiques dans les objets LookML. Vous devez spécifier exactement une des valeurs requires_child ou forbidden_child (si les deux sont définies, seule requires_child est appliquée et forbidden_child est ignorée sans notification) :

  • requires_child (chaîne ou liste) : nom ou noms des propriétés enfants qui doivent être présents. Lorsque vous spécifiez une liste, la règle est respectée si l'un des enfants listés est présent.
  • forbidden_child (chaîne ou liste) : nom ou noms des propriétés enfants qui ne doivent pas être présents. Lorsque vous spécifiez une liste, le nœud est signalé si l'un des enfants listés est présent.
  • child_filters (Map, facultatif) : filtres de propriété supplémentaires auxquels l'enfant requis doit répondre.

Exemple nécessitant des descriptions pour toutes les dimensions visibles :

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

Exemple interdisant sql_table_name sur les tables dérivées :

- 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

Applique un ordre alphabétique aux éléments frères d'un conteneur.

  • order_by (chaîne, obligatoire) : type LookML des enfants frères à ordonner, généralement "dimension" ou "measure". Seuls les enfants directs du nœud sélectionné sont comparés, et les enfants dimension_group ne sont pas inclus dans "dimension".

Les noms sont comparés en tenant compte de la casse, en fonction du code de caractère : les majuscules sont triées avant les minuscules, et _ est trié entre les deux.

Exemple nécessitant que les dimensions soient listées par ordre alphabétique dans les vues :

- 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

Force un élément correspondant à un filtre spécifique à apparaître comme le premier enfant de sa catégorie.

  • position (String, facultatif) : contrainte de position. Doit être "first" (la valeur par défaut est "first").

Pour les règles first_child, select doit utiliser le formulaire parent.child_type, tel que "view.dimension". Le paramètre filters identifie l'enfant qui doit apparaître en premier. Il ne limite pas les nœuds parents vérifiés. Le paramètre parent_filters est accepté par le schéma, mais il est ignoré pour ce type de règle.

Exemple nécessitant que la dimension de clé primaire soit déclarée en premier dans une vue :

- 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

Applique l'unicité d'une valeur de propriété à tous les nœuds correspondants dans les fichiers validés lors d'une exécution CI.

  • unique_property (chaîne, obligatoire) : nom de la propriété dont les valeurs doivent être uniques dans les nœuds correspondants, comme "sql_table_name" ou "label".

Les valeurs sont comparées en tant que chaînes exactes, et la première occurrence ainsi que chaque doublon sont signalés. Si une exécution de validation ne vérifie qu'un sous-ensemble des fichiers du projet, les doublons dans les fichiers en dehors de ce sous-ensemble ne sont pas détectés.

Exemple qui garantit des noms de table uniques dans toutes les vues :

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

Contraintes de règles personnalisées

Lorsque vous créez des règles personnalisées, respectez les contraintes suivantes :

  1. Aucune collision avec les noms de règles intégrés : les règles personnalisées ne peuvent pas réutiliser les noms du catalogue de règles intégrées, comme boolean-dimension-name-prefix ou sql-table-name-uniqueness.
  2. Noms personnalisés uniques : chaque règle personnalisée doit avoir un nom distinct dans la liste custom_rules.
  3. Format dash-case : les noms de règles doivent utiliser le format dash-case (lowercase-words-with-hyphens).

Ordre d'évaluation de la configuration

Lorsque le validateur de style évalue un fichier LookML, les règles de configuration sont appliquées dans l'ordre suivant :

  1. Exclusion de fichiers : si le fichier correspond à un modèle dans ignore_files, il est complètement ignoré.
  2. Règles actives : les règles actives pour le fichier sont celles de ruleset_version (all-v1.0 ou none), plus toute règle intégrée à laquelle est attribuée une gravité warn ou error dans rules ou dans un bloc overrides correspondant, plus toutes les règles définies dans custom_rules.
  3. Résolution de la gravité : pour chaque règle active, le premier des paramètres suivants qui spécifie une gravité est prioritaire : le dernier bloc overrides correspondant, puis le bloc rules global, puis le bloc severity de la règle personnalisée, et enfin la gravité par défaut (error).
  4. Règles désactivées : les règles dont la gravité résolue est disabled sont ignorées pour ce fichier.

Exemple de fichier de configuration

L'exemple suivant montre un fichier lkmlstyle.yaml complet qui illustre la sélection d'un ensemble de règles de base, les exclusions de fichiers, les personnalisations de règles globales, les remplacements à portée limitée et les règles personnalisées :

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

Champ d'application et résultats de la validation

Les sections suivantes décrivent les fichiers vérifiés par le validateur de style et la façon dont les résultats de la validation sont signalés :

Fichiers validés

  • Seuls les fichiers .lkml et .lookml du projet racine sont validés. Les projets de dépendances importés (locaux ou distants) ne sont pas validés.
  • Chaque fichier est validé en fonction de son propre contenu. Les instructions include: ne sont pas suivies et les objets extraits via une instruction include: ne sont pas validés dans le fichier d'inclusion.
  • Les exécutions CI déclenchées par les jobs CI dbt Cloud valident la branche LookML de production plutôt qu'une branche de développement.

Comportement et résultat de réussite ou d'échec

  • L'exécution d'un validateur de style n'échoue que si au moins un diagnostic présente le niveau de gravité error. Les avertissements seuls n'entraînent pas l'échec de l'exécution.
  • Sur la page des résultats de l'exécution de l'IC, chaque résultat de diagnostic inclut le nom de la règle, le chemin d'accès, le numéro de ligne, un extrait de contexte et un lien vers la documentation de la règle. Pour en savoir plus sur l'exécution de suites et l'affichage des résultats, consultez Exécuter des suites d'intégration continue et Afficher les résultats d'une exécution d'IC.
  • Un fichier de configuration non valide génère une seule erreur invalid-config sur la ligne 1 du fichier de configuration, et l'exécution de la validation échoue.

Validation incrémentielle

Vous pouvez activer la validation incrémentielle pour le validateur de style en cochant la case Erreurs incrémentielles uniquement (activée par défaut) dans la section Validateur de style lorsque vous créez ou modifiez une suite d'intégration continue.

Lorsque la validation incrémentielle est activée, le validateur de style ne signale que les nouvelles violations sur votre branche de développement :

  1. Elle valide la branche de développement.
  2. Il valide la branche cible à l'aide du fichier de configuration de la branche de développement.
  3. Il ne signale que les cas de non-respect qui ne sont pas déjà présents dans la branche cible.

Notez le comportement suivant lorsque la validation incrémentielle est activée :

  • Les cas de non-respect préexistants dans la branche cible n'entraînent pas l'échec de l'exécution.
  • Étant donné que le fichier de configuration de la branche de développement est utilisé pour valider les deux branches, une modification de la configuration sur la branche de développement ne peut pas masquer les cas de non-respect préexistants ni faire apparaître le code LookML préexistant comme de nouveaux cas de non-respect.
  • La branche de développement doit contenir un fichier de configuration lkmlstyle.yaml (ou lkmlstyle.yml). Sinon, l'exécution échoue et une erreur de configuration manquante s'affiche.

Lorsque l'option Erreurs incrémentielles uniquement est désactivée, chaque non-respect détecté dans la branche validée est signalé.

Catalogue de règles intégrées

Le tableau suivant liste les 25 règles standards intégrées disponibles dans l'ensemble de règles all-v1.0 :

Nom de la règle Entité cible Récapitulatif de la règle
average-measure-name-prefix Mesure Les mesures avec type: average ou average_distinct doivent commencer par avg_ ou average_.
boolean-dimension-name-prefix Dimension Les dimensions "Oui/Non" doivent commencer par is_, has_ ou does_.
count-measure-name-prefix Mesure Les mesures avec type: count ou count_distinct doivent commencer par count_.
dimension-group-name-suffix Groupe de dimensions Les groupes de dimensions ne doivent pas se terminer par _at, _date ni _time.
dimension-label-redundant-yes-no Dimension Les libellés de dimensions "Oui/Non" ne doivent pas inclure de marqueur "Oui/Non" tel que (Yes / No) ou (yes/no) (quelle que soit la casse ou l'espacement).
dimension-name-snake-case Dimension Les noms des dimensions et des groupes de dimensions doivent être en minuscules snake_case.
explore-fields-presence Explorer Les explorations doivent définir la propriété fields:.
explore-label-presence Explorer Les explorations doivent définir une propriété label: explicite.
includes-wildcard-usage Inclure Les instructions include: ne doivent pas utiliser de caractères génériques pour les fichiers de vue (tels que *.view.lkml ou /views/*.view). Les autres caractères génériques ne sont pas signalés.
join-relationship-presence Rejoindre Les déclarations Explore join: doivent spécifier un relationship:.
measure-name-snake-case Mesure Les noms de mesures doivent être en minuscules snake_case.
measure-sql-table-reference Mesure Les mesures doivent faire référence aux dimensions à l'aide de ${dimension_name}, et non de ${TABLE}.column.
numeric-measure-value-format-presence Mesure Les mesures avec type: count, sum, average ou number doivent spécifier value_format: ou value_format_name:.
pdt-view-name-prefix Afficher Les tables dérivées persistantes (PDT) doivent commencer par pdt_. Une vue est considérée comme un PDT si son derived_table définit datagroup_trigger, sql_trigger_value, interval_trigger ou persist_for, ou définit materialized_view: yes.
primary-key-first-dimension Dimension La dimension de clé primaire doit être la première dimension définie dans la vue.
primary-key-visibility Dimension Les dimensions de clé primaire doivent être masquées (hidden: yes).
sql-table-name-uniqueness Afficher Plusieurs vues ne doivent pas pointer vers le même sql_table_name.
sum-measure-name-prefix Mesure Les mesures avec type: sum ou sum_distinct doivent commencer par sum_ ou total_.
view-dimension-order Afficher Les dimensions d'une vue doivent être organisées par ordre alphabétique.
view-label-presence Afficher Les vues doivent définir un label: explicite.
view-measure-order Afficher Les mesures d'une vue doivent être organisées par ordre alphabétique.
view-name-snake-case Afficher Les noms de vues doivent être en minuscules snake_case (un + en début de nom est autorisé pour les affinements).
view-primary-key-presence Afficher Les vues avec sql_table_name ou derived_table (et sans extends) doivent définir une clé primaire.
visible-dimension-description-presence Dimension Les dimensions visibles doivent avoir une valeur description:.
visible-measure-description-presence Mesure Les mesures visibles doivent avoir un description:.

Dépannage

Les sections suivantes décrivent les problèmes de configuration courants et les variantes de syntaxe acceptées lors du dépannage du validateur de style :

Erreurs de configuration

Les problèmes suivants sont refusés lorsque le fichier de configuration est chargé et sont signalés comme une erreur invalid-config :

  • Clés de premier niveau inconnues ou clés inconnues dans une configuration de règle.
  • schema_version ou ruleset_version manquant, ou valeur non acceptée pour l'un ou l'autre paramètre.
  • Gravités scalaires abrégées, telles que rule-name: warn.
  • Bloc de remplacement avec files ou rules manquants ou vides, ou configuration de règle dans un bloc de remplacement sans severity.
  • Nom de règle inconnu dans un bloc de remplacement.
  • Règle personnalisée dont le nom est identique à celui d'une autre règle personnalisée ou d'une règle intégrée.
  • Une clé spécifique à un type utilisée sur un rule_type incorrect (par exemple, order_by sur une règle pattern_match).
  • Expression régulière non valide.
  • Paramètre order_by manquant (pour les règles order) ou paramètre unique_property manquant (pour les règles unique).
  • Une valeur position autre que first (pour les règles first_child).
  • Un ! non mis entre guillemets en début de clé de filtre, tel que !hidden: true, qui est une syntaxe de balise YAML non valide et empêche l'analyse du fichier de configuration.

Problèmes de configuration silencieux

  • Les noms de règles mal orthographiés dans le bloc rules global sont ignorés sans notification.
  • Les noms de types LookML mal orthographiés dans select, filters, parent_filters, requires_child, forbidden_child ou order_by ne génèrent pas d'erreur. Au lieu de cela, la règle ne correspond jamais (ou échoue toujours pour requires_child).
  • Si vous spécifiez à la fois match et should_not_match, ou à la fois requires_child et forbidden_child, seul le premier paramètre de chaque paire est appliqué, et le second est ignoré.
  • Spécifier parent_filters sur une règle first_child n'a aucun effet et est ignoré.
  • Les filtres ne correspondent qu'aux propriétés explicitement déclarées dans le fichier LookML, et non aux valeurs LookML par défaut (voir Syntaxe de filtrage).
  • Les modèles d'expression régulière dans les règles pattern_match sont des correspondances de sous-chaîne non ancrées, sauf si vous les ancrez avec ^ et $ (voir pattern_match).

Variantes syntaxiques acceptées

  • Les valeurs de severity et rule_type ne sont pas sensibles à la casse.
  • rule_type: pattern est accepté comme alias pour pattern_match.
  • Les espaces blancs de début et de fin dans ruleset_version sont ignorés.