… then all the dependent collections and roles would also be installed from GitLab. I’ve tried several permutations in the dependencies key in galaxy.yaml with no luck. Is below - or something like it - supported in galaxy.ymldependencies:?
[WARNING]: Skipping Galaxy server https://galaxy.ansible.com/api/. Got an unexpected error when getting available versions of collection foo.collection-b:
'/api/v3/plugin/ansible/content/published/collections/index/foo/collection-b/versions/'
ERROR! Unexpected Exception, this is probably a bug: '/api/v3/plugin/ansible/content/published/collections/index/foo/collection-b/versions/'
yep that was my first attempt - same result - to me the suspicious part is /api/v3/plugin - GitLab doesn’t support this endpoint to my knowledge. Before cracking open the Ansible code I thought I was see if others had already successfully done this.
I setup something similar with AWX.
Created a repo with with the collection name for example:
test.collection
Created roles folder, plugins and so on.
Then in a other repo with all the awx playbooks named for example:
AWX Playbooks
I have a requirements.yml with the following lines:
Go look for requirements.yml in the collection files
ansible galaxy install -r "path to requirements"
Avoiding steps >=2 is the purpose of dependencies in galaxy.yml except it appears to me that Ansible didn’t envision having dependencies of a collection in gitlab - as listed in galaxy.yml.
Well I think you’re saying it would require us to stand up an in-house Galaxy server which - definitely not opposed to but I was looking for the easy button for now to just host our roles and collections in GitLab…
If your referring to my post, I am not saying you need an in house galaxy server. Im wondering if you have an existing configuration thats messing with how ansible-galaxy is searching for your dependencies
gotcha - I’m running the ansible-galaxy commands in a bare test directory.
ansible --version
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller starting with Ansible 2.12. Current version: 3.7.16 (default, Oct 30 2024,
20:44:12) [GCC 7.3.1 20180712 (Red Hat 7.3.1-17)]. This feature will be removed from ansible-core in version 2.12. Deprecation warnings can be disabled by
setting deprecation_warnings=False in ansible.cfg.
ansible [core 2.11.12]
config file = None
configured module search path = ['/home/redacted/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/redacted/.local/lib/python3.7/site-packages/ansible
ansible collection location = /home/redacted/.ansible/collections:/usr/share/ansible/collections
executable location = /home/redacted/.local/bin/ansible
python version = 3.7.16 (default, Oct 30 2024, 20:44:12) [GCC 7.3.1 20180712 (Red Hat 7.3.1-17)]
jinja version = 3.0.0
libyaml = True
I only learned this recently myself from this forum, but installing collections from a git repository is meant to be a “developer shortcut” per the official documentation: Installing collections — Ansible Community Documentation
As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet. This functionality is meant as a minimal shortcut for developers of content as previously described, and git repositories may not support the full set of features from the ansible-galaxy CLI.
So it sorta occupies this vague space of “you can do it, but the better option would be to publish it somewhere”. Just food for thought if you are looking at setting up an on-prem Galaxy mirror (not a bad idea given the public Ansible galaxy has gone down twice this year).
Sure thing. When I did use a private git server, we did used https with anonymous browsing enabled on the repo initially. Later, when we switched to ssh only, we needed to add the git servers public key to known hosts and setup an ssh key on the ansible controller so it could access the repo. It did work though
One of those could be the issue and ansible-galaxy is just being quiet about it…
Good luck, I hope it works out
Update in case this helps anyone. this GitHub issue post from Oct '23 helped.
The Ansible team released a new Galaxy server. You’d need to use Ansible >=2.13.9 to download content from it.
Turns out a dependent collection of the one I was trying to install itself had deps on amazon.aws and my Ansible version (core 2.11.12) simply could not ansible-galaxy collection install amazon.aws. As soon as I added the ref to the “old” galaxy server to ansible.cfg then ansible-galaxy again started working but it looks like the old galaxy server isn’t 100% at parity with the new in terms of collection versions it maintains but - this seems to be the root cause for my particular situation.