Docs: true/false with boolean values in docsite/rst/playbook_guide (#78958)

docs/docsite/rst/playbook_guide/playbooks_blocks.rst

@@ -41,7 +41,7 @@ All tasks in a block inherit directives applied at the block level. Most of what
       when: ansible_facts['distribution'] == 'CentOS'
       become: true
       become_user: root
-      ignore_errors: yes
+      ignore_errors: true
 
 In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: yes`` ensures that Ansible continues to execute the playbook even if some of the tasks fail.
 
@@ -153,7 +153,7 @@ You can use blocks with ``flush_handlers`` in a rescue task to ensure that all h
         - name: Print a message
           ansible.builtin.debug:
             msg: 'I execute normally'
-          changed_when: yes
+          changed_when: true
           notify: run me even after an error
 
         - name: Force a failure

docs/docsite/rst/playbook_guide/playbooks_checkmode.rst

@@ -37,14 +37,14 @@ For example:
   tasks:
     - name: This task will always make changes to the system
       ansible.builtin.command: /something/to/run --even-in-check-mode
-      check_mode: no
+      check_mode: false
 
     - name: This task will never make changes to the system
       ansible.builtin.lineinfile:
         line: "important config"
         dest: /path/to/myconfig.conf
         state: present
-      check_mode: yes
+      check_mode: true
       register: changes_to_important_config
 
 Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes.
@@ -104,4 +104,4 @@ Because the ``--diff`` option can reveal sensitive information, you can disable
         owner: root
         group: root
         mode: '0600'
-      diff: no
+      diff: false

docs/docsite/rst/playbook_guide/playbooks_conditionals.rst

@@ -29,7 +29,7 @@ The simplest conditional statement applies to a single task. Create the task, th
         ansible.posix.seboolean:
           name: mysql_connect_any
           state: true
-          persistent: yes
+          persistent: true
         when: ansible_selinux.status == "enabled"
         # all variables can be used directly in conditionals without double curly braces
 

docs/docsite/rst/playbook_guide/playbooks_debugger.rst

@@ -138,7 +138,7 @@ After Ansible invokes the debugger, you can use the seven :ref:`debugger command
 
     - hosts: test
       debugger: on_failed
-      gather_facts: no
+      gather_facts: false
       vars:
         var1: value1
       tasks:
@@ -253,7 +253,7 @@ Update args command
 
     - hosts: test
       strategy: debug
-      gather_facts: yes
+      gather_facts: true
       vars:
         pkg_name: not_exist
       tasks:

docs/docsite/rst/playbook_guide/playbooks_error_handling.rst

@@ -20,7 +20,7 @@ By default Ansible stops executing tasks on a host when a task fails on that hos
 
     - name: Do not count this as a failure
       ansible.builtin.command: /bin/false
-      ignore_errors: yes
+      ignore_errors: true
 
 The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors.
 
@@ -37,7 +37,7 @@ You can ignore a task failure due to the host instance being 'UNREACHABLE' with
 
     - name: This executes, fails, and the failure is ignored
       ansible.builtin.command: /bin/true
-      ignore_unreachable: yes
+      ignore_unreachable: true
 
     - name: This executes, fails, and ends the play for this host
       ansible.builtin.command: /bin/true
@@ -47,14 +47,14 @@ And at the playbook level:
 .. code-block:: yaml
 
     - hosts: all
-      ignore_unreachable: yes
+      ignore_unreachable: true
       tasks:
       - name: This executes, fails, and the failure is ignored
         ansible.builtin.command: /bin/true
 
       - name: This executes, fails, and ends the play for this host
         ansible.builtin.command: /bin/true
-        ignore_unreachable: no
+        ignore_unreachable: false
 
 .. _resetting_unreachable:
 

docs/docsite/rst/playbook_guide/playbooks_loops.rst

@@ -239,7 +239,7 @@ You can use Jinja2 expressions to iterate over complex lists. For example, a loo
       community.mysql.mysql_user:
         name: "{{ item[0] }}"
         priv: "{{ item[1] }}.*:ALL"
-        append_privs: yes
+        append_privs: true
         password: "foo"
       loop: "{{ ['alice', 'bob'] | product(['clientdb', 'employeedb', 'providerdb']) | list }}"
 
@@ -448,7 +448,7 @@ Variable                    Description
 ::
 
       loop_control:
-        extended: yes
+        extended: true
 
 .. note:: When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase.
 
@@ -459,8 +459,8 @@ To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set
 ::
 
       loop_control:
-        extended: yes
-        extended_allitems: no
+        extended: true
+        extended_allitems: false
 
 Accessing the name of your loop_var
 -----------------------------------

docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst

@@ -42,7 +42,7 @@ For example, to manage a system service (which requires ``root`` privileges) whe
       service:
         name: httpd
         state: started
-      become: yes
+      become: true
 
 To run a command as the ``apache`` user:
 
@@ -50,7 +50,7 @@ To run a command as the ``apache`` user:
 
     - name: Run a command as the apache user
       command: somecommand
-      become: yes
+      become: true
       become_user: apache
 
 To do something as the ``nobody`` user when the shell is nologin:
@@ -59,7 +59,7 @@ To do something as the ``nobody`` user when the shell is nologin:
 
     - name: Run a command as nobody
       command: somecommand
-      become: yes
+      become: true
       become_method: su
       become_user: nobody
       become_flags: '-s /bin/sh'
@@ -316,7 +316,7 @@ To set ``enable`` mode for a specific task, add ``become`` at the task level:
      arista.eos.eos_facts:
        gather_subset:
          - "!hardware"
-     become: yes
+     become: true
      become_method: enable
 
 To set enable mode for all tasks in a single play, add ``become`` at the play level:
@@ -324,7 +324,7 @@ To set enable mode for all tasks in a single play, add ``become`` at the play le
 .. code-block:: yaml
 
    - hosts: eos-switches
-     become: yes
+     become: true
      become_method: enable
      tasks:
        - name: Gather facts (eos)
@@ -344,7 +344,7 @@ Often you wish for all tasks in all plays to run using privilege mode, that is b
    ansible_connection: ansible.netcommon.network_cli
    ansible_network_os: arista.eos.eos
    ansible_user: myuser
-   ansible_become: yes
+   ansible_become: true
    ansible_become_method: enable
 
 Passwords for enable mode
@@ -374,7 +374,7 @@ Ansible still supports ``enable`` mode with ``connection: local`` for legacy net
            gather_subset:
              - "!hardware"
          provider:
-           authorize: yes
+           authorize: true
            auth_pass: " {{ secret_auth_pass }}"
 
 We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details.
@@ -423,7 +423,7 @@ task:
 
     - Check my user name
       ansible.windows.win_whoami:
-      become: yes
+      become: true
 
 The output will look something similar to the below:
 
@@ -725,9 +725,9 @@ Here are some examples of how to use ``become_flags`` with Windows tasks:
     ansible.windows.win_copy:
       src: \\server\share\data\file.txt
       dest: C:\temp\file.txt
-      remote_src: yes
+      remote_src: true
     vars:
-      ansible_become: yes
+      ansible_become: true
       ansible_become_method: runas
       ansible_become_user: DOMAIN\user
       ansible_become_password: Password01
@@ -735,12 +735,12 @@ Here are some examples of how to use ``become_flags`` with Windows tasks:
 
   - name: run a command under a batch logon
     ansible.windows.win_whoami:
-    become: yes
+    become: true
     become_flags: logon_type=batch
 
   - name: run a command and not load the user profile
     ansible.windows.win_whomai:
-    become: yes
+    become: true
     become_flags: logon_flags=
 
 

docs/docsite/rst/playbook_guide/playbooks_prompts.rst

@@ -19,7 +19,7 @@ Here is a most basic example:
 
         - name: username
           prompt: What is your username?
-          private: no
+          private: false
 
         - name: password
           prompt: What is your password?
@@ -56,9 +56,9 @@ You can hash the entered value so you can use it, for instance, with the user mo
 
      - name: my_password2
        prompt: Enter password2
-       private: yes
+       private: true
        encrypt: sha512_crypt
-       confirm: yes
+       confirm: true
        salt_size: 7
 
 If you have `Passlib <https://passlib.readthedocs.io/en/stable/>`_ installed, you can use any crypt scheme the library supports:
@@ -107,8 +107,8 @@ Some special characters, such as ``{`` and ``%`` can create templating errors. I
    vars_prompt:
      - name: my_password_with_weird_chars
        prompt: Enter password
-       unsafe: yes
-       private: yes
+       unsafe: true
+       private: true
 
 .. seealso::
 

docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst

@@ -324,8 +324,7 @@ role ``meta/argument_specs.yml`` file. All fields are lower-case.
            * Ensure that the default value in the docs matches the default value in the code. The actual
              default for the role variable will always come from ``defaults/main.yml``.
            * The default field must not be listed as part of the description, unless it requires additional information or conditions.
-           * If the option is a boolean value, you can use any of the boolean values recognized by Ansible:
-             (such as true/false or yes/no).  Choose the one that reads better in the context of the option.
+           * If the option is a boolean value, you should use `true/false` if you want to be compatible with `ansible-lint`.
 
         :choices:
 

docs/docsite/rst/playbook_guide/playbooks_tags.rst

@@ -67,7 +67,7 @@ You can apply the same tag to more than one individual task. This example tags s
      ansible.builtin.service:
        name: ntpd
        state: started
-       enabled: yes
+       enabled: true
      tags: ntp
 
    - name: Install NFS utils
@@ -147,7 +147,7 @@ If you want to apply a tag to many, but not all, of the tasks in your play, use
        ansible.builtin.service:
          name: ntpd
          state: started
-         enabled: yes
+         enabled: true
 
    - name: Install NFS utils
      ansible.builtin.yum:
@@ -183,7 +183,7 @@ If all the tasks in a play should get the same tag, you can add the tag at the l
        ansible.builtin.service:
          name: ntpd
          state: started
-         enabled: yes
+         enabled: true
 
    - hosts: fileservers
      tags: filesharing

docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst

@@ -537,7 +537,7 @@ By default, Ansible gathers facts at the beginning of each play. If you do not n
 .. code-block:: yaml
 
     - hosts: whatever
-      gather_facts: no
+      gather_facts: false
 
 Adding custom facts
 -------------------
@@ -615,7 +615,7 @@ By default, fact gathering runs once at the beginning of each play. If you creat
       - name: Create directory for ansible custom facts
         ansible.builtin.file:
           state: directory
-          recurse: yes
+          recurse: true
           path: /etc/ansible/facts.d
 
       - name: Install custom ipmi fact