지속적 통합 스타일 검사기

지속적 통합 (CI) 스타일 유효성 검사기는 LookML 스타일 린터를 사용하여 LookML 프로젝트 전반에 LookML 코딩 표준, 이름 지정 규칙, 구조적 권장사항을 적용합니다. 스타일 검사기는 구성 가능한 스타일 규칙에 따라 LookML 파일을 검사하여 팀이 깔끔하고 일관되며 가독성이 높은 코드베이스를 유지하도록 지원합니다.

스타일 검사기를 실행하려면 LookML 프로젝트 저장소의 루트 디렉터리에 lkmlstyle.yaml (또는 lkmlstyle.yml)라는 구성 파일을 추가해야 합니다. 스타일 린터 구성에 대한 자세한 내용은 이 페이지의 구성 파일 섹션을 참고하세요.

CI 스위트에서 스타일 유효성 검사기를 구성하고 실행하고 유효성 검사 출력을 보는 방법에 대한 자세한 내용은 지속적 통합 스위트 만들기, 지속적 통합 스위트 실행, CI 실행 결과 보기 문서 페이지를 참고하세요.

시작하기 전에

지속적 통합에서 스타일 검사기를 사용하려면 다음이 필요합니다.

• Looker 26.18 이상을 실행하고 CI 요구사항을 충족하며 CI가 사용 설정된 Looker 인스턴스
• Git 버전 제어로 구성된 LookML 프로젝트
• CI 스위트 설정에서 사용 설정된 스타일 검사기 전환 버튼 (스타일 검사기는 기본적으로 사용 중지되어 있음) 스타일 유효성 검사기를 사용 설정하면 증분 오류만 옵션이 기본적으로 사용 설정됩니다.
• LookML 프로젝트 저장소의 루트 디렉터리에 있는 lkmlstyle.yaml (또는 lkmlstyle.yml) 구성 파일 이 페이지의 구성 파일 섹션을 참고하세요.

구성 파일

Looker CI에서 스타일 검사기를 실행하려면 구성 파일이 필요합니다. 스타일 검사기가 실행되면 LookML 프로젝트 저장소의 루트 디렉터리에서 다음 우선순위 순서로 구성 파일을 자동으로 확인합니다.

1. lkmlstyle.yaml
2. lkmlstyle.yml

두 파일이 모두 루트 디렉터리에 있는 경우 lkmlstyle.yaml가 우선 적용되며 lkmlstyle.yml는 무시됩니다.

lkmlstyle.yaml도 lkmlstyle.yml도 프로젝트 루트 디렉터리에 없고 API를 통해 전달된 맞춤 구성이 없으면 스타일 검증 실행이 "No style validator configuration provided" 오류와 함께 실패합니다.

참고: Looker IDE는 프로젝트 루트 디렉터리의 lkmlstyle.yaml을 예약된 프로젝트 파일로 취급하고 스키마 기반 자동 완성 및 유효성 검사를 제공합니다. IDE 검사는 게시된 JSON 스키마를 기반으로 하므로 IDE에서 유효성 검사를 통과하는 일부 구성은 스타일 검사기를 실행할 때 거부될 수 있습니다.

기본 설정으로 25개의 표준 기본 제공 규칙을 모두 실행하려면 lkmlstyle.yaml 파일에서 다음 최소 구성 정보를 사용하면 됩니다.

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

그렇지 않으면 구성 파일을 맞춤설정할 수 있습니다. 구성 파일에는 다음 최상위 매개변수가 포함될 수 있습니다.

매개변수	유형	필수 여부	기본값	설명
schema_version	정수	예	없음	구성 스키마 버전입니다. 버전 1만 지원되며 명시적으로 지정해야 합니다.
ruleset_version	문자열	예	없음	상속할 기준 규칙 세트 버전입니다. 지원되는 값은 "all-v1.0", "none"입니다.
ignore_files	문자열 목록	아니요	[]	스타일 검사에서 완전히 제외할 파일의 glob 패턴입니다.
rules	지도	아니요	{}	개별 규칙의 전역 맞춤설정 (severity 및 version) 기준 규칙 세트에 포함되지 않은 기본 제공 규칙을 사용 설정하고 맞춤 규칙의 심각도를 변경할 수도 있습니다. 예는 규칙 맞춤설정 섹션을 참고하세요.
overrides	List of maps	아니요	[]	특정 일치 파일 경로의 심각도를 조정하거나 사용 설정하는 범위가 지정된 규칙 재정의입니다.
custom_rules	List of maps	아니요	[]	선언적 사용자 정의 맞춤 규칙입니다.

