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.