Ansible-Lint Error 601 literal-compare: Fix Boolean Comparisons
By Luca Berton · Published 2024-01-01 · Category: installation
Fix ansible-lint Error 601 literal-compare. Stop comparing to True/False literally and use proper Jinja2 boolean testing in when conditions.
Introduction
Ansible is a powerful and versatile automation tool commonly used for configuring and managing servers and infrastructure. It allows you to define your infrastructure as code, making it easier to maintain and scale. However, like any software tool, Ansible has its own set of error messages and warnings, which are essential for troubleshooting and improving your playbooks. One common error message you might encounter is [601] Don't compare to literal True/False. In this article, we'll explore what this error means and how to solve it.
Understanding the Error The [601] Don't compare to literal True/False error is raised by Ansible's built-in linting mechanism, which helps identify potential issues and best practices in your playbooks. This particular error message suggests that you are using a redundant comparison in your playbook, specifically when comparing a variable to True or False.
Here’s an example of what might trigger this error:
In the above example, Ansible is flagging the line when: production == True as problematic. While it's technically correct to compare the production variable to True, Ansible suggests a cleaner and more concise way to express the same condition.
We can test the playbook using the ansible-lint utility:
Solving the Error
To resolve the [601] Don't compare to literal True/False error, follow Ansible's recommended best practice, which is to directly reference the variable without a comparison to True or False. In most cases, you can simplify your condition like this:
The updated code snippet is functionally equivalent to the previous one but cleaner and more concise by simply using when: production, you are already checking if the production variable evaluates to True. If production is True, the task will execute, and if it's False, the task will be skipped, which is the desired behavior.
Why It Matters Using when: production instead of when: production == True not only makes your playbook more readable but also follows Ansible's best practices for playbook development. This best practice is important for several reasons: Readability: It improves the clarity of your code by eliminating unnecessary comparisons. When someone else reviews your playbook, they can quickly understand the intended behavior. Consistency: Following best practices ensures consistency across your playbooks, making it easier to maintain and troubleshoot them. Reduced Risk of Errors: By simplifying your code, you reduce the risk of introducing errors during development or maintenance. Performance: While the performance impact of such a comparison is negligible, following best practices generally leads to more efficient code.
Conclusion The [601] Don't compare to literal True/False error in Ansible is a valuable reminder to follow best practices and write clean, readable code. By using when: production instead of when: production == True, you not only resolve the error but also make your playbooks more concise and easier to work with. As you continue developing your Ansible playbooks, watch for similar linting messages and embrace best practices to streamline your automation tasks.
The Error
The Fix
More Examples
String "true" Gotcha
Complex Conditions
In Practice
Suppress Rule
FAQ
Why is this a problem?
It's redundant and error-prone. when: var == True can fail if var is the string "true" instead of boolean true. Direct boolean checks are safer.
What about None/null checks?
What about numeric comparisons?
Numeric comparisons are fine — this rule only applies to True/False literals:
The Error
Quick Fix
More Examples
String vs Boolean
Comparing to None/Undefined
Complex Conditions
Ansible Test Expressions
Configure the Rule
FAQ
Why is literal comparison bad?
It's redundant — when: x == True is the same as when: x but harder to read. It can also cause bugs when x is a truthy string instead of a boolean.
What about comparing to specific values?
Comparing to specific values like "production" or 200 is fine — the rule only flags True, False, and None literals.
Does this affect functionality?
Usually no — x == True and x behave the same for booleans. But for strings like "yes", x == True fails while x | bool works correctly.
Related Articles • Ansible when Conditional Guide • Ansible Handlers Guide
Category: installation