Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend boolean values section in playbooks_variables #1279

Open
skilyazhnev opened this issue Apr 17, 2024 · 3 comments
Open

Extend boolean values section in playbooks_variables #1279

skilyazhnev opened this issue Apr 17, 2024 · 3 comments
Labels
new_contributor This PR is the first contribution by a new community member.

Comments

@skilyazhnev
Copy link

Hello!

The table presents boolean values and their interpretations within Ansible.

.. table::
:class: documentation-table
=============================================================================================== ====================================================================
Valid values Description
=============================================================================================== ====================================================================
``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0`` Truthy values
``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0`` Falsy values
=============================================================================================== ====================================================================

However, the distinction between native boolean values and those interpretable as boolean could be clearer. This lack of distinction might lead users to misunderstand how Ansible processes certain values.

When I look at that table, it's obvious to me that I can run the play, and the "check" task within the play won't execute.
(ansible-core)

- hosts: all
  connection: local
  vars:
    check: 'false'
  tasks:
    - name: check 
      debug:
        msg: "{{ check }}"
      when: check
      delegate_to: localhost

But it will execute because it will be interpreted as True (not an empty string). And I have to use | bool to force work it right.

There is some note about "Native" bool values and intetpritation in test article

- name: "Native Boolean interpretation"
loop:
- yes
- true
- True
- TRUE
- no
- No
- NO
- false
- False
- FALSE
assert:
that:
# Note that while other values may be cast to boolean values, these are the only ones that are natively considered boolean
# Note also that `yes` is the only case-sensitive variant of these values.
- item is boolean

But looks like better to clarify that in Boolean variables section.

To address this, I propose splitting the section into two subsections:

Native Boolean: This subsection would outline values natively recognized as boolean by Ansible, such as yes, true, false, etc.

Interpretable as Bool: Here, we could elaborate on values that may not be natively recognized but can be interpreted as boolean ('false', 'f' etc...), emphasizing the usage of the bool filter for proper conversion.

How do you think?

Tested on

$ ansible --version
ansible [core 2.15.9]
  config file = None
  python version = 3.9.6
  jinja version = 3.1.3
  libyaml = True
@ansible-documentation-bot ansible-documentation-bot bot added needs_triage Needs a first human triage before being processed. new_contributor This PR is the first contribution by a new community member. labels Apr 17, 2024
@ansible-documentation-bot
Copy link
Contributor

Thanks for your Ansible docs contribution! We talk about Ansible documentation on matrix at #docs:ansible.im and on libera IRC at #ansible-docs if you ever want to join us and chat about the docs! We meet there on Tuesdays (see the Ansible calendar) and welcome additions to our weekly agenda items - scroll down to find the upcoming agenda and add a comment to put something new on that agenda.

@oraNod oraNod removed the needs_triage Needs a first human triage before being processed. label Apr 18, 2024
@oraNod
Copy link
Contributor

oraNod commented Apr 18, 2024

Hi @skilyazhnev Thanks for opening this issue! I've used your example and can observe the behaviour you mention. It's interesting and the proposal to split the section seems reasonable to me. There's always room for more nuance in the docs, I find. However I'm also mindful that folks from the core team or some of the super knowledgeable community folks could see things differently and have other recommendations.

The best way to find out is usually a PR. Do you want to make the changes you're suggesting and submit a PR to this repo?

@skilyazhnev
Copy link
Author

@oraNod Sure, I will prepare PR with proposal for that section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new_contributor This PR is the first contribution by a new community member.
Projects
Status: 🏗 In progress
Development

No branches or pull requests

2 participants