Galaxy: Support multiple roles within a single GitHub repo

[chouseknecht]

Tasks

• [x] Modify the Galaxy data model to enable the inclusion of multiple roles within a single GitHub repository.
• [x] Modify the import process to recursively look for roles within an optional roles directory.
• [x] Recurse subdirectories looking for meta/main.yml, as roles may be at the top-level and not in a roles directory.
• [ ] Modify the import process to look for a .galaxy_ignore file. If this file exists at the root of a role directory tree, then the import process will not import the role, nor will it recurse any further into the role.
• [x] On the repository, change github_branch to import_branch.
• [x] Change the existing migration so that every repo receives a default_branch value. It should come from repo.github_branch, but if repo.github_branch not available, get it from the most recent import task.
• [ ] Validate the repository name. Set repository alias in case name contains restricted symbols (e.g. .)

[drybjed]

@chouseknecht: any plans to support repositories where Ansible roles are placed in the ansible/roles/ subdirectory? This doesn't seem to be common, but it might be useful to namespace various Ansible-related code with ansible/playbooks/, ansible/filter_plugins/, etc. to be gathered under one subdirectory in a large monorepo.

[chouseknecht]

@drybjed

Take a look at #245 and https://etherpad.net/p/Galaxy_Metadata

The gist is that we plan to let the author decide how to organize content within a given repository. The only requirement is for the author to provide a manifest file that tells Galaxy where to look for the content, and any dependencies (both internal and external to the repo).

[drybjed]

@chouseknecht An ansible-galaxy.yml sounds like a good idea.

I briefly looked at the linked thread and documents but I haven't found an easy answer to this question:

In DebOps monorepo I have roles located in ansible/roles/ and named like debops.dhcpd, debops.nginx, etc. This naming scheme allows me to specify the debops.nginx role names in the playbooks, and it works the same when roles are currently installed from Ansible Galaxy.

The question is - will you support some kind of naming template, so that my roles won't end up with names like debops.debops.nginx (following <namespace>.<repository>.<role> naming scheme)? In other words, should I rename the roles in the repository from for example ansible/roles/debops.nginx/ to ansible/roles/nginx/? That will break existing playbooks and will make use of the roles only from the repository cumbersome...

I guess the additional namespacing would allow to for example to have debops.common.nginx role on Ansible Galaxy, but how would that translate to the directory name in the repository? Will there be a way to map specific role directories to the names on Ansible Galaxy in the ansible-galaxy.yml file?

[chouseknecht]

@drybjed

The alternate_name exists at the repo level today, and we will continue to support that. There is currently no plan to provide the same at the role level, though we may add it in a future iteration.

The plan is to release these changes in our QA environment, which is public, and you'll be able to test with your roles, and see how things function. Based on feedback, we may determine that an alternate_name is needed either in the repo metadata, or maybe in the role metadata.

[chouseknecht]

Support multiple roles within a single repo

[drybjed]

@chouseknecht Sounds good then. I was planning to write a bunch of scripts to export DebOps roles from the monorepo to separate GitHub repositories, so that they would still be available via Ansible Galaxy, but I might wait for your multi-role implementation instead - it seems much simpler than implementing crutches. Looking forward to it. :-)

[artburkart]

Hi, if I wanted to test this out, where would I find the branch? Does this mean the ansible-galaxy executable can also download multiple different roles from a single repo?

[artburkart]

Have I misunderstood it? Or is this the wrong place to ask such questions?

[drybjed]

@chouseknecht Any progress with this feature? Is there a way to test it before an official release?

[artburkart]

@cutwater, is there any way to track the progress of this issue now that it's been closed? Has the feature been abandoned? Thanks!

[cutwater]

@artburkart Thanks for your interest in this feature. The majority of planned action items are implemented in standalone branch. We're working on a number of changes, that will land on our public QA site first. Please wait for announcement.

[artburkart]

@cutwater - Is that branch visible?

[aminancelot]

Any update on this please? Any ETA?

[drybjed]

@aminancelot The Ansible project converged on Ansible Collections as a way to support multiple Ansible roles in one git repository. I don't think there are plans to implement anything else at present.

The support for Collections in Ansible 2.9 is actually pretty good, I suggest that you switch to it. My project already is available as an Ansible Collection, but that might be an overkill initially; there are more approachable collections available on Galaxy.

[aminancelot]

@drybjed Thank you.