I can think a few cases where being able to control local role folder names would make things cleaner. For example: referencing repos with the same name in the end, too long or obscure repo names, etc. None of this is a blocker that would stop us from using this feature. I am looking forward to having this in the main branch and in a official release.
On Thursday, August 14, 2014 3:10:29 PM UTC+3, Michael DeHaan wrote: > > " would just add one more requirement - being able to overwrite the > role-name and rely on the git repo name exclusively. Idea for syntax if you > want to keep the *role_name/url, role_version* format:" > > While interesting, we don't want to do this because we already have > ",version" used for describing roles in a way that is not specific. > Further, I don't think those URLs technically support comments in the case > of ssh://, so that seems like something we'd want to avoid. > > We can go with git+https://url,version > > I'm happy with that. > > > > > On Thu, Aug 14, 2014 at 12:17 AM, Ivaylo Bratoev <[email protected] > <javascript:>> wrote: > >> Hi guys, >> >> I am currently investigating different options for managing roles and >> looking forward to having this in Ansible itself. My requirements are >> similar - having roles shared (and versioned) in private git repos, >> referenced from playbooks in other repos. >> The solution you are discussing here sounds like in the right direction. >> I would just add one more requirement - being able to overwrite the >> role-name and rely on the git repo name exclusively. Idea for syntax if you >> want to keep the *role_name/url, role_version* format: >> git+https://git.acme.com/ansible/role-logstash.git#alias=logstash >> >> This would reference the role from the private repo but use the name >> 'logstash' instead of 'role-logstash'. >> >> If you are OK to change the format to *role_name, scm, url *the syntax >> suggested by Sam would work well for us: >> logstash,git,https://git.acme.com/ansible/role-logstash.git >> >> Ivo >> >> >> On Thursday, August 14, 2014 3:37:03 AM UTC+3, Will Thames wrote: >>> >>> I'm happy enough with this approach but how do we apply that to role >>> dependencies. >>> >>> In my git test role I provide a git dependency: >>> https://bitbucket.org/willthames/git-ansible-galaxy/src/ >>> 1e58ef87f234926caaf5e6b1f2c5378d90f476b1/meta/main.yml?at=master >>> >>> This works with the ansible-galaxy in the pull request but would not as >>> it stands without some form of scm detection. >>> >>> On reflection, I think I'd be happiest with the scm+url suggestion - >>> this would eliminate the need for scm detection and keep the role_name/url, >>> role_version format of the rolesfile >>> role_name would continue to be derived from the repo name. >>> >>> From Sam's example, this would then look more like this (not 100% happy >>> with git+git but it's nicer than handling the special case). >>> >>> # Custom roles using various protocols >>> git+ssh://[email protected]:ansible/role-disa-stig-rhel6.git,1.0 >>> git+https://git.acme.com/ansible/role-kibana.git >>> git+git://[email protected]:ansible/role-logstash.git >>> >>> This would end up with roles called e.g. role-logstash, which might not >>> be what you want, but I would prefer to keep the rolesfile simple. >>> >>> Will >>> >>> On Thursday, August 14, 2014 12:59:43 AM UTC+10, Michael DeHaan wrote: >>>> >>>> +1 >>>> >>>> >>>> >>>> On Wed, Aug 13, 2014 at 10:57 AM, Sam Doran <[email protected]> wrote: >>>> >>>>> I like your syntax suggestion. That seems to fit more with the ansible >>>>> project. I agree that specifying the protocol would be a good idea. >>>>> >>>>> Here's what it might look like: >>>>> >>>>> # Galaxy roles >>>>> adham.helal.authentication >>>>> agios.nginx-unicorn,1.3 >>>>> >>>>> # Custom roles using various protocols >>>>> disa-stig-rhel6,git,ssh://[email protected]:ansible/role- >>>>> disa-stig-rhel6.git,1.0 >>>>> kibana,git,https://git.acme.com:ansible/role-kibana.git >>>>> logstash,git,git://[email protected]:ansible/role-logstash.git >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ansible Project" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/ansible-project/2946b30e-e772-44af-9592- >>>>> f0fec3f8da30%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ansible-project/2946b30e-e772-44af-9592-f0fec3f8da30%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/112b3ddf-57b3-4405-a02a-8f08c62a88d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
