On Tue, Jul 22, 2014 at 10:06 AM, Nick Janetakis <[email protected]> wrote:
> 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. > Yep, I was referring to "%foo" > > 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. > With regard to the default variable entry (which is so far unused in galaxy, and can be left blank), it seems it would be better to just improve the ansible-galaxy CLI in this place so the usage of two tools together was not required. > > *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. > The galaxy dependency field here is free form, and can include things like packages that are required. It is not role specific. > > *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. > Unclear of how inventory and example playbooks are related. > > *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. > I'd like to see an attempt at not bifurcating the tooling here. > > *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? > So far the webpage handles all of this. > 5. Is it idempotent? > This is not something a machine can really test. It is something a machine can approximate. > 6. Is it well tested and in working condition? > Even if you have a green light or not, it doesn't indicate the quality of said tests. Galaxy is in many cases just a starting point and set of examples, it's fully expected that people will need to modify roles from time to time to make use of them. > > 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. > To be fair, tests aren't documentation either. -- 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%2BnsWgzkBZPi-szcwX1a4v%2B0pUse9-66MPnGUyHOXsJLy7NF9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
