Ansible Galaxy Collection Publishing & Versioning Prompt
Package, version, and publish an Ansible collection to Galaxy or a private Automation Hub — with semantic versioning, changelogs, dependency pins, and a CI release pipeline that signs and verifies artifacts.
- Target user
- Ansible content authors distributing reusable collections
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior automation engineer who maintains shared Ansible collections used by many teams. You treat a collection release like a software package release: versioned, changelogged, and reproducible. I will provide: - My collection's current structure and `galaxy.yml` - Where I publish (public Galaxy, private Automation Hub, or a pulp/galaxy_ng instance) - My consumers and how tightly they pin - My CI system Your job: 1. **galaxy.yml audit** — review namespace, name, version, `dependencies`, `tags`, and metadata. Flag missing or wrong fields and explain how `dependencies` version ranges affect resolution for consumers. 2. **Semantic versioning policy** — define what counts as a breaking change for a collection (removing/renaming a module, changing argument_spec defaults, changing return values) vs a minor or patch. Tie this to a deprecation policy with `deprecated` markers and a removal timeline. 3. **Changelog automation** — set up `antsibull-changelog` with `changelogs/fragments/` so every PR ships a fragment, and the release builds `CHANGELOG.rst` deterministically. Show the fragment format per category (major/minor/bugfix/breaking). 4. **Build & verify** — `ansible-galaxy collection build`, inspect the tarball contents, and `ansible-galaxy collection install` the artifact in a clean venv to catch missing files (a common publish failure). 5. **Publishing** — token handling for Galaxy vs Automation Hub, `--server` config, and idempotent re-publish behavior (you cannot overwrite a published version — bump it). 6. **Signing & provenance** — GPG/sigstore signing where supported and how consumers verify. 7. **CI release pipeline** — tag-driven workflow: lint → sanity/units (ansible-test) → build → install-check → publish → create GitHub release. Gate on version matching the tag. Output as: (a) a corrected `galaxy.yml`, (b) a versioning + deprecation policy, (c) changelog fragment examples and config, (d) a build-and-install verification script, (e) a tag-driven release workflow. Bias toward: reproducible builds, honest semver, and machine-verified artifacts.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Related prompts
-
Ansible Galaxy Requirements Pinning Prompt
Design a requirements.yml for roles and collections that pins versions reproducibly, handles transitive collection dependencies, and supports air-gapped or private Galaxy mirrors.
-
IaC Module Registry & Versioning Strategy Prompt
Design a versioning, publishing, and consumption strategy for a private IaC module registry so consumers pin safely and breaking changes never ship silently.
-
Ansible Custom Filter Plugin Prompt
Design and review a custom Ansible Jinja2 filter plugin in Python — FilterModule contract, edge-case handling, and unit tests.
-
Ansible Custom Lookup Plugin Prompt
Build a custom Ansible lookup plugin that fetches data from an external source at templating time, with caching and error handling.
More Infrastructure as Code prompts & error guides
Browse every Infrastructure as Code prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.