That seems reasonable, especially if skipping hg/git if not installed, though I'm guessing that's maybe *not* as easy for ssh:// git?
Just trying to think aloud whether specifying the protocol is a good idea. I'm thinking it might be, and it would save some network activity on long resource lists as well. What about: for basic files: rolename,version # implies galaxy rolename,version,scm,source ?? On Wed, Aug 13, 2014 at 9:29 AM, Will Thames <w...@thames.id.au> wrote: > It tries a git ls-remote and an hg identify and then uses whichever > succeeds. > > Will > On 13/08/2014 11:19 pm, "Michael DeHaan" <mich...@ansible.com> wrote: > >> Yeah this is about what I was thinking? >> >> Can I ask how it determines if something is hg or git:// for a https:// >> URL? >> >> Maybe we need do syntaxes like git+https:// and git+ssh://, etc? >> >> >> >> >> On Wed, Aug 13, 2014 at 8:57 AM, Will Thames <w...@thames.id.au> wrote: >> >>> How does >>> https://github.com/ansible/ansible/pull/8600 >>> look for URL based roles? >>> >>> I think I can make good use of this - I'll have to rethink our workflow >>> but the final result should be better and meet my requirements. Hopefully >>> I'll have a new blog post and I'll mark the old one as deprecated. >>> >>> Will >>> >>> On Wednesday, August 13, 2014 5:04:52 AM UTC+10, Michael DeHaan wrote: >>>> >>>> >>>> >>>> >>>> On Mon, Aug 11, 2014 at 8:31 PM, Will Thames <wi...@thames.id.au> >>>> wrote: >>>> >>>>> I know your thoughts on ansible-lint - that the behaviour should be >>>>> integrated into core. But my pull request to do something along those >>>>> lines >>>>> has been open for 8 months https://github.com/ansible/ >>>>> ansible/pull/5123 >>>>> >>>>> >>>> >>>> I think it's no-secret that we've had a large queue lately. >>>> >>>> A lot of our prioritzation has been around hardening of core >>>> functionality, and also keeping with EC2 and other hoping things moving. >>>> This is still interesting to me just not something our heuristics have >>>> bubbled to the top. >>>> >>>> Part of the problem is having absolutely ridiculous levels of >>>> contribution at this point, which we are thankful for. >>>> >>>> >>>> >>>>> Anyway, to focus on the main points you make. >>>>> >>>>> My understanding is that ansible galaxy role versions matter at >>>>> install time. I guess that means that each playbook installs the roles >>>>> locally. This means that the problem of using one role version for uat and >>>>> one role version for prod is not necessarily solved is it? >>>>> >>>> >>>> playbooks don't actually install the roles, but ansible-galaxy CLI >>>> calls do. >>>> >>>> In the ansible-galaxy requirements file you can in fact say >>>> >>>> username.rolename,v1.00 >>>> username.rolename2,v1.05 >>>> >>>> And if you had them so configured to check out in locations (ideally >>>> using a different role path for each) that would be easy to do. You might >>>> also have an ansible.cfg that selects this rolepath and also adds it to >>>> .gitignore >>>> >>>> One of the things missing though is the ability to (right now) specify >>>> git:// and ssh:// git locations so it doesn't just have to download from >>>> Ansible galaxy proper. >>>> >>>> I think we're also open to new formats for the requirements file if >>>> needed, as long as it can continue to support the old format. >>>> >>>> >>>>> >>>>> I assume there are existing discussions on using repos other than >>>>> github - I'll have to look into this. I'm definitely keen to avoid >>>>> reinventing any wheels if I can. >>>>> >>>>> To be clear, I'm not particularly concerned about the versioning of >>>>> Ansible itself, just that the same playbook can reference different roles. >>>>> >>>>> Will >>>>> >>>>> >>>>> On Monday, August 11, 2014 11:02:34 PM UTC+10, Michael DeHaan wrote: >>>>> >>>>>> So, let's not go down that lint-discussion road again. We know where >>>>>> it leads. >>>>>> >>>>>> Rather, let's once again discuss how we can improve roles to do what >>>>>> we need. >>>>>> >>>>>> As for role versioning, there have been a few who have liked the >>>>>> things that chef did with their library tool (I haven't used it), and >>>>>> we've >>>>>> posted quite a few times that we're open to making the ansible-galaxy CLI >>>>>> work better with raw SCM repos as well as versioning deps. >>>>>> >>>>>> There's also been the suggestion that ansible have a tag to assert >>>>>> the required ansible version, or perhaps it's a module. >>>>>> >>>>>> All of this seems like a good thing to do. >>>>>> >>>>>> I don't particularly care for the idea of requiring a version in the >>>>>> role name, as that breaks the ability to cleanly branch the role in >>>>>> Galaxy, >>>>>> which is handled via git tags presently. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 11, 2014 at 8:45 AM, Will Thames <wi...@thames.id.au> >>>>>> wrote: >>>>>> >>>>>>> Working in an environment where we hope to reuse common playbooks >>>>>>> and roles across the organisation, I've been thinking a lot on how to >>>>>>> manage updates to roles and playbooks without breaking repeatability >>>>>>> (running the same playbook against the same environment should have the >>>>>>> same result, even if the two runs are separated by months). >>>>>>> >>>>>>> My current strategy and some of the techniques that I use to augment >>>>>>> that is described at >>>>>>> http://willthames.github.io/2014/08/11/techniques-for-versio >>>>>>> ning-ansible.html >>>>>>> >>>>>>> and I plan to add some more rules for ansible-lint to allow checking >>>>>>> that roles fit the techniques (I'm not sure even whether to publish the >>>>>>> rules, but they certainly won't be core rules as they may well be >>>>>>> entirely >>>>>>> specific to my environment) >>>>>>> >>>>>>> Anyway thoughts are welcome on whether there are better ways to do >>>>>>> it! (Particularly if there's a pure DVCS way that achieves a similar >>>>>>> outcome) >>>>>>> >>>>>>> Will >>>>>>> >>>>>>> -- >>>>>>> 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 ansible-proje...@googlegroups.com. >>>>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/ansible-project/100fd0dc- >>>>>>> c083-4bd3-8e9f-dce0cb2c9b18%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/ansible-project/100fd0dc-c083-4bd3-8e9f-dce0cb2c9b18%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 ansible-proje...@googlegroups.com. >>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/ansible-project/d9177e20-4009-40fd-8217- >>>>> d7a2bacc9732%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/ansible-project/d9177e20-4009-40fd-8217-d7a2bacc9732%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 ansible-project+unsubscr...@googlegroups.com. >>> To post to this group, send email to ansible-project@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/8173919e-8948-4840-a58a-930bccb9259d%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/8173919e-8948-4840-a58a-930bccb9259d%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 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 >> ansible-project+unsubscr...@googlegroups.com. >> >> To post to this group, send email to ansible-project@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%40mail.gmail.com >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%40mail.gmail.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 ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAGmGhM3AKe9JCOwnNZytgvA-rVjU0KW7E9G6e67c7wsdRgWYDw%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CAGmGhM3AKe9JCOwnNZytgvA-rVjU0KW7E9G6e67c7wsdRgWYDw%40mail.gmail.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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxnzxsbqVFzFUJGBvBn0O7mdZ8PvXdreSw7jFeEbB0CoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
