chore(deps): bump the ansible group with 2 updates#79
Conversation
Updates the requirements on [ansible](https://github.com/ansible-community/ansible-build-data) and [ansible-core](https://github.com/ansible/ansible) to permit the latest version. Updates `ansible` to 14.0.0 - [Changelog](https://github.com/ansible-community/ansible-build-data/blob/main/docs/release-process.md) - [Commits](ansible-community/ansible-build-data@13.6.0...14.0.0) Updates `ansible-core` to 2.21.0 - [Release notes](https://github.com/ansible/ansible/releases) - [Commits](ansible/ansible@v2.20.5...v2.21.0) --- updated-dependencies: - dependency-name: ansible dependency-version: 14.0.0 dependency-type: direct:production dependency-group: ansible - dependency-name: ansible-core dependency-version: 2.21.0 dependency-type: direct:production dependency-group: ansible ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
📝 WalkthroughWalkthroughUpdated ChangesAnsible Dependency Upgrade
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@requirements.txt`:
- Around line 4-5: Update requirements.txt and CI to ensure the
Ansible/ansible-core bump is consistent: keep ansible>=14.0.0,<15.0.0 and
explicitly pin ansible-core to a compatible spec (ansible-core==2.21.* or
>=2.21.0,<2.22.0) so the resolver can't pick an incompatible core; update the
test-runner Dockerfile constraint that currently reads ansible>=8.0.0 to match
this new range to avoid CI vs local version skew; run the full
playbook/collection test matrix and validate behavior around COLLECTI
ONS_ON_ANSIBLE_VERSION_MISMATCH and ansible-galaxy requires_ansible handling and
confirm no security advisories affect 14.0.0/2.21.0 in your threat model.
- Line 4: Align Ansible version constraints across test images and scripts to
match requirements.txt by updating the installs in
tests/dockerfiles/Dockerfile.test-runner, Dockerfile, and simple-test.sh to
either install the exact same spec "ansible>=14.0.0,<15.0.0" or to pip-install
using the shared requirements.txt (e.g., pip install -r requirements.txt) so
test runners use the same Ansible version bounds as production.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b21c2f4b-c932-43ba-a0c2-6f995560e40f
📒 Files selected for processing (1)
requirements.txt
| # Core dependencies | ||
| ansible>=13.6.0,<14.0.0 | ||
| ansible-core>=2.20.5 | ||
| ansible>=14.0.0,<15.0.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Find all ansible version constraints in the repository
echo "=== Searching for ansible version constraints ==="
rg -n -i 'ansible[><=]' --type=yaml --type=dockerfile --type=py --type=sh --type=toml --type=json -g '!*.lock' -g '!*.log'Repository: somethingwithproof/ansible-wordpress-enterprise
Length of output: 194
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Show requirements.txt ansible constraint ==="
if [ -f requirements.txt ]; then
nl -ba requirements.txt | sed -n '1,120p'
else
echo "requirements.txt not found"
fi
echo
echo "=== Inspect tests/dockerfiles/Dockerfile.test-runner around the referenced line ==="
# Find the actual path (it might differ); prefer exact match first
if [ -f tests/dockerfiles/Dockerfile.test-runner ]; then
nl -ba tests/dockerfiles/Dockerfile.test-runner | sed -n '1,120p'
else
echo "tests/dockerfiles/Dockerfile.test-runner not found; locating Dockerfile.test-runner..."
fd -a -t f 'Dockerfile\.test-runner' . || true
fi
echo
echo "=== Search for ansible version constraints across common config/build files ==="
rg -n -i 'ansible\s*(?:[<>=!~]=)\s*' \
--glob 'requirements*.txt' \
--glob '*requirements*' \
--glob '*Dockerfile*' \
--glob '*.yml' --glob '*.yaml' \
--glob '*.toml' \
--glob '*.json' \
--glob '*.py' \
--glob '*.sh' \
--glob '!**/*.lock' --glob '!**/*.log' || true
echo
echo "=== Search for exact ansible pin/specifiers (==, ~=, >=, <=, >, <) ==="
rg -n -i 'ansible\s*(==|~=|>=|<=|>|<)\s*' \
--glob 'requirements*.txt' \
--glob '*Dockerfile*' \
--glob '*.yml' --glob '*.yaml' \
--glob '!**/*.lock' --glob '!**/*.log' || trueRepository: somethingwithproof/ansible-wordpress-enterprise
Length of output: 201
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Show requirements.txt ansible constraint ==="
if [ -f requirements.txt ]; then
# show first 120 lines with line numbers via awk
awk 'NR>=1 && NR<=120 {printf "%4d\t%s\n", NR, $0}' requirements.txt | sed -n '1,120p'
else
echo "requirements.txt not found"
fi
echo
echo "=== Inspect tests/dockerfiles/Dockerfile.test-runner around the referenced line (if present) ==="
if [ -f tests/dockerfiles/Dockerfile.test-runner ]; then
awk 'NR>=1 && NR<=140 {printf "%4d\t%s\n", NR, $0}' tests/dockerfiles/Dockerfile.test-runner | sed -n '1,140p'
else
echo "tests/dockerfiles/Dockerfile.test-runner not found; locating Dockerfile.test-runner..."
fd 'Dockerfile\.test-runner' . -t f -a || true
# If we find something, print first 200 lines for whichever file exists
path="$(fd 'Dockerfile\.test-runner' . -t f -a | head -n 1 || true)"
if [ -n "${path:-}" ] && [ -f "$path" ]; then
echo
echo "=== File: $path (first 200 lines) ==="
awk 'NR>=1 && NR<=200 {printf "%4d\t%s\n", NR, $0}' "$path"
else
echo "No Dockerfile.test-runner found"
fi
fi
echo
echo "=== Search for ansible version constraints across common config/build files ==="
rg -n -i 'ansible\s*(?:[<>=!~]=)\s*' \
--glob 'requirements*.txt' \
--glob '*requirements*' \
--glob '*Dockerfile*' \
--glob '*.yml' --glob '*.yaml' \
--glob '*.toml' \
--glob '*.json' \
--glob '*.py' \
--glob '*.sh' \
--glob '!**/*.lock' --glob '!**/*.log' || true
echo
echo "=== Search for exact ansible specifiers (==, ~=, >=, <=, >, <) ==="
rg -n -i 'ansible\s*(==|~=|>=|<=|>|<)\s*' \
--glob 'requirements*.txt' \
--glob '*Dockerfile*' \
--glob '*.yml' --glob '*.yaml' \
--glob '*.toml' \
--glob '*.json' \
--glob '*.py' \
--glob '*.sh' \
--glob '!**/*.lock' --glob '!**/*.log' || trueRepository: somethingwithproof/ansible-wordpress-enterprise
Length of output: 3307
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Show the file(s) containing ansible>=2.14 ==="
# Print filename + matching line + a few context lines
rg -n -i 'ansible\s*>=\s*2\.14' --glob 'Dockerfile*' --glob '*Dockerfile*' --glob '!**/*.lock' --glob '!**/*.log' .
echo
echo "=== Show the line(s) containing ansible>=8.0.0 ==="
rg -n -i 'ansible\s*>=\s*8\.0\.0' --glob '*Dockerfile*' .
echo
echo
echo "=== Inspect simple-test.sh around line 31 ==="
if [ -f simple-test.sh ]; then
awk 'NR>=1 && NR<=120 {printf "%4d\t%s\n", NR, $0}' simple-test.sh | sed -n '1,120p'
else
echo "simple-test.sh not found at repo root; searching..."
fd 'simple-test\.sh' . -t f -a || true
path="$(fd 'simple-test\.sh' . -t f -a | head -n 1 || true)"
if [ -n "${path:-}" ] && [ -f "$path" ]; then
echo "=== File: $path ==="
awk 'NR>=1 && NR<=160 {printf "%4d\t%s\n", NR, $0}' "$path" | sed -n '1,160p'
fi
fiRepository: somethingwithproof/ansible-wordpress-enterprise
Length of output: 1853
Fix Ansible version skew between requirements.txt and test Docker images/scripts.
Production requires ansible>=14.0.0,<15.0.0, but the test/aux install paths use different constraints:
tests/dockerfiles/Dockerfile.test-runnerinstallsansible>=8.0.0(no<15upper bound)Dockerfileinstallsansible>=2.14simple-test.shinstallsansiblewith no version constraint
This can make tests run against different Ansible behavior than production. Align these constraints to match requirements.txt (or reuse the same requirements spec).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@requirements.txt` at line 4, Align Ansible version constraints across test
images and scripts to match requirements.txt by updating the installs in
tests/dockerfiles/Dockerfile.test-runner, Dockerfile, and simple-test.sh to
either install the exact same spec "ansible>=14.0.0,<15.0.0" or to pip-install
using the shared requirements.txt (e.g., pip install -r requirements.txt) so
test runners use the same Ansible version bounds as production.
| ansible>=14.0.0,<15.0.0 | ||
| ansible-core>=2.21.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify ansible and ansible-core versions exist and check for security issues
echo "=== Checking ansible 14.0.0 ==="
curl -s https://pypi.org/pypi/ansible/json | jq -r '.releases | keys[] | select(startswith("14.0"))' | head -5
echo -e "\n=== Checking ansible-core 2.21.0 ==="
curl -s https://pypi.org/pypi/ansible-core/json | jq -r '.releases | keys[] | select(startswith("2.21"))' | head -5
echo -e "\n=== Checking ansible 14.0.0 dependencies ==="
curl -s https://pypi.org/pypi/ansible/14.0.0/json 2>/dev/null | jq -r '.info.requires_dist[] | select(contains("ansible-core"))' || echo "Version 14.0.0 not found or no ansible-core dependency listed"
echo -e "\n=== Checking for security advisories ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: PIP, package: "ansible") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: PIP, package: "ansible-core") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: somethingwithproof/ansible-wordpress-enterprise
Length of output: 2834
🌐 Web query:
ansible 14.0.0 breaking changes and compatibility with ansible-core 2.21
💡 Result:
Ansible 14.0.0 is explicitly built to be compatible with and dependent upon ansible-core 2.21 [1][2]. The two packages are tightly coupled, meaning Ansible 14.0.0 is intended to be used with the version of ansible-core it ships with (2.21.x) [1]. Breaking Changes and Porting Guidance The primary breaking changes in Ansible 14.0.0 revolve around collection-specific updates and configuration behavior regarding version mismatches [3][4][5]. Key points include: 1. Ansible-Galaxy Version Mismatch Behavior: A significant change affects how ansible-galaxy handles collections that declare a requires_ansible version incompatible with the running ansible-core [4][5]. By default, these collections are now excluded from installation and download [4][5]. To restore previous behavior, you must set COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH to ignore in your ansible.cfg [4][5]. 2. Collection-Specific Breaking Changes: - Community.dns: Support for ansible-core versions prior to 2.17 has been dropped, which also effectively ends support for Python versions older than 3.8 for this collection [6]. It also dropped support for dnspython versions below 2.0.0 [6]. - Community.mysql: All modules and plugins have been removed from this collection and migrated to the ansible.mysql collection [3]. Users must adjust FQCNs (Fully Qualified Collection Names) in their playbooks (e.g., changing community.mysql.mysql_info to ansible.mysql.mysql_info) [3]. - PSRP (Ansible-core): The default for negotiate_service when building the Kerberos Service Principal Name has changed from WSMAN to host to improve Windows compatibility [3]. Users needing the old behavior must explicitly set ansible_psrp_negotiate_service=WSMAN in their host variables [3]. For a comprehensive list of all collection-level changes and deprecations, consult the official Ansible 14 Porting Guide [3]. Because Ansible 14 bundles a curated set of collections, you should review the changelogs of the specific collections you use, as they may contain additional deprecations or removed features [3][6].
Citations:
- 1: https://www.ansiblepilot.com/articles/ansible-14-pre-release-new-features-collections-guide
- 2: https://forum.ansible.com/t/release-announcement-ansible-community-package-14-0-0b1-pre-release/45833
- 3: https://docs.ansible.com/projects/ansible/latest/porting_guides/porting_guide_14.html
- 4: https://github.com/ansible-community/ansible-build-data/blob/14.0.0a1/14/CHANGELOG-v14.md
- 5: https://github.com/ansible-community/ansible-build-data/blob/main/14/CHANGELOG-v14.md
- 6: https://github.com/ansible-community/ansible-build-data/blob/14.0.0a4/14/CHANGELOG-v14.md
Ensure Ansible 14/ansible-core 2.21 bump is consistent and handle Ansible 14 porting changes
ansible==14.0.0declaresansible-core~=2.21.0, soansible>=14.0.0,<15.0.0withansible-core>=2.21.0is internally compatible.- Still review Ansible 14 breaking/behavior changes (e.g.,
ansible-galaxyhandling ofrequires_ansiblemismatches vsCOLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH) and confirm your usage/playbooks/collections behave as expected. - The security advisories surfaced for
ansible/ansible-coreappear to target older vulnerable ranges, so this bump should be addressing them—but confirm none apply specifically to14.0.0/2.21.0in your threat model. - Check the test-runner Dockerfile constraint (
ansible>=8.0.0) to avoid version skew between CI andrequirements.txt.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@requirements.txt` around lines 4 - 5, Update requirements.txt and CI to
ensure the Ansible/ansible-core bump is consistent: keep ansible>=14.0.0,<15.0.0
and explicitly pin ansible-core to a compatible spec (ansible-core==2.21.* or
>=2.21.0,<2.22.0) so the resolver can't pick an incompatible core; update the
test-runner Dockerfile constraint that currently reads ansible>=8.0.0 to match
this new range to avoid CI vs local version skew; run the full
playbook/collection test matrix and validate behavior around COLLECTI
ONS_ON_ANSIBLE_VERSION_MISMATCH and ansible-galaxy requires_ansible handling and
confirm no security advisories affect 14.0.0/2.21.0 in your threat model.
Updates the requirements on ansible and ansible-core to permit the latest version.
Updates
ansibleto 14.0.0Commits
7ec68faRelease Ansible 14.0.0 (#697)79c7241Schedule cyberark.pas for removal from Ansible 15 (#694)413d77bSpecify collection-directory for graphiant.nas (take 2) (#693)5fd3dfcSpecify collection-directory for graphiant.nas (#692)5629d13Ansible 14.0.0rc1: Dependencies, changelog and porting guide (#691)3be0a6cAnsible 14: Include community.mysql 5.x (#690)23e2edeRestore community.mysql redirect_replacement_major_version to 14 (#688)2855fe3Ansible 14.0.0b1: Dependencies, changelog and porting guide (#687)13e93a5Ansible 14: restrict community.mysql to < 5.0.0 (#686)9d58612ci: add ignore-version-regressions option for release playbook and adjust rel...Updates
ansible-coreto 2.21.0Release notes
Sourced from ansible-core's releases.
Commits
98ab81fNew release v2.21.0 (#86992)62a1c11Update Ansible release version to v2.21.0rc1.post0. (#86912)a5f3424New release v2.21.0rc1 (#86911)30457c7[stable-2.21] git: fix track_submodules using hardcoded master branch (#86692...887be29Update Ansible release version to v2.21.0b3.post0. (#86878)f277916New release v2.21.0b3 (#86877)6272e9dAddINJECT_INVOCATIONconfig (#86771) (#86865)57b7d9dAdd WORKER_SESSION_ISOLATION config for TTY sharing (#86762) (#86864)aa4179cDisable ansible-test azure cloud self-test (#86866) (#86870)da34f51Fix ansible-test remote aliases for new-style args (#86844) (#86845)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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsSummary by CodeRabbit