Why is ansible-lint so slow?

[ssbarnea]

As I seen more than once this question being raised in various groups, I think it does deserve a clear explanation. There is no single reason, some of them are fixable but some of them will always make it be a less than instant linter.

Ansible-lint does just performs a simple formatting verification of the YAML files involves, it does use ansible itself to validate that the code will not choke when run.

• 5.0+, it does run ansible-playbook --syntax-check on each identified playbook. That happens a subprocess and ansible loading is known to be slow to instantiate, it can take 0.6-2s to run even on a minimal playbooks. One major issue is that ansible-playbook does not accept receiving multiple playbooks, as this could have avoided re-instantiation for each playbook. One improvement that we can do here is to run these processes async, another one would be to persuade ansible core team to enable ansible to receive multiple playbooks, and to report issues with each of them. About 90% of execution time is Ansible own code.
• 5.0+ it does run yamllint on each file if yamllint is present (low impact)
• ansible-lint loads each file using two different yaml loaders because it needs features from each of them, for example ruamel.yaml allows it to process comments (needed for noqa feature) and pyyaml does not support that.
• Installing ansible (especially the full blown version) using pip takes considerable amount of time, use of pre-build containers or assuring that the venv is cached does address this issue (pre-commit does that).
• 4.3.6+ if you enable --progressive mode, the linter will likely run twice, as it will also try to identify which rules were already broken before the current commit. That effectively doubles the execution duration, but only when you activate this feature and when you have matches.

Why I cannot run ansible-lint only on modified files?

Validation of any particular Ansible file can be affected by changes made to other files. Less than half of the problems identifiable by the linter can be process by looking at an isolated file.

Due to this there is no such thing as a partial run. Yes, obviously that you can still run it on a single playbook but we do not recommend it.

How slow is really ansible-lint?

Based on my testing, the longest runtime was around 1m 20s on a big repository like zuul-roles, which had >330 files. To me that is fast-enough to always run it locally before uploading a change and wait for the CI/CD results.

[ssbarnea]

Considering it fixed in master, the speed is quite good.

[MarkusTeufelberger]

$ time ansible-lint --help
usage: ansible-lint [-h] [-L] [-f {rich,plain,rst,codeclimate}] [-q] [-p]
                    [--parseable-severity] [--progressive] [-r RULESDIR] [-R]
                    [--show-relpath] [-t TAGS] [-T] [-v] [-x SKIP_LIST]
                    [-w WARN_LIST] [--nocolor] [--force-color]
                    [--exclude EXCLUDE_PATHS] [-c CONFIG_FILE] [--offline]
                    [--version]
                    [lintables [lintables ...]]

positional arguments:
  lintables             One or more files or paths. When missing it will
                        enable auto-detection mode.

optional arguments:
  -h, --help            show this help message and exit
  -L                    list all the rules
  -f {rich,plain,rst,codeclimate}
                        Format used rules output, (default: rich)
  -q                    quieter, although not silent output
  -p                    parseable output in the format of pep8
  --parseable-severity  parseable output including severity of rule
  --progressive         Return success if it detects a reduction in number of
                        violations compared with previous git commit. This
                        feature works only in git repositories.
  -r RULESDIR           Specify custom rule directories. Add -R to keep using
                        embedded rules from /usr/local/lib/python3.6/dist-
                        packages/ansiblelint/rules
  -R                    Keep default rules when using -r
  --show-relpath        Display path relative to CWD
  -t TAGS               only check rules whose id/tags match these values
  -T                    list all the tags
  -v                    Increase verbosity level
  -x SKIP_LIST          only check rules whose id/tags do not match these
                        values
  -w WARN_LIST          only warn about these rules, unless overridden in
                        config file defaults to 'experimental'
  --nocolor             disable colored output, same as NO_COLOR=1
  --force-color         Force colored output, same as FORCE_COLOR=1
  --exclude EXCLUDE_PATHS
                        path to directories or files to skip. This option is
                        repeatable.
  -c CONFIG_FILE        Specify configuration file to use. Defaults to
                        ".ansible-lint"
  --offline             Disable installation of requirements.yml
  --version

real	0m1,281s
user	0m1,175s
sys	0m0,098s

$ time ansible-lint --version
ansible-lint 5.0.0

real	0m1,169s
user	0m1,085s
sys	0m0,087s

It takes over a second of waiting time just to display the help text or the version string. Something seems off here.

[ssbarnea]

@MarkusTeufelberger The delay is caused by Ansible instantiation, as we need to check its version, and ansible is know to have a poor boot time.

Try again with time ansible --version and check the difference ;)

[MarkusTeufelberger]

$ time ansible --version
ansible 2.10.5
  config file = /home/[redacted]  configured module search path = ['/home/[redacted]', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.12 (default, Aug 18 2020, 02:08:22) [GCC 5.4.0 20160609]

real	0m0,894s
user	0m0,839s
sys	0m0,056s

Still takes ~0.2s to display a version string. Guess that's Python... :-/

For comparison, here's another linter written in Python:

$ time yamllint --version
yamllint 1.26.0

real	0m0,097s
user	0m0,088s
sys	0m0,008s

Anyways, if linting then would take just 2 seconds in total I wouldn't be posting here. On a rather small repository here it takes about 45 seconds to lint all playbooks unfortunately, which is far too long to convince my colleagues to use this as a pre-commit hook (so it is moved to the [manual] section and only run on CI - of course they can run it locally if they want to). Due to the difficulties in finding out what to actually lint when a file changes (Playbooks point towards roles but roles/hosts have no idea which playbooks target them so if something changes in a file belonging to a role it isn't clear what else to lint) there is also a lot of extra work being done. Maybe there can be some caching or representation what gets called from where so only relevant files get linted after an analysis step?