build(deps): bump ansible from 11.13.0 to 12.2.0 in /tests

[dependabot]

Bumps ansible from 11.13.0 to 12.2.0.

Commits

• e7be45b Bump actions/setup-python from 5 to 6 (#603)
• 6f16485 Add ravendb.ravendb to Ansible 12 and 13 (#579)
• d567c52 Add 13/ directory (#601)
• 7819537 Ansible 11.10.0: Dependencies, changelog and porting guide (#600)
• 23876d1 Release Ansible 12.0.0 (#599)
• f1fa409 Revert "Restrict purestorage.flashblade to < 1.21.0. (#596)" (#598)
• 7473747 Ansible 12.0.0rc1: Dependencies, changelog and porting guide (#597)
• 6873c9a Restrict purestorage.flashblade to < 1.21.0. (#596)
• 92a4a56 Remove cloud.common from Ansible 12 (#593)
• a1547b5 Fix broken docs. (#594)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[claude]

🔴 Bumping ansible from 11.13.0 to 12.2.0 pulls in ansible-core 2.19.x, but three upper-bound pins in the repo still cap at <2.19.0 and will block every playbook run and collection install. This PR must also bump: playbooks/ansible_version.yml (maximal_ansible_version to 2.20.0), meta/runtime.yml (requires_ansible upper bound to <2.20.0), and the compatibility table in docs/ansible/ansible.md:35.

Extended reasoning...

What breaks

The ansible community package has a fixed mapping to ansible-core:

• ansible 11.x → ansible-core 2.18.x
• ansible 12.x → ansible-core 2.19.x

So installing ansible==12.2.0 (this PR) will install ansible-core 2.19.x at runtime. Three separate upper-bound pins in the repo still cap at <2.19.0, each with a distinct enforcement path:

1. playbooks/ansible_version.yml:8-17 — playbook runtime assertion

vars:
  minimal_ansible_version: 2.18.0
  maximal_ansible_version: 2.19.0
...
- ansible_version.string is version(minimal_ansible_version, ">=")
- ansible_version.string is version(maximal_ansible_version, "<")

This play is imported by playbooks/boilerplate.yml, which is imported by essentially every user-facing entrypoint (cluster.yml, reset.yml, upgrade-cluster.yml, scale.yml, etc.). Every playbook run will abort at startup with: Ansible must be between 2.18.0 and 2.19.0 exclusive - you have 2.19.x.

2. meta/runtime.yml:2 — collection install/load metadata

requires_ansible: ">=2.18.0,<2.19.0"

galaxy.yml declares this repo as the kubernetes_sigs.kubespray collection, and tests/scripts/collection-build-install.sh and contrib/collection.sh actually build and install it via ansible-galaxy collection install. requires_ansible is enforced by ansible-galaxy at install/load time before any playbook runs, with an error like: Collection kubernetes_sigs.kubespray was created with Ansible version >=2.18.0,<2.19.0, and you are running 2.19.x. This is a different failure path from #1 — a different file, different enforcement mechanism, different error message.

3. docs/ansible/ansible.md:35 — compatibility documentation

The supported-version table still reads >=2.18.0, <2.19.0, which would be inconsistent with an ansible-12 pin.

Step-by-step proof

1. User (or CI) runs pip install -r requirements.txt → ansible==12.2.0 installed → ansible-core 2.19.x installed as a transitive dependency.
2. User runs ansible-playbook -i inventory/... cluster.yml.
3. cluster.yml imports playbooks/boilerplate.yml, which imports playbooks/ansible_version.yml.
4. The assert task evaluates ansible_version.string is version("2.19.0", "<") where ansible_version.string == "2.19.x".
5. Assertion fails → playbook aborts with the "must be between 2.18.0 and 2.19.0 exclusive" message. No cluster operation succeeds.

Parallel path for collection users:

1. User runs ansible-galaxy collection install kubernetes_sigs.kubespray (or tests/scripts/collection-build-install.sh).
2. ansible-galaxy reads meta/runtime.yml, sees requires_ansible: ">=2.18.0,<2.19.0", compares against the installed ansible-core 2.19.x.
3. Install/load is rejected. Playbooks are never reached.

Fix

Bump all three upper bounds in lockstep with this requirements.txt change (e.g. to <2.20.0):

• playbooks/ansible_version.yml: maximal_ansible_version: 2.20.0
• meta/runtime.yml: requires_ansible: ">=2.18.0,<2.20.0"
• docs/ansible/ansible.md:35: update table row to >=2.18.0, <2.20.0

Without these, the PR breaks kubespray for every user on every entrypoint (playbook execution and collection install).