Galaxy collection files do not match github

Hello! This is my first post (beyond the welcome thread), so please forgive me if I have misunderstood the posting requirements.

I am having a file content mismatch with the community.zabbix collection when installed using ansible-galaxy. Although I’d like to solve that problem, I think I may have a fundamental misunderstanding of how using collections installed through ansible-galaxy are supposed to work.

Background: I have been using the community.zabbix collection successfully for almost 1 year and I was under the impression that collection versions were being updated correctly when running commands like:

ansible-galaxy collection install community.zabbix
ansible-galaxy collection install --force community.zabbix 

I believe this to be true because of this:

ansible-galaxy collection verify community.zabbix
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/community-zabbix-4.1.1.tar.gz to /home/<redacted>/.ansible/tmp/ansible-local-49141vdynf_mk/tmpgwem86b_/community-zabbix-4.1.1-higlwv4m
Verifying 'community.zabbix:4.1.1'.
Installed collection found at '/home/<redacted>/.ansible/collections/ansible_collections/community/zabbix'
MANIFEST.json hash: 777ef16a9b66811d4a63ddc71c44fb4ef71c0537e33fcc2dfb6bbb8acc83d452
Successfully verified that checksums for 'community.zabbix:4.1.1' match the remote collection.

I recently upgraded to ansible core 2.19.3, and when running a playbook that uses the community.zabbix role I received an error related to broken conditionals. I started investigating and found the culprit, and solved the issue.

ansible [core 2.19.3]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/<redacted>/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/<redacted>/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.12.3 (main, Aug 14 2025, 17:47:21) [GCC 13.3.0] (/usr/bin/python3)
  jinja version = 3.1.2
  pyyaml version = 6.0.1 (with libyaml v0.2.5)

Here’s the rub! When I compared the file causing the broken conditional error to the file hosted on the community.zabbix github, the file on github differed from the file on my local machine. Given the verify command stated the local files matched what was on galaxy and even completely removed the local version and reinstalled with the same ‘broken conditional’ error and file mismatch, I’m unsure what to check next.

For context, here is the exact mismatch I found:

~/.ansible/collections/ansible_collections/community/zabbix/roles/zabbix_repo/tasks/Debian.yml

line 86:

- name: "Debian | Configuring the weight for APT" 
  ansible.builtin.copy:
    dest: "/etc/apt/preferences.d/{{ zabbix_repo_package }}"
    content: |
      Package: {{ zabbix_repo_package }}
      Pin: origin repo.zabbix.com
      Pin-Priority: {{ zabbix_repo_apt_priority }}
    owner: root
    mode: "0644"
  when:
    - zabbix_repo_package is defined
    - zabbix_repo_package ##[THIS IS THE PROBLEM LINE]##
  become: true
  tags:
    - install

When I check the github repository, it appears that this line is different, and what I would expect to avoid the broken conditional error:

##https://github.com/ansible-collections/community.zabbix/blob/main/roles/zabbix_repo/tasks/Debian.yml
- name: "Debian | Configuring the weight for APT"
  ansible.builtin.copy:
    dest: "/etc/apt/preferences.d/{{ zabbix_repo_package }}"
    content: |
      Package: {{ zabbix_repo_package }}
      Pin: origin repo.zabbix.com
      Pin-Priority: {{ zabbix_repo_apt_priority }}
    owner: root
    mode: "0644"
  when:
    - zabbix_repo_package is defined
    - zabbix_repo_package | length > 0 ##[WHY IS THIS MISSING FROM LOCAL FILES?]##
  become: true
  tags:
    - install

I’m at a loss as to how to troubleshoot the differences and solve the root cause. Of course, I can manually update the local files, but I’m hoping to learn more about ansible and ansible galaxy instead of a quick fix. If I have left out critical information needed to assist, please let me know what I can provide to help you help me!

Thank you.

community.zabbix 4.1.1 was released on September 3. zabbix_repo: Fix broken conditional by pviffx · Pull Request #1633 · ansible-collections/community.zabbix · GitHub was merged on September 23. Why do you expect a change that didn’t happen until after the release to be present in the release?

Is there some Ansible equivalent of monkeypatch that would let a user patch around an issue like this without modifying the installed collection file?

  1. Ansible does not care how the collection got installed, as long as it is in a search path of yours. So you can take a copy of a collection’s version (whether released or not) and modify as to your wishes, and store it somewhere where Ansible will find it.

    That’s not exactly monkeypatching though. But it will also work with execution environments: either change the definition to copy some files into the environment at the end of the build process to overwrite files, or create a new image from the built image that has some files modified.

  2. You can install also from git, so in the specific case of this thread you can also install a specific commit from the git repository to get a version that’s already patched. This will also work with EEs.

1 Like

I’ve added comments in the PR about an upcoming release, and more generally in Validate compatibility with ansible-core 2.19 · Issue #1513 · ansible-collections/community.zabbix · GitHub (the issue that was supposed to track ansible-core 2.19 compatibility).

2 Likes

Thanks, @flowerysong. Your response helped me learn more about git, which admittedly, appears to be the root cause of my issue.

To answer your question directly, I was not expecting anything because I did not understand the relationship between galaxy ↔ github, or even github on its own. I’ve added these topics to my short list of things to deep dive.

Thanks for the options @felixfontein! I’ll try this out as I learn more about git.