My First Ansible Release

My first ansible package release and reflections on the process.

Intro

This week, the Ansible community package release process was opened up to the community (i.e., non-Hatters) for the first time! This is a pretty big milestone for our community. The Ansible Community Steering Committee made decisions and policies for the Ansible package, but we were never able to handle the releases ourselves — until now. I was the release manager for this week’s Ansible 8.6.0 release and @felixfontein, another community member, took care of Ansible 9.0.0b1. As the maintainer of the downstream Fedora package and co-maintainer of our build tooling, it was great to see the process in action!

Release process overview

Note

The ansible community package contains a set of independent Ansible collections that are curated by the community, and it pulls in ansible-core. Each major version of ansible depends on a specific major version of ansible-core and contains specific major versions of the collections it includes.

The release process involves putting the appropriate collection versions together, downloading the collection artifacts, and combining them into a single Python package with the proper metadata. Along with the package, a combined changelog and porting guide are generated for all of the collections in the package. The porting guide, changelog, and other static data about the specific collection versions included in each ansible release is kept in the ansible-build-data repository.

Hiccups

I also have a newfound appreciation for the work of the Ansible release manager and am already working on process improvement for future releases. The Ansible 8.6.0 release, in particular, was not without hiccups.

We had one upstream collection that had a semantic versioning violation and another collection that published a release with syntactically invalid Python files. The latter issue broke downstream packages even for users who do not utilize the broken plugins. This is unfortunately not the first time collection maintainers have published releases with Python syntax errors. In the end, I pinned the semver-violating collection to an earlier version and had to publish an 8.6.1 hottfix release to fix the other issue.

Testing and QA issues

We generally rely on upstream collections to follow our guidelines and run CI tests before publishing their releases. However, some collections, especially the commercial ones with convoluted internal <-> external repo sync pipelines, do not seem to consistently test releases before publishing them to Ansible Galaxy 😥.

The Steering Committee and Release Management WG are discussing running some basic smoke tests of our own on top of the ansible package. To this end, I submitted a PR to add a basic Python byte-compilation test to the ansible release playbook. This should at least catch the most egregious issues.

We are also discussing running at least a subset of ansible-test sanity’s tests on top of all collections, but that presents its own can of worms. Mainly, running all of the tests for every single collection is very time-consuming and resource intensive. Also, we would need to figure out how to retrieve the collection sources. The Galaxy artifacts are not guaranteed to include all of the files needed to run sanity tests while the content tagged in the upstream Git repository may not match the Galaxy artifact’s content.