CfgMgmtCamp 2026: Content Development and Collection Maintenance

News & Announcements Blog
, , , , , ,
1

CfgMgmtCamp 2026: Content Development and Collection Maintenance

This post is part of a series of talks presented at CfgMgmtCamp 2026. Please see CfgMgmtCamp for all other talks.

Using antsibull-nox to test your Ansible collection

Speaker: Felix Fontein

Slides: Presentation

Video: YouTube

Antsibull-nox is an extension for nox that makes it easy to run various tests and other testing tools for Ansible collections. In this talk, I want to present some background on why I created antsibull-nox, why I chose nox (instead of, say, tox), and demonstrate how you can use antsibull-nox to test your Ansible collections.

Questions

  • Why is using TOML so difficult in Ansible?

Behind The Scene: How We Ship Ansible Network Collections

Speaker: Chetna Agrawal

Slides: Presentation

Video: YouTube

How do you transform dozens of ansible network collections into predictable, “always-green” releases? We will share how the Ansible Networking team standardizes structure, testing, and release hygiene across collections, so users get fewer surprises and faster fixes. We will cover our CI gates (sanity/unit/integration), Galaxy readiness checks, branch strategy, and what “Done” means before publishing.

ansible-docsmith - ultimate tool to document ansible roles

Speaker: Kirill Satarin

Slides: Presentation

Repository: GitHub

Video: YouTube

Maintaining accurate, up-to-date documentation for Ansible roles is a persistent challenge when maintaining ansible roles. ansible-docsmith solves this problem by automating documentation generation from a single source of truth - argument_specs.yml file.

In this talk, we’ll explore ansible-docsmith and how to use it to forget about ever updating the README.md file for the role, but always keeping it up to date.

  • Using argument_specs.yml as the single source of truth for ansible role readme.md file
  • Using ansible-docsmith in CI/CD: automation pipelines and pre-commit hooks, making documentation updates effortless
  • Available customization options in ansible-docsmith: how to use Jinja2 templates to generate readme.md according to your specific documentation standards
  • Compare ansible-docsmith with ansibull-docs - pros and cons, use case scenarios

Debugging Playbooks Made Easy

Speaker: Jure Medvesek

Slides: Presentation

Video: YouTube

The Ansible community lacks official debugging tools. In this session, I’ll present our reference implementation of an Ansible Playbook Debugger that allows you to inspect variables without relying on ‘printf’ debugging.

This debugger is useful in many scenarios, such as:

  • Retrieving structured results from tasks
  • Evaluating Jinja expressions or real variables and facts at runtime
  • Listing Ansible facts
  • Checking actual FQCN used when a short name was used in a playbook

In this session, I’ll showcase practical use cases where this tool has proven valuable, including live demos that highlight how it simplifies development, inspects variables, and improves visibility into your playbooks.

Talk Notes

Use Cases:

  • Retrieve task result structure
  • Evaluating Jinja expressions
  • Listing ansible facts
  • FQCN names
  • Precedence of arguments evaluation

VSCode Plugin - Spotter: VSC Extension - Steampunk Spotter Documentation

Supported Ansible:

  • Version: 2.11-2.18 from any thread
  • Ansible 2.19 must run in main thread

Control flows supported:

  • Breakpoints - stop on custom task
  • Stop on start - stop before gather facts
  • Step - execute till next step
  • Continue - execute to next breakpoint or the end

Additional choices:

  • Stop once per task (strategy) or for every iteration inside loop (task) → debugType attribute

Watch/debug console (only in strategy debugType mode)

What it is not:

  • Action plugin debugger - use python debugger
  • Inventory plugin debugger
  • Filter, test or lookup plugin debugger - user python debugger

Security considerations:

  • Masking secrets - Debugger must have access to ALL variables, even those in ansible-vault. Potential to use data tagging feature introduced in Ansible Core 2.19.

Overriding variable values - not implemented.

Ideas & followups

Potential in newer versions of Ansible Core to use the Data Tagging feature to prevent secrets being exposed during debugging. Tagging variables as sensitive (or equivalent) to prevent exposure during debugging sessions.

Questions

  • Advice for how to use the debugger for writing plugins in an enterprise setting.

    • The debugger can debug everything but modules, recommended using breakpoints during debugging sessions.

  • Is it possible to re-run the task while the debugger is running?

    • No simple way to do that right now. Potential to explore in the future.

