> > Also I may point out it appears you are using a new templating system :) >
I'm not. I'm using jinja2 and the tool itself has no extra dependencies other than what ansible requires. The %foo syntax is only used on the command line so you as the scripter have access to the current role name in your script. It can't just read the folder name because it might be prefixed with your git username to conform to the galaxy's way of naming roles. In the above example you might have your role at yourname/ansible-myrole on github but it's "yourname.myrole" on the galaxy. %role_name returns just "myrole" as a convenience. It is true that ansible-galaxy init does instantiate a readme template for > a role, contributions to make that configurable would be welcome, I'm not > sure "stats based" are the ideal way to go about it. > I think there's a misunderstanding about what the rebuild command does because you looked at the docs before I had documentation written about it. It's not stats based really. Look, the default ansible-galaxy readme template expects you to enter: *1. your default variables* This means you have your defaults listed in both your meta file AND your readme and it's annoying to keep both in sync by copy/pasting. Ansigenome solves this by just reading in your defaults from the meta file and dumps it under a defaults header in the readme. You don't have to configure anything to get this functionality but optionally you can overwrite the defaults output in the readme by changing your meta file. It also doesn't clutter your meta file with the automated readme contents either. *2. a list of dependencies* Yikes, here's another thing I need to copy/paste from my meta file without Ansigeome. Ansigenome solves this by just looking at your dependencies list in the meta file and outputs them cleanly in the readme without configuration. *3. example playbook* Ansigenome addresses this in a different way. By default it doesn't output anything like this to the readme since it's very custom and impossible to guess from just looking at your role. So instead all you have to do is goto the meta file and fill out the "inventory" field and it'll automatically create a quick start guide in your readme listing out whatever you wrote there. *4. requirements* Ansignome takes a peek at your platforms in the meta file and automatically builds a list of platforms for you in the readme. You don't need to copy/paste them into your readme anymore. You guys clearly thought some of those things were annoying so you built that into the galaxy role page, like the platforms, etc.. The problem is I don't want to have to look at a git repo AND the galaxy to figure out what a role does or needs to work. *As a role user looking to use a public role I want to see:* 1. What defaults are available? 2. What facts are set? 3. What platforms does it work on? 4. What dependencies do I need? 5. Is it idempotent? 6. Is it well tested and in working condition? As an aside I also don't want to have to look at both a galaxy profile and a git repo. I want a single point of truth that's close to home (git repo). *As an open source roler build I want to:* 1. Not have to copy/paste a ton of stuff into a readme file. 2. Easily be able to create unique content in my readme when needed. 3. Have as much documentation written automatically as possible. Ansigenome addresses all of the above issues and more with the rebuild/init commands and does it in a way that requires no configuration at all from the user for both role consumers and authors. What about roles that require authentication to external sources, or spin > up new cloud instances? This is why I'm saying public integration tests is > not feasible for many roles. > Ok, if you don't want an idempotency test added by default then just delete the .travis.yaml file in the role's directory. It also won't even run unless you specifically login to travis and turn the repo on. Having tests like this is a benefit to the community IMO and adding your own tests that ignore idempotency is super easy and standard to do. It shows how to use the role since you need to set it up on travis. It acts as fool proof documentation. because most large internal projects will have roles in all in one repo, > and in many cases, Travis doesn't apply, etc. > Then just don't use travis then, problem solved heh? Also you can have roles in 1 repo and benefit from Ansignome in the same way as having separate roles. It gathers stats on all roles it finds in a directory you give it. It doesn't care about any git directories. I used that run example of adding git directories as an example of the type of things you can do with the run commands. By no means do you need git dirs for each role. I want to make that super clear. -- 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/24078987-45f7-4e0e-9da2-d5695ace076b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
