Ansible troubleshooting - Error 601: literal-compare
How to Solve the Ansible Error 601 literal-compare Don’t Compare to Literal True/False
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
 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
 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
Here’s an example of what might trigger this error:
--- - name: Ensure production environment is configured hosts: all tasks: - name: Ensure a task runs only in the production environment ansible.builtin.debug: msg: "This is a production task" when: production == True
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
WARNING Listing 1 violation(s) that are fatal literal-compare: Don't compare to literal True/False. 601.yml:5 Task/Handler: Ensure a task runs only in the production environment Read documentation for instructions on how to ignore specific rule violations. Rule Violation Summary count tag profile rule associated tags 1 literal-compare basic idiom Failed: 1 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'min'.
The Best Resources For Ansible
- CYBER DEALS at The Linux Foundation! Up to 65% off, and a FREE GIFT with EVERY PURCHASE! Limited Time, Don't Delay!
- Udemy: Learn Ansible Automation in 250+examples & practical lessons: Learn Ansible with some real-life examples of how to use the most common modules and Ansible Playbook
- Ansible by Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
- Ansible Cookbook: A Comprehensive Guide to Unleashing the Power of Ansible via Best Practices, Troubleshooting, and Linting Rules with Luca Berton
- Ansible For Windows By Examples: 50+ Automation Examples For Windows System Administrator And DevOps
- Ansible For Linux by Examples: 100+ Automation Examples For Linux System Administrator and DevOps
- Ansible Linux Filesystem By Examples: 40+ Automation Examples on Linux File and Directory Operation for Modern IT Infrastructure
- Ansible For Security by Examples: 100+ Automation Examples to Automate Security and Verify Compliance for IT Modern Infrastructure
- Ansible Tips and Tricks: 10+ Ansible Examples to Save Time and Automate More Tasks
- Ansible Linux Users & Groups By Examples: 20+ Automation Examples on Linux Users and Groups Operation for Modern IT Infrastructure
- Ansible For PostgreSQL by Examples: 10+ Examples To Automate Your PostgreSQL database
- Ansible For Amazon Web Services AWS By Examples: 10+ Examples To Automate Your AWS Modern Infrastructure
- Ansible Automation Platform By Example: A step-by-step guide for the most common user scenarios
Solving the Error
To resolve the
 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
False. In most cases, you can simplify your condition like this:
--- - name: Ensure production environment is configured hosts: all tasks: - name: Ensure a task runs only in the production environment ansible.builtin.debug: msg: "This is a production task" when: production
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.
 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.
Learn the Ansible automation technology with some real-life examples in my
My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
Want to keep this project going? Please donate