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
ansible-lint provides a way of enforcing locally applicable standards - for example, we use it to warn against using Ansible as a build tool, among other things. 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? 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 > <javascript:>> 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-versioning-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 <javascript:>. >> To post to this group, send email to ansible...@googlegroups.com >> <javascript:>. >> 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-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/d9177e20-4009-40fd-8217-d7a2bacc9732%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
