Ansible troubleshooting - Error 104: Deprecated Bare Vars

Introduction

Ansible, the popular open-source automation platform, provides a straightforward and efficient way to automate tasks, manage configurations, and orchestrate processes. However, as with any tool, there are best practices to follow and potential pitfalls to avoid. In this article, we will delve into Ansible Error 104, “Deprecated Bare Vars”, which is a rule in Ansible-Lint designed to identify potentially confusing expressions where it’s unclear whether a variable or string should be used. We will explore this error, understand its implications, and learn how to write clean, maintainable Ansible code that adheres to best practices.

See also: Ansible troubleshooting - Error 102: No Jinja2 in 'when' Conditions

The Problem: Deprecated Bare Vars

Ansible Error 104, known as “Deprecated Bare Vars”, is a valuable rule designed to maintain code clarity and consistency. This rule points out situations where it is unclear whether a given expression should be interpreted as a variable or a string. To address this, Ansible encourages users to either use the full variable syntax or convert the expression into a list of strings.

Problematic Code Example:

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items: foo # <-- deprecated-bare-vars

In the code above, the variable “foo” is being referenced without any clear indication of whether it’s a variable or a string. This ambiguity can lead to confusion and potential issues down the line.

Output:

WARNING  Listing 2 violation(s) that are fatal
schema[playbook]: $[0].tasks[0].with_items 'production' does not match '^\\{[\\{%](.|[\r\n])*[\\}%]\\}$'
104.yml:1  Returned errors will not include exact line numbers, but they will mention
the schema name being used as a tag, like ``schema[playbook]``,
``schema[tasks]``.
This rule is not skippable and stops further processing of the file.
If incorrect schema was picked, you might want to either:
* move the file to standard location, so its file is detected correctly.
* use ``kinds:`` option in linter config to help it pick correct file type.
deprecated-bare-vars: Possible bare variable 'production' used in a 'with_items' loop. You should use the full variable syntax ('{{ production }}') or convert it to a list if that is not really a variable.
104.yml:7 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 deprecated-bare-vars basic   deprecations         
     1 schema[playbook]     basic   core
Failed: 2 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'min'.

Correcting the Code

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items:
    - foo

In this case, we’ve made it clear that “foo” is not a variable, but rather a string value. By providing it in a list format, we remove the ambiguity. If “foo” is indeed a variable:

---
- ansible.builtin.debug:
    msg: "{{ item }}"
  with_items: "{{ foo }}"

Here, we’ve used the full variable syntax by enclosing “foo” in double curly braces {{ foo }}. This unequivocally indicates that “foo” is a variable that should be interpreted as such.

See also: Ansible troubleshooting - Error 105: Deprecated Module Usage

Benefits of Clarifying Expressions

Conclusion

Ansible Error 104, “Deprecated Bare Vars”, serves as a valuable reminder to maintain code clarity and consistency in Ansible playbooks. By providing explicit indications of whether an expression is a variable or a string, you can improve code readability, maintainability, and debugging. In the world of automation and orchestration, clean and understandable code is essential for achieving reliable and efficient results. So, when working with Ansible, remember to make your intentions clear and your code unambiguous.

See also: Ansible troubleshooting - Error 106: Role Name Rules

Related Articles