# Inconsistently tagged git repos **URL:** \ **Category:** Collection Development\ **Tags:** tags, github, galaxy-ng\ **Created:** [July 1, 2025, 6:36pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676 "2025-07-01T18:36:45Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![dnmvisser](https://avatars.discourse-cdn.com/v4/letter/d/8e8cbc/32.png) [@dnmvisser](https://forum.ansible.com/u/dnmvisser)\ **Post date:** [July 1, 2025, 6:36pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/1 "2025-07-01T18:36:46Z")
Hii, while [discussing workarounds](https://forum.ansible.com/t/ansible-galaxy-https-galaxy-ansible-com-taking-very-long-to-respond/43406/10?) for issues with [https://galaxy.ansible.com](https://galaxy.ansible.com), I came across some inconsistencies wrt git tags. Collections below [Ansible Collections · GitHub](https://github.com/ansible-collections) seem to randomly tag versions with, or without a `v` prefix. For example, [Releases · ansible-collections/ansible.posix · GitHub](https://github.com/ansible-collections/ansible.posix/releases) tags version with the `v` prefix. While for example [Releases · ansible-collections/ansible.netcommon · GitHub](https://github.com/ansible-collections/ansible.netcommon/releases) tags versions without it. If the version tags where consistent across all collections, then devising a workaround would be simpler as one wouldn’t have to add logic to cater for two possible permutations of the tag. It may just be my OCD but on the other hand it seems like a simple thing (technically, at least) to do… I don’t have a pref for either format, as long as it’s consistent 🙂 For background info, I was hoping to convert a standard requirements file that uses the default Galaxy API: ```yaml collections: - name: amazon.aws source: https://galaxy.ansible.com version: 7.6.1 - name: ansible.netcommon source: https://galaxy.ansible.com version: 5.3.0 - name: ansible.posix source: https://galaxy.ansible.com version: 1.5.4 - name: ansible.utils source: https://galaxy.ansible.com version: 2.12.0 - name: community.aws source: https://galaxy.ansible.com version: 7.2.0 - name: community.crypto source: https://galaxy.ansible.com version: 2.22.0 - name: community.docker source: https://galaxy.ansible.com version: 3.12.1 - name: community.general source: https://galaxy.ansible.com version: 8.6.5 - name: community.postgresql source: https://galaxy.ansible.com version: 3.9.0 - name: amazon.cloud source: https://galaxy.ansible.com version: 0.4.0 ``` To it’s “github equivalent” workaround version, with `yq -ry '{collections:.collections|map("git+https://github.com/ansible-collections/"+.name+","+.version)}'`: ```yaml collections: - git+https://github.com/ansible-collections/amazon.aws,7.6.1 - git+https://github.com/ansible-collections/ansible.netcommon,5.3.0 - git+https://github.com/ansible-collections/ansible.posix,1.5.4 - git+https://github.com/ansible-collections/ansible.utils,2.12.0 - git+https://github.com/ansible-collections/community.aws,7.2.0 - git+https://github.com/ansible-collections/community.crypto,2.22.0 - git+https://github.com/ansible-collections/community.docker,3.12.1 - git+https://github.com/ansible-collections/community.general,8.6.5 - git+https://github.com/ansible-collections/community.postgresql,3.9.0 - git+https://github.com/ansible-collections/amazon.cloud,0.4.0 ``` If it weren’t for the randomly tagged repos… ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [July 1, 2025, 7:38pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/2 "2025-07-01T19:38:31Z")
Not exactly on topic, but related… I’m certainly not recommending this for production, but I personally maintain a galaxy mirror, and it’s basically just a PoC, and has no support statement, and no guarantees, but: Just specify `https://sivel.eng.ansible.com/api/` as the server and there you go. Again this may be down, dead, or some form of non-functional at any point. It’s powered by my application called amanda which can be found at: > **[GitHub - sivel/amanda: A simple web application, to mimic the v3 API...](https://github.com/sivel/amanda)** > > A simple web application, to mimic the v3 API endpoints for Ansible Galaxy Collections, with no database, just a directory with artifacts The above could easily be used in CI, along with CI caching, to serve via amanda when a cache exists, or fetch from galaxy as needed. I even wrote a public example for CI as well that cached the galaxy install directory: [ansible-collection-test/.github/workflows/ci.yml at devel · sivel/ansible-collection-test · GitHub](https://github.com/sivel/ansible-collection-test/blob/devel/.github/workflows/ci.yml) Although, I will say that collections and roles should really _not_ be downloaded and installed repeatedly. My recommendation is, and always has been, that they should be vendored into your project. And I’m not even talking about git submodules, I mean, just install and commit them into your repo. This is also a good use case for execution environments, which would have the collections pre-installed. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [July 1, 2025, 8:06pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/3 "2025-07-01T20:06:20Z")
> [@dnmvisser](#): > > For example, [Releases · ansible-collections/ansible.posix · GitHub](https://github.com/ansible-collections/ansible.posix/releases) tags version with the `v` prefix. While for example [Releases · ansible-collections/ansible.netcommon · GitHub](https://github.com/ansible-collections/ansible.netcommon/releases) tags versions without it. I think you confused the two collections, ansible.posix doesn’t use the `v` prefix, while ansible.netcommon does. Also interestingly, ansible.netcommon didn’t always do that. It only started doing that from 5.1.2 on; 5.1.1 and before don’t use the `v` prefix. I don’t know why some collections started adding the `v` prefix (some probably did it since their inception though, and some of these might even be around since before the Ansible collection split - i.e. spring 2020, when ansible/ansible was split up and a large number of new collections was created). I guess one reason is that GitHub officially recommends that (you can see a message “It’s common practice to prefix your version names with the letter `v`.” if you click on “Draft a new release”). ---
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [July 1, 2025, 8:17pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/4 "2025-07-01T20:17:54Z")
It’s due to the publishing jobs on Zuul. In the past when done manually I tagged the Windows collections with vx.y.z but when integrating Zuul the tag pattern it uses to detect when to publish a release uses something like `\d+\.\d+\.\d+` so we needed to remove the prefix. It kills me everytime I go to publish a new version to drop the prefix but trying to setup automated publishing on AH/Galaxy is painful enough that I just stick with Zuul for now. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [July 1, 2025, 8:54pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/5 "2025-07-01T20:54:42Z")
Out of curiosity: why do you want to use that prefix? ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [July 1, 2025, 8:56pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/6 "2025-07-01T20:56:29Z")
(The regex in question is here btw: [zuul-config/zuul.d/pipelines.yaml at c5a95f9fcb0be7963c55e24bdfdb3f0a5c58cb5a · ansible/zuul-config · GitHub](https://github.com/ansible/zuul-config/blob/c5a95f9fcb0be7963c55e24bdfdb3f0a5c58cb5a/zuul.d/pipelines.yaml#L158) The one for pre-releases is a bit further up.) ---
**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\ **Post date:** [July 1, 2025, 9:57pm UTC](https://forum.ansible.com/t/inconsistently-tagged-git-repos/43676/7 "2025-07-01T21:57:02Z")
> Out of curiosity: why do you want to use that prefix? Just what I’ve done in the past so having my own personal projects use v but not the collections hit that part of the brain that I don’t like. If I really wanted to justify it, it means I can create tags that are not releases and use the prefix to denote the meaning of the tag but that’s a bit of a stretch.