Inconsistently tagged git repos

Project Discussions Collection Development
, ,
1

Hii, while discussing workarounds for issues with https://galaxy.ansible.com, I came across some inconsistencies wrt git tags. Collections below Ansible Collections · GitHub seem to randomly tag versions with, or without a v prefix.
For example, Releases · ansible-collections/ansible.posix · GitHub tags version with the v prefix. While for example Releases · ansible-collections/ansible.netcommon · GitHub 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 :slight_smile:

For background info, I was hoping to convert a standard requirements file that uses the default Galaxy API:

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)}':

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…

3 Likes
2

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:

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

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.

3

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”).

4

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.

5

Out of curiosity: why do you want to use that prefix?

6

(The regex in question is here btw: zuul-config/zuul.d/pipelines.yaml at c5a95f9fcb0be7963c55e24bdfdb3f0a5c58cb5a · ansible/zuul-config · GitHub The one for pre-releases is a bit further up.)

7

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.