Hi,
Felix suggested I start a dedicated topic after I mentioned this project in the introduction thread, so here it is 
I recently built ansible-static-lint (astl), a Go implementation of the ansible-lint rules that can be decided from the YAML source alone.
The starting observation was fairly simple: a significant part of the latency of ansible-lint comes from starting and loading the Ansible runtime, while many lint rules do not actually need that runtime.
So instead of trying to replace ansible-lint, I separated the two concerns:
- astl handles the static rules where very fast feedback is useful
- ansible-lint remains the reference for syntax checking, collection resolution, schemas,
--fix, and the other runtime-dependent checks
Currently astl implements 38 of the 51 default ansible-lint rules.
On the frozen ansible-lint compatibility corpus, it reproduces 2370 / 2370 findings within its supported scope, including file, line, column and message.
On my test machine:
| ansible-lint | astl | |
|---|---|---|
| 6-line playbook | 2.1 s | 2.5 ms |
| 478 files corpus | 46.8 s | 37 ms |
The comparison is intentionally not presented as equivalent work: ansible-lint also performs runtime-dependent checks that astl deliberately does not. The point is that the static subset becomes cheap enough to run in an editor, pre-commit hook, or on every CI push.
I have also tried to make adoption incremental rather than introducing another configuration:
- existing
.ansible-lintconfiguration skip_list,enable_list,warn_list, profiles# noqa.ansible-lint-ignore(added in v0.2.0 after the first user request)- ansible-lint rule identifiers by default
- GitHub Action and pre-commit support
- SARIF output
GitHub:
The project is still very young, and at this stage what I am most interested in is real Ansible repositories and workflows where this approach breaks down or is simply not useful.
In particular I’d be interested in hearing:
- whether a fast static layer alongside ansible-lint makes sense in your workflow
- which compatibility gaps would prevent you from using it
- and examples of repositories where I should test it