ruleset_version

ruleset_version 파라미터는 스타일 검사 전략의 기반을 정의합니다.

• "all-v1.0" (권장): error 심각도 수준에서 25개의 모든 표준 내장 LookML 스타일 규칙을 활성화합니다. 이 옵션은 포괄적인 품질 시행을 기본적으로 원하는 팀에 적합합니다.
• "none": 사용 설정된 내장 규칙이 0개로 시작합니다. 이 옵션은 스타일 검증을 점진적으로 채택하거나, 특정 규칙을 하나씩 선택하거나, 맞춤 조직 규칙만 실행하려는 팀에 적합합니다. ruleset_version가 "none"인 경우 기본 제공 규칙을 선택하려면 rules 블록 또는 overrides 블록에서 규칙에 warn 또는 error 심각도를 할당합니다.

ignore_files

ignore_files 매개변수는 스타일 검사 중에 완전히 우회하려는 파일의 glob 패턴 목록을 허용합니다. 이러한 패턴과 일치하는 파일은 기본 제공 규칙이나 맞춤 규칙에 대해 검사되지 않습니다.

지원되는 와일드 카드 문법은 다음과 같습니다.

• *: 단일 디렉터리 수준 내에서 구분자가 아닌 모든 문자 시퀀스와 일치합니다.
• **: 여러 중첩된 디렉터리 수준에서 모든 문자 시퀀스와 일치합니다.
• ?: 단일 문자와 일치합니다.
• {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

심각도가 warn 또는 error인 rules (또는 overrides 블록)에 나열된 기본 제공 규칙은 ruleset_version이 "none"로 설정된 경우에도 활성 상태입니다. 예를 들어 다음 시작 구성은 ruleset_version: "none"로 시작하고 두 개의 기본 제공 규칙만 사용 설정합니다.

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: 규칙을 완전히 비활성화하고 검증 중에 건너뜁니다.

중요: 규칙 구성은 rule-name: { severity: warn }과 같은 맵으로 정의해야 합니다. rule-name: warn와 같은 약식 스칼라 구문은 지원되지 않으며 구성 유효성 검사 오류가 발생합니다. 전역 rules 블록에서 severity는 선택사항이며 (기본값은 error이므로 rule-name: {}이 유효함) 선택사항인 version 키가 허용됩니다 (모든 기본 제공 규칙은 버전 1에 있으므로 version를 생략할 수 있음). overrides 블록 내에서 severity이 필요하며 허용되는 유일한 키입니다.

경고: 전역 rules 블록의 규칙 이름은 검증되지 않습니다. 맞춤법이 틀린 규칙 이름은 자동으로 무시되며 수정하려는 규칙은 기본 심각도를 유지합니다. overrides 블록의 규칙 이름이 검증됩니다.

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 내에 정의된 조인)와 같은 특정 직계 상위 요소 내에 정의된 요소를 타겟팅합니다. 상위 요소는 직계 상위 요소여야 하며 경로의 마지막 두 세그먼트만 사용됩니다 (따라서 a.b.c는 b.c처럼 동작함).
• 여러 타겟: 쉼표로 구분된 문자열 또는 목록(예: select: "dimension, dimension_group" 또는 select: ["dimension", "dimension_group"])을 사용하여 여러 요소 유형을 타겟팅합니다.

선택기, 필터, 하위 이름은 정확한 대소문자 구분 LookML 키워드입니다. 이름의 철자가 틀린 경우 구성 오류로 보고되지 않으며 규칙이 일치하지 않습니다.

filters 및 parent_filters

filters 및 parent_filters를 사용하여 LookML 파일에 명시적으로 선언된 LookML 속성을 기반으로 타겟팅된 노드를 세분화할 수 있습니다.

중요: LookML 기본값이 적용되지 않습니다. 예를 들어 hidden: false는 hidden: no를 문자 그대로 선언하는 LookML 필드만 일치합니다. 하지만 hidden의 기본값은 no이므로 LookML에서 hidden: no를 선언하지 않을 가능성이 높습니다. 마찬가지로 type: "string"의 경우 string이 type의 기본값이므로 LookML 프로젝트에 type: "string"이 없을 가능성이 높습니다.

• 불리언 동등성: primary_key: true 또는 hidden: true과 같이 명시적으로 선언된 불리언 속성을 일치시킵니다.
• 문자열 동일성: type: "yesno" 또는 type: "count"과 같은 정확한 문자열 값을 일치시킵니다.
• 목록 중 하나: type: ["string", "number", "date"]와 같은 목록의 값과 일치합니다.
• 존재 여부 확인: derived_table: ""와 같은 빈 문자열을 전달하여 블록 또는 속성이 있는지 확인합니다.
• 부정: 키 또는 값 앞에 !를 추가하여 필터를 부정합니다. 부정된 키는 따옴표로 묶어야 합니다. 따옴표로 묶이지 않은 선행 !는 YAML 태그 구문이므로 구성 파일의 파싱이 실패합니다.
  • "!hidden": true 또는 hidden: "!true"는 hidden를 선언하지 않는 필드를 포함하여 표시되는 (숨겨지지 않은) 항목과 일치합니다.
  • type: ["!yesno", "!date"]은 yesno도 date도 아닌 유형과 일치합니다.

rule_type

각 맞춤 규칙은 rule_type 매개변수에 대해 다음 다섯 가지 규칙 원형 중 하나를 지정해야 합니다.

• pattern_match
• property
• order
• first_child
• unique

pattern_match

LookML 항목 이름 또는 속성 값에 정규 표현식 패턴을 적용합니다. match 또는 should_not_match 중 하나만 지정해야 합니다. 둘 다 설정된 경우 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 중 하나만 지정해야 합니다. 둘 다 설정된 경우 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"

참고: 이 예에서는 기본 제공 view-dimension-order 규칙을 복제합니다. all-v1.0에서 이와 같은 맞춤 규칙을 사용하는 경우 내장 규칙을 사용 중지하세요. 그렇지 않으면 각 위반이 두 번 보고됩니다.

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

참고: 이 예에서는 기본 제공 primary-key-first-dimension 규칙을 복제합니다. all-v1.0에서 이와 같은 맞춤 규칙을 사용하는 경우 내장 규칙을 사용 중지하세요. 그렇지 않으면 각 위반이 두 번 보고됩니다.

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 브랜치를 검증합니다.

통과 또는 실패 동작 및 출력

• 스타일 검사기 실행은 진단 중 하나 이상이 error 심각도를 갖는 경우에만 실패합니다. 경고만으로는 실행이 실패하지 않습니다.
• CI 실행 결과 페이지에서 각 진단 결과에는 규칙 이름, 경로, 줄 번호, 컨텍스트 스니펫, 규칙 문서 링크가 포함됩니다. 스위트 실행 및 결과 보기에 관한 자세한 내용은 지속적 통합 스위트 실행 및 CI 실행 결과 보기를 참고하세요.
• 잘못된 구성 파일은 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	측정기준	예/아니요 측정기준은 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	참여	탐색 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 (first_child 규칙의 경우)이 아닌 position 값
• 필터 키에 따옴표로 묶이지 않은 선행 !(예: !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를 모두 지정하는 경우: 각 쌍의 첫 번째 매개변수만 적용되고 두 번째 매개변수는 무시됩니다.
• first_child 규칙에 parent_filters를 지정해도 효과가 없으며 무시됩니다.
• 필터는 LookML 기본값이 아닌 LookML 파일에 명시적으로 선언된 속성만 일치시킵니다 (필터링 문법 참고).
• pattern_match 규칙의 정규 표현식 패턴은 ^ 및 $로 고정하지 않는 한 고정되지 않은 하위 문자열 일치입니다 (pattern_match 참고).

허용되는 문법 변형

• severity 및 rule_type 값은 대소문자를 구분하지 않습니다.
• rule_type: pattern은 pattern_match의 별칭으로 허용됩니다.
• ruleset_version의 선행 및 후행 공백은 무시됩니다.