This is now working for the roles file in YAML format. It doesn't work so well for role dependencies - we'd probably need to declare some special variables for that.
At the moment the YAML file format is - src: "git+http://git.example.com/repos/horrible-role-name"; name: "nice-role-name" version: v1.0 You can also use scm: git (or hg) instead of the git+ / hg+ - the end result is the same. For this to work with role dependencies it would need to be obvious what are role_vars and what are settings for installing dependencies (perhaps prepend role_install to distinguish the two? - I haven't implemented this at all, figure I should gather thoughts on requirements first. Something like dependencies: - { role: friendly_role_name, this_is_a_role_variable: x, role_install_src: "git+http://url";, role_install_version: v1.0 } On 17 Aug 2014, at 23:00, Michael DeHaan <[email protected]> wrote: > "I also don't particularly propose rewriting what I've done so far given that > it's backwards compatible" > > This would be fine with me. > > "I would prefer not to support a mixed format roles file - how about if the > filename ends '.yml' or '.yaml' we treat it as yaml, otherwise use the > existing format." > > +1 > > This could be applied on top. > > > > > On Sun, Aug 17, 2014 at 3:21 AM, Will Thames <[email protected]> wrote: > My implementation only uses three fields, in an order that is backward > compatible with the existing roles file, and I'm not sure what the other > proposed fields would be. > > However, I like the YAML idea if only because it would work much more nicely > with the dependencies section of meta/main.yml too. > > I would prefer not to support a mixed format roles file - how about if the > filename ends '.yml' or '.yaml' we treat it as yaml, otherwise use the > existing format. > > I also don't particularly propose rewriting what I've done so far given that > it's backwards compatible - any change would be to support the yaml notation > in addition (which would also be extensible to any of the other proposed > fields I've forgotten about). > > Will > > On 17 Aug 2014, at 00:52, Michael DeHaan <[email protected]> wrote: > >> Positional fields could be a problem, we already have a proposal for like 5 >> of them, and in different cases it's now seaming like they are in different >> orders. I think we need to reset here. If we're proliferating on fields, >> here is what I propose. >> >> * (A) continue to support the existing syntax for the galaxy-username, >> version >> >> * (B) use a list of YAML hashes for the approved syntax, and update the >> documentation >> >> * (C) go down the YAML path if the first non-space character is a "-" >> >> Perhaps it looks roughly like this: >> >> ---- >> >> - repo: git+ssh:// >> role_name: blippy >> version: ... >> >> - galaxy: username.rolename >> recursive: false >> >> - galaxy: username.rolename2 >> version: 1.2.3 >> >> - galaxy: username.rolename_is_terrible >> role_name: save_as_this >> >> ?? >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Aug 15, 2014 at 8:07 AM, Will Thames <[email protected]> wrote: >> Ok, friendly role names now allowed as third field. >> >> Added bonus of installing roles from URLs without SCM (think nexus, >> artefactory or just e.g. direct bitbucket/github/stash download URLs) >> >> Integration tests and unit tests to demonstrate that these improvements seem >> to work as expected. >> >> Will >> >> >> On Friday, August 15, 2014 10:22:44 AM UTC+10, Will Thames wrote: >> Perhaps we could make role name an optional third field - so if you do want >> role_name but not role_version, just leave role_version blank i.e. >> git+http://git.server/bad-role-name,,nice-role-name >> >> The reason for making it the third field is that I don't want to break >> existing roles files and I don't want the parsing for SCM roles to be >> fundamentally different to the galaxy roles. >> >> I don't particularly wish this to block the take-up of this pull request, >> but I'm happy enough to implement it if the above seems a reasonable >> approach. >> >> Will >> >> On Friday, August 15, 2014 3:03:36 AM UTC+10, Ivaylo Bratoev wrote: >> 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]> >> 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.0kibana,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. >> >> 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/af2e9ef3-19e1-4379-a6b8-439936841e7d%40googlegroups.com. >> >> 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/0520bf55-0dc0-4a3b-9c27-5d15da78a289%40googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Ansible Project" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe. >> To unsubscribe from this group and all its topics, 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/CA%2BnsWgxP4WCqUf4MbhytOO-A%3DfiTnn8Dtz%2BHUhxJ3RD%2BTNQB5Q%40mail.gmail.com. >> >> 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/B9D82A46-0916-4747-8323-5A9309F12251%40thames.id.au. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/TawjChwaV08/unsubscribe. > To unsubscribe from this group and all its topics, 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/CA%2BnsWgxsMac6wEVHNVHTZimWaZVCR93rX0eO8qdVJgsiEUxznQ%40mail.gmail.com. > 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/4DEBED3F-10A0-401F-B067-749AA58CA13B%40thames.id.au. For more options, visit https://groups.google.com/d/optout.
