Линтинг 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 — новые правила в свежем релизе не должны внезапно красить пайплайн.

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

• Тестирование и CI
• Salt в CI/CD
• SLS-файлы и YAML
• Jinja в SLS
• Тестирование состояний