ansible-core 2.21.5 - Maintenance Release and Artifact Verification

ansible-core 2.21.5 is a new tag in the 2.21 series of the ansible/ansible repository. This post covers what the release page actually contains and how to handle it in a pinned pipeline.

The full release notes and downloads are on the GitHub release page.

The release v2.21.5 was published on 5 October 2026 at 15:11 UTC. It is not a prerelease. The GitHub notes are short. They do not list individual fixes. They point to the 2.21 changelog and give the built artifacts with their checksums. That shapes what can be said here, and this post does not invent anything beyond it.

The release notes link to changelogs/CHANGELOG-v2.21.rst at the v2.21.5 tag in the repository. That file is the source of truth for bug fixes, minor changes, and any security entries in this patch. The GitHub release page itself carries no summary of them.

Practical consequence for operators: reading the release page is not enough to decide on an upgrade. Open the changelog, filter to the 2.21.5 section, and check it against the modules, plugins, and callbacks your playbooks use. If you run ansible-test in CI for your own collections, check the same section for sanity test or tooling changes before the bump.

A patch release in a stable series is normally a low risk bump. The notes here give no breaking changes and no migration steps, so there is no upgrade section in this post. Still, run your own test matrix. A green run on 2.21.4 says little about 2.21.5 behavior in your own roles.

Two artifacts are listed, both hosted on PyPI file URLs.

  • Built distribution: ansible_core-2.21.5-py3-none-any.whl, 2457267 bytes.
  • Source distribution: ansible_core-2.21.5.tar.gz, 3395026 bytes.

The wheel tag is py3-none-any. That means a pure Python wheel with no compiled extension and no platform tag. The same file installs on any platform the package supports. For container images and offline mirrors, that keeps the build simple: one wheel, no per architecture variants.

The sdist is about 940 KB larger than the wheel. That is the usual gap, since the source archive carries extra build and test material.

The notes publish a SHA256 for each file:

  • Wheel: 08886f9f3e23d129aa98a01271c4a47833516e1cb7c737a246788cb474f41222
  • Source archive: 65bb3148c58ebb843cd5074004c805f404f152114d98476dd823324616c9c6cb

If you mirror packages into an internal index, compare these values against the files you ingest. A minimal check looks like this:

echo "08886f9f3e23d129aa98a01271c4a47833516e1cb7c737a246788cb474f41222  ansible_core-2.21.5-py3-none-any.whl" | sha256sum -c -

For pinned installs, pip hash checking mode is the natural fit. Put the wheel hash in a requirements file using --hash=sha256:... and install with --require-hashes. That makes a changed artifact fail loudly instead of silently landing in a control node image.

One caveat. These checksums come from the same release page as the links. They detect corruption and mirror drift. They do not give independent proof of origin if the page itself were altered. Treat them as one control among several.

For teams running Ansible against data platforms, the work is small:

  1. Read the 2.21.5 section of the changelog.
  2. Bump the pin in your execution environment or control node image.
  3. Add the wheel hash to the lockfile.
  4. Run the playbook and collection tests you already have.

Nothing in the notes calls for emergency action. Schedule it with the normal patch cadence.