Ctrl+K
Ctrl+K
Ctrl+K

Ansible Lint

Ansible Lint#

Утилита Ansible Lint является универсальным инструментом для проверки качества и стиля кода в сценариях, ролях и коллекциях Ansible. Для этого она предоставляет различные аргументы, описание которых приводится далее.

Вызов утилиты имеет следующий вид:

ansible-lint [-h] [-P | -L | -T] [-f {brief,full,md,json,codeclimate,quiet,pep8,sarif}] [--sarif-file SARIF_FILE] [-q]
             [--profile {min,basic,moderate,safety,shared,production}] [-p] [--project-dir PROJECT_DIR] [-r RULESDIR]
             [-R] [-s] [--fix [WRITE_LIST]] [--show-relpath] [-t TAGS] [-v] [-x SKIP_LIST] [--generate-ignore] [-w WARN_LIST]
             [--enable-list ENABLE_LIST] [--nocolor] [--force-color] [--exclude EXCLUDE_PATHS [EXCLUDE_PATHS ...]]
             [-c CONFIG_FILE] [-i IGNORE_FILE] [--offline] [--version] [lintables ...]

Для понимания принципов работы утилиты обратитесь к ее описанию.

Аргументы команды#

При запуске Ansible Lint можно использовать следующие аргументы:

lintables#

Позиционный аргумент, идущий в самом конце и определяющий список файлов (список путей), подлежащих проверке.

-h, --help#

Вывод справочной информации.

-P, --list-profiles#

Вывод списка всех профилей. Форматирование вывода не поддерживается.

-L, --list-rules#

Вывод списка всех правил. Возможные значения:

  • brief – краткое описание правил (по умолчанию);

  • full – полное описание правил;

  • md – формат Markdown.

-T, --list-tags#

Вывод всех тегов и правил, к которым они относятся. Чтобы включить правила с тегом opt-in, необходимо повысить уровень детализации с помощью флага -v.

-f, --format#

Формат вывода:

  • brief – краткий;

  • codeclimate – совместимый с Code Climate;

  • full – полный с выводом детальной информацией о каждой найденной проблеме;

  • json – JSON;

  • md – Markdown;

  • pep8 – соответствующий стандарту PEP 8;

  • quiet– минимально возможное количество информации, то есть только сообщения об ошибках;

  • sarif – SARIF.

Значение по умолчанию отсутствует.

--sarif-file#

Файл для вывода в формате SARIF.

-q#

Уменьшение уровня детализации вывода. Для минимального уровня укажите -qq.

--profile#

Профиль проверки:

  • min – минимальные проверки, чтобы Ansible мог загрузить контент;

  • basic – стандартные правила форматирования и синтаксиса;

  • moderate – рекомендации по читаемости и поддержке;

  • safety – правила безопасности для избежания использования опасных модулей;

  • shared – профиль для подготовки к публикации кода;

  • production – наивысший уровень строгости.

-p, --parseable#

Вывод результата в формате, удобном для разбора, эквивалентен -f pep8.

--project-dir#

Каталог проекта или репозитория. По умолчанию – каталог, в котором расположен конфигурационный файл .ansible-lint.

-r, --rules-dir#

Каталоги с пользовательскими правилами. Указанные правила заменяют собой встроенные. Чтобы использовать и встроенные правила, и пользовательские, используйте аргумент --rules-dir совместно с аргументом -R.

-R#

Сохранение встроенных правил при использовании аргумента -r.

-s, --strict#

Возвращение ненулевого кода выхода для предупреждений, а не только для ошибок.

---fix#

Разрешение автоматического исправления проблем, включая форматирование YAML. Можно ограничить список правил, для которых разрешены исправления, указав all, none, список идентификаторов или тегов.

--show-relpath#

Вывод относительного пути к текущему каталогу.

-t, --tags#

Использование только тех правил, идентификаторы или теги которых совпадают с указанными.

-v#

Повышение уровня детализации вывода. Для максимального уровня укажите -vv.

-x, --skip-list#

Использование только тех правил, идентификаторы или теги которых не совпадают с указанными, например, --skip-list=name.

--generate-ignore#

Генерация файла .ansible-lint-ignore, который содержит список файлов и правил, которые должны быть пропущены при проверке. Каждая строка содержит путь к файлу и через пробел название или идентификатор правила.

-w, --warn-list#

Показ предупреждений только для указанных правил, если это не переопределено в конфигурационном файле. Значение по умолчанию: experimental, jinja[spacing], fqcn[deep].

--enable-list#

Включение дополнительных правил. Позволяет указать идентификаторы или теги дополнительных правил, которые должны быть включены при проверке.

--nocolor#

Отключение цветного вывода (эквивалентно NO_COLOR=1).

--force-color#

Принудительное включение цветного вывода (эквивалентно FORCE_COLOR=1).

--exclude#

Путь к файлу или каталогу, который следует пропустить (повторяемый параметр).

-c, --config-file#

Конфигурационный файл. По умолчанию ищет файлы .ansible-lint, config/ansible-lint.yml, или .config/ansible-lint.yaml.

-i, --ignore-file#

Файл игнорирования. В файле игнорирования содержится список файлов и правил, которые должны быть пропущены при проверке. Каждая строка содержит путь к файлу и через пробел идентификатор правила. По умолчанию ищет файлы .ansible-lint-ignore или .config/ansible-lint-ignore.txt.

--offline#

Отключение установки зависимостей из requirements.yml и обновления схем.

--version#

Вывод информации о версии Ansible Lint.

Переменные окружения#

При запуске Ansible Lint можно использовать следующие переменные окружения:

ANSIBLE_LINT_CUSTOM_RULESDIR#

Путь к каталогам с пользовательскими правилами.

