Inspired by a great audience question at our last meetup… check out the Level Up team’s latest blog post: “Express Your Team’s Infrastructure Code Standards Using Custom ansible-lint Rules“.
A few highlights:
- “The Ansible by Red Hat project currently maintains ansible-lint as a way to communicate its summary view of global default best practices and “syntactic sugar” to the wider community”
- “Granted, your team may not always end up agreeing with ansible-lint’s default worldview. Which is totally fine. There are both runtime (the -x flag) and config file options available to exclude rules either by the rule ID or any matching tag. If and when you encounter false-positives, or have other reasons to want to reduce warning “noise” in your linting efforts, you can simply share your ansible-lint config files somewhere like GitHub that the rest of your team can consume as well.”
- “ansible-lint becomes super-charged when you combine its default rules with custom rules created by you and your team”