Building CI/CD Pipelines for your Ansible code

Speaker: Ottavia Balducci

Slides: Presentation

Repository: GitHub

Video: Talk was not recorded due to technical issues with the display and projector in the room.

Ansible has become indispensable for modern configuration management. Once you start writing Ansible code, the first thing that you should do is to put it under version control. From there, a whole new world of automation possibilities through CI/CD pipelines opens up.

In this session, we will explore how to leverage CI/CD pipelines to supercharge your Ansible repositories. Using GitLab CI/CD as the primary example, we will walk through several real-life scenarios, each illustrated with a live demo. We will start with the simple yet impactful step of adding automatic linting. We will then move on to more advanced use cases such as automatically building collections and execution environments, generating CHANGELOGs with antsibull-changelog, and performing automated testing with Molecule.

Whether you are just starting with Ansible or already managing complex automation frameworks, this talk will offer practical examples and ideas to take your Ansible code management to the next level.

Talk Notes

Due to the nature of Ansible, make sure to think about file/code structure beforehand.

Having your Ansible code in Git opens up the use of CI/CD pipelines.

CI/CD pipelines: execute jobs on git events, usually on a runner. For tests, linting, releases, deployments etc.

GitLab CI/CD:

Use the .gitlab-ci.yml file in your project.
Divided into stages, executed one after another. A stage can contain multiple jobs which can run in parallel.

Git hooks can be use for same purpose and are great but CI/CD pipelines are better :smiley: :

  • More workflows
  • Nice logging
  • Dedicated runners
Ansible Lint

First pipeline when code is in git: lint the code (static analysis): Check for best practices and possible caveats and to enforce standards.

Yamllint - Generic for YAML, ansible-lint also uses yamllint, so no separate yamllint is required.

You can override lint complains on per line basis using # noqa syntax.

Ansible Collections

When code grows, it is a good idea to package the code in a collection:

  • Modular and reusable
  • Easily distributed
  • Clearer context
  • Version controlled
  • Easier to maintain

Ansible Galaxy CLI Tool:

Initialise a collection: ansible-galaxy collection init

Build a collection: ansible-galaxy collection build

Publish a collection on galaxy, private galaxy NG or AAP: ansible-galaxy collection publish

Install a collection: ansible-galaxy install (downloads all requirements + collection)

CI/CD pipeline workflow: Build collection → tarball → saved as artifact → publish to galaxy server or AAP.

Changelogs
  • Provides a clear project history.
  • Easier maintenance and support.
  • Better user trust.

Antsibull-changelog CLI Tool:

Add changelog fragments to each commit: describes what the change does.

antsibull-changelog release → collects all changelog fragments and adds it to CHANGELOG.rst. It also reads inline docs from plugins/modules, so no separate changelog fragment required.

Fragment syntax:

deprecated_features:
  - >-
  ...

breaking_changes:
  - >-
  ...

minor_changes:
  - ...

Run from CI/CD on version bump → generate changelog → push new tag.

Execution Environments
  • Container images for executing Ansible.
  • Created with ansible-builder CLI tool.
  • Customizable with: own collections, python packages, certificates etc.
  • Use with ansible-navigator, AWX or AAP.

Definition in execution-environment.yml: set dependencies, base image, additional build steps.

ansible-builder build –container-runtime docker -t <registry>:<tag>

CI/CD: run builder to build image → push new image to registry.

Molecule
  • Create test infrastructure
  • Run ansible code against it
  • Verify results
  • Test idempotence
  • Destroy test infrastructure

Steps:

  • Init: molecule init scenario my_scenario
  • Create infra: molecule create
  • Run test: molecule converge
  • Test idempotence molecule idempotence
  • Destroy: molecule destroy

Or all in sequence: molecule test

Check out the other sessions at CfgMgmtCamp 2026 using the links below:

Here are links to all the talks on YouTube as well as related forum discussions:

1 Like
CfgMgmtCamp 2026: AI and Automation
CfgMgmtCamp 2026: Community and Contributor Summit
CfgMgmtCamp 2026: IT Architecture
CfgMgmtCamp 2026: Integration and Tooling
CfgMgmtCamp 2026: Ansible Core 2.19
CfgMgmtCamp 2026: Ansible Ecosystem