ANSIBLE_LINT_IGNORE_FILE#

Переопределение имени файла игнорирования.

Значение по умолчанию – .ansible-lint-ignore.

ANSIBLE_LINT_WRITE_TMP#

Сохранение исправлений во временные файлы, не изменяя оригиналы. Созданные временные файлы используются для проверки.

ANSIBLE_LINT_SKIP_SCHEMA_UPDATE#

Отключение обновления схем.

ANSIBLE_LINT_NODEPS#

Отключение установки зависимостей и проверок, которые могут завершиться неудачей при отсутствии модулей.

Файл настроек#

В файле настроек Ansible Lint можно задать следующие параметры:

profile#

Профиль проверки. Возможные значения параметра приведены в описании аргумента --profile. При значении null, используется конфигурация, заданная другими параметрами.

Пример заполнения:

profile: null
sarif_file#

Файл для вывода в формате SARIF.

Пример заполнения:

sarif_file: result.sarif
exclude_paths#

Путь к файлу или каталогу, который следует пропустить (повторяемый параметр).

Пример заполнения:

exclude_paths:
  - .cache/
  - test/fixtures/formatting-before/
  - test/fixtures/formatting-prettier/
parseable#

Включение форматирования, удобного для разбора.

Пример заполнения:

parseable: true
quiet#

Понижение уровня детализации вывода.

Пример заполнения:

quiet: true
strict#

Указание обрабатывать предупреждения как ошибки.

Пример заполнения:

strict: true
verbosity#

Уровень подробности вывода. Если установлено значение 1, вывод будет наименее подробным. Для более детализированного вывода используйте более высокие значения.

Пример заполнения:

verbosity: 1
mock_modules#

Список модулей, которые Ansible Lint должен имитировать для прохождения синтаксической проверки, если они отсутствуют.

Пример заполнения:

mock_modules:
  - zuul_return
  - fake_namespace.fake_collection.fake_module
  - fake_namespace.fake_collection.fake_module.fake_submodule
mock_roles#

Список ролей, которые Ansible Lint должен имитировать для прохождения синтаксической проверки, если они отсутствуют.

Пример заполнения:

mock_roles:
  - mocked_role
  - author.role_name
  - fake_namespace.fake_collection.fake_role
loop_var_prefix#

Определение префиксов для переменных цикла, используемых в ролях. Префикс должен начинаться с __ или названия роли, что предотвращает конфликт названий переменных.

Пример заполнения:

loop_var_prefix: "^(__|{role}_)"
var_naming_pattern#

Регулярное выражение, определяющее допустимый шаблон для названий переменных. В данном примере название переменной должно начинаться с буквы или подчеркивания и содержать только строчные буквы, цифры и подчеркивания:

var_naming_pattern: "^[a-z_][a-z0-9_]*$"
use_default_rules#

Указание необходимости использования встроенных правил Ansible Lint.

Пример заполнения:

use_default_rules: true
rulesdir#

Список путей к каталогам с пользовательскими правилами.

Пример заполнения:

rulesdir:
  - ./rule/directory/
skip_list#

Список тегов правил, которые должны быть проигнорированы. Чтобы правило было пропущено, достаточно совпадения одного тега из списка.

Пример заполнения:

skip_list:
  - skip_this_tag
enable_list#

Список дополнительных правил.

Пример заполнения:

enable_list:
  - args
  - empty-string-compare
  - no-log-password
  - no-same-owner
  - name[prefix]
  - galaxy-version-incorrect
  - yaml
tags#

Ограничение проверки только правилами с указанными тегами. Чтобы правило было выбрано, достаточно, чтобы оно содержало один из указанных тегов.

Пример заполнения:

tags:
  - jinja[spacing]
warn_list#

Список тегов для правил, неудачную проверку которых нужно рассматривать как предупреждение, а не ошибку. Чтобы правило попало в предупреждения, достаточно совпадения одного тега из списка.

Пример заполнения:

warn_list:
  - skip_this_tag
  - experimental
write_list#

Автоматическое исправление кода для соответствия указанным правилам. Возможные значения:

  • all – разрешает все исправления;

  • none – отключает исправления;

  • список тегов.

Пример заполнения:

write_list:
  - all
offline#

Отключение установки зависимостей и обновления схем.

Пример заполнения:

offline: true
extra_vars#

Значения обязательных переменных Ansible, используемых в сценариях или ролях, чтобы избежать ошибок анализа, возникающих из-за их отсутствия.

Пример заполнения:

extra_vars:
  foo: bar
  multiline_string_variable: |
    line1
    line2
  complex_variable: ":{;\t$()"
skip_action_validation#

Включение принудительной проверки действий с помощью задач. Обычно это не требуется, потому что проверка синтаксиса покрывает это.

Пример заполнения:

skip_action_validation: false
kinds#

Добавление пользовательских шаблонов для определения типа файла.

Пример заполнения:

kinds:
  - yaml: "**/*.yaml-too"
only_builtins_allow_collections#

Список сторонних коллекций, использование которых разрешено при включенном правиле only_builtins.

Пример заполнения:

only_builtins_allow_collections:
  - example_ns.example_collection
only_builtins_allow_modules#

Список сторонних модулей, использование которых разрешено при включенном правиле only_builtins.

Пример заполнения:

only_builtins_allow_modules:
  - example_module
task_name_prefix#

Определение префикса, который будет добавлен к названиям задач.

Пример заполнения:

task_name_prefix: "{stem} | "
max_block_depth#

Ограничение максимальной вложенности блоков.

Пример заполнения:

max_block_depth: 20
supported_ansible_also#

Добавление поддержки для версий Ansible, которые могут быть не указаны как поддерживаемые по умолчанию.

Пример заполнения:

supported_ansible_also:
  - "2.14"
Содержание