Линтинг SLS

salt-lint — статический анализатор SLS-файлов, поддерживаемый компанией Warpnet. Он сделан по образцу ansible-lint и решает ту же задачу: находит проблемы в коде состояний до того, как они доедут до мастера. Линтер работает с исходным текстом файла — ему не нужны ни мастер, ни миньоны, ни рендеринг Jinja, поэтому проверка занимает секунды и легко встраивается в pre-commit-хук и CI. Это первый рубеж обороны в пирамиде тестирования Salt: он не проверяет логику состояний, зато дёшево отсекает целый пласт механических ошибок — от битых отступов до секретов, случайно закоммиченных в открытом виде.

Как это работает

Устанавливается через pip install salt-lint, запускается как salt-lint init.sls или на всё дерево сразу: git ls-files '*.sls' | xargs salt-lint. Анализатор разбирает файл как текст с учётом YAML- и Jinja-синтаксиса и применяет набор пронумерованных правил: висячие пробелы, слишком длинные строки, числовые режимы файлов без кавычек (классическая ловушка YAML с восьмеричными числами), устаревший синтаксис, подозрительные места вроде паролей прямо в состоянии. При находках возвращает ненулевой код выхода — этого достаточно, чтобы CI-джоба упала. Поведение настраивается файлом .salt-lint в корне репозитория: список игнорируемых правил (skip_list), исключаемые пути. Точечно правило глушится инлайн-комментарием # noqa с номером правила. Для машинной обработки есть вывод в JSON, а для локальной автоматизации проект публикует готовый pre-commit-хук.

Когда применять

Всегда, когда SLS-файлы лежат в Git и их редактирует больше одного человека, — по сути, в любом непустом репозитории состояний. Типовая схема двухступенчатая: локально линтер срабатывает в pre-commit и ловит ошибки до коммита, а в CI тот же прогон выполняется обязательным шагом на каждый push — это защищает от тех, у кого хуки не установлены. Важно понимать границы инструмента: salt-lint не рендерит Jinja и не знает ваших pillar-значений, поэтому он не заметит обращение к несуществующему ключу или ошибку в логике цикла. Для этого нужен следующий уровень — рендер-проверка через state.show_sls и полноценные тесты состояний. Линтер отвечает на вопрос «аккуратен ли код», а не «работает ли он».

Типичные ошибки

Главная — включить линтер на большом легаси-репозитории сразу в блокирующем режиме: сотни предупреждений, CI красный у всех, и через неделю проверку просто отключают. Правильный путь — начать с skip_list на самые шумные правила и включать их обратно по мере чистки. Вторая ошибка — противоположная: расставлять # noqa на всё подряд, превращая линтер в декорацию; каждое подавление должно быть осознанным. Третья — прогонять только изменённые файлы: правка общего Jinja-макроса может сломать SLS, которого нет в диффе, поэтому полный прогон дешевле разбирательств. И не забывайте пиннить версию линтера в CI — новые правила в свежем релизе не должны внезапно красить пайплайн.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы