0%

Шпаргалка: dmtlint / pkglint

pkglint проверяет Application-пакеты (курс сфокусирован на нём), dmtlint — Module (нужен Application-разработчику только для понимания зависимостей, не для авторства модулей). Полный разбор — M9 уроки 2–4.

Самые используемые команды

1
2
3
4

d8 package verify                          # запустить pkglint на локальной директории пакета (6 линтеров)
d8 package verify --hide-warnings           # только ошибки — типичный строгий CI-гейт
dmt lint [dirs...]                            # запустить dmtlint на директории Module (9 линтеров, для анализа зависимостей)
dmt lint [dirs...] --linter <name>              # запустить только один линтер

d8 package verify — pkglint (6 линтеров, Application)

1
2
3
4
5
6
7

d8 package verify
d8 package verify --hide-warnings                   # показывать только ошибки, скрывая warnings (типично для CI)
d8 package verify --show-ignored                      # показать находки, явно исключённые через .pkglint.yaml
d8 package verify --remote <ref>                        # проверить уже опубликованный артефакт в registry, не локальную директорию
d8 package verify --remote registry.example.org/packages/umami/version/0.1.0
d8 package verify --lint-config <path>                    # указать альтернативный конфиг вместо .pkglint.yaml
d8 package verify --lint-config ./.pkglint.yaml             # явное указание файла конфигурации по умолчанию

6 линтеров pkglint:

ЛинтерЧто проверяет
docsналичие и корректность документации (docs/, обязательные разделы, локализация)
iconналичие, формат и размеры иконки пакета
imagesпрактики сборки (werf.yaml, Dockerfile): явные версии base image, отсутствие мутабельного тега :latest
layoutструктура файлов/директорий пакета (changelog.yaml, openapi/ и т.д.)
ossкорректность oss.yaml (обязательные поля, SPDX-лицензии)
templatesHelm/Nelm-шаблоны: синтаксис, обязательные метки (app.kubernetes.io/name, app.kubernetes.io/instance)

Конфигурация .pkglint.yaml (в корне пакета) — переопределяет дефолтные правила: какие находки повышать/понижать в severity, какие правила исключать точечно.

oss.yaml — поля, проверяемые линтером oss

Плоский список компонентов (без обёртки items:):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

- id: <component-id> # стабильный идентификатор для диагностики
  name: <component-name> # имя open-source компонента
  description: <text> # описание компонента
  license: <SPDX-identifier> # одна строка (например MIT, AGPL-3.0, MIT OR Apache-2.0)
  link: <url> # ссылка на исходный репозиторий или лицензию
  version: <exact-version> # точная версия (взаимоисключимо с versions)
  # versions:                  # альтернатива version — список {name, version, condition}
  #   - name: ...
  #     version: ...
  #     condition: ...

dmt lint — dmtlint (9 линтеров, Module)

Application-разработчику нужен для понимания, как проверяются Module-зависимости платформы (см. M6 «Обязательные модули») — не для написания собственных Module.

1
2
3
4
5
6
7

dmt lint [dirs...]
dmt lint [dirs...] --linter <name>            # запустить только один линтер (например, rbac)
dmt lint [dirs...] --values-file <path>         # передать values-файл при линтинге
dmt lint [dirs...] --hide-warnings                # скрыть предупреждения, показать только ошибки
dmt lint [dirs...] --abs-path                       # вывод абсолютных путей в находках
dmt lint [dirs...] --show-ignored                     # показать находки, исключённые через .dmtlint.yaml
dmt lint [dirs...] --log-level <level>                  # управление уровнем логирования

9 линтеров dmtlint:

ЛинтерЧто проверяет
containerдубли имён контейнеров, env, securityContext, probes, resources
docsREADME, билингвальность (ru/en), отсутствие кириллицы в EN-версии
hooksсинтаксис Go-хуков, ingress-конфигурации, регистрируемые хуками
imagesпрактики Dockerfile/werf-сборки образов Module
modulemodule.yaml, OpenAPI-конверсии, oss.yaml, лицензии зависимостей
no-cyrillicотсутствие кириллицы там, где ожидается только английский текст
openapiкорректность OpenAPI-схем, конвенции именования CRD
rbacRole/RoleBinding/ServiceAccount, wildcard-права (resources: ["*"], verbs: ["*"])
templatesVPA/PDB, интеграция Prometheus/Grafana, порты сервисов

Прочие команды dmt

1
2
3
4
5

dmt bootstrap <name> [--pipeline github|gitlab] [--directory <dir>] [--repository-url <url>]   # скаффолдинг нового Module
dmt render [module-path] [--output <dir>]                     # рендер чартов Module с учётом Deckhouse-контекста (НЕ "сырой" helm template)
dmt render <module-path> --output ./rendered
dmt test conversions [module-path] [--update]                    # тест миграции config-values.yaml между версиями схемы
dmt test templates [module-path] [--update]                         # тест шаблонов Module

.dmtlint.yaml — ключи конфигурации

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

linters-settings:
  <linter>:
    impact: error         # находки линтера блокируют CI
    impact: warn            # находки понижены до предупреждений, не блокируют CI

exclude-rules:
  <linter>:
    - kind: <Kind>            # точечное исключение находки по Kubernetes kind
      name: <name>              # точечное исключение находки по имени ресурса
      container: <name>           # исключение по имени контейнера

Прочие файлы, проверяемые линтерами

1
2
3
4

changelog.yaml    # обязательный файл, проверяется линтером layout (pkglint)
openapi/            # директория, имя/структура проверяются линтером layout (pkglint)
.pkglint.yaml         # конфигурация pkglint (Application), в корне пакета
.dmtlint.yaml           # конфигурация dmtlint (Module), в корне модуля

Место в CI/CD-пайплайне

Типовой порядок стадий (см. M9 урок 6, M11 урок 4):

1
2
3

setup  → build → verify → publish
         (werf     (d8 package    (d8 package
          build)    verify)        build)

1
2

# verify-package job (stage: verify) — типовой шаг перед публикацией
d8 package verify --hide-warnings

d8 package verify — единственный вызов линтера, встречающийся в практике курса как гейт CI; dmt lint в уроках Application-трека появляется только как read-only анализ чужого Module (git clone --depth 1 https://github.com/deckhouse/modules-template.git) для понимания зависимостей, а не как шаг публикации собственного пакета.