Ansible troubleshooting - Error 601: literal-compare

How to Solve the Ansible Error 601 literal-compare Don’t Compare to Literal True/False

October 31, 2023

Access the Complete Video Course and Learn Quick Ansible by 200+ Practical Lessons

#ansible-error #ansible-best-practices #ansible-playbook #ansible-troubleshooting #automation #infrastructure-as-code #ansible-linting #ansible-coding #devops #it-automation

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:

---
- 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 ansible-lint utility:

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

Certifications

The Linux Foundation Linux Performance Tuning - Build a broad toolkit to optimize Linux performance from the kernel up

Coursera Pro - Unlimited access to 7,000+ world-class courses, hands-on projects, and job-ready certificate programs—all included in your subscription

Video Course

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

Printed Book

eBooks

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:

---
- 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.

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.

Subscribe to the YouTube channel, Medium, and Website, X (formerly Twitter) to not miss the next episode of the Ansible Pilot.