Ansible 2.8 was released in May 2019 and later in May came to Fedora 30 in package form. So the first tests could be done to see what needed to be done to switch from 2.7 to 2.8 and don’t generate a lot of stopped GitLab CI-jobs due to new warnings and errors. So let start with one warning that needs to be resolved before the 2.12 release and also is given on many third-party roles.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel

The example code above is simple enough to get the warning about CONDITIONAL_BARE_VARS. We could opt for disabling the warning in ansible.cfg and move forward, but as this is technical debt we don’t want to get more and resolve the current debt as quickly as possible.

TASK [role.platform : Enable EPEL repository] *******************************
[DEPRECATION WARNING]: evaluating platform_repo_epel as a bare variable, this 
behaviour will go away and you might need to add |bool to the expression in the
 future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature 
will be removed in version 2.12. Deprecation warnings can be disabled by 
setting deprecation_warnings=False in ansible.cfg.

First we try to resolve this technical debt in the traditional way and making it a Boolean comparison and this stops Ansible from complaining as it is not a bare variable anymore.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel == True

Now Ansible lint starts to give a notification, added in version 4.0.0, as you shouldn’t do a Boolean comparison this was. And while it is technical correct, we also want this linting notification gone to pass the CI-pipeline.

[601] Don't compare to literal True/False
/path/to/ansible/project/roles/platform/tasks/main:6
  when: platform_repo_epel == True

In original message from Ansible there was already a hit on how to resolve this and by adding a Boolean filter both Ansible keeps on running correctly and Ansible lint is also happy.

- name: Enable EPEL repository
  package:
    name: epel-release
    state: present
  when: platform_repo_epel|bool

While these kind of modifications seem non-trivial and a test in your CI-pipeline could easily be set to “allow_failure=true”, but it makes code more readable for yourself and others.

Published by Hans Spaans

Unix & security consultant with a passion for Linux, Solaris, PostgreSQL, Perl and network services, but also a strong believer in open and free source, standards and content.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.