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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 [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/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 [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/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 [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/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 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/CA%2BnsWgzFdWQS_H5PE1ijN4UAHsfUA5Foc%2BFzQ2hZa93twyw8tA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
