On Tue, Jul 22, 2014 at 8:56 AM, Nick Janetakis <[email protected]> wrote:
> Thanks for the feedback, I'll try to address some of your concerns: > > *Re: "run":* > The stemmed from the ginas project. It's currently 50 roles inside of a > single git repo. The author of ginas recently decided he's going to try and > break up each role into stand alone git repos and release whatever roles he > can on the galaxy. Now... he is a unix beast and could write a script to > walk each directory, create a new git repo, add a remote origin to it, > etc.. but it's annoying to write all of that stuff. Wouldn't it be cool to > just type: > > `ansigenome run -m 'git init && git remote add origin https://github.com/ >> *yourname*/%role_name.git` >> > I'd probably go "find . | xargs" myself, maybe bash alias it. For most internal projects, keeping one role per repo is really complicated. It works great for galaxy because it allows for seperate versions and forking, and easier pull requests. Also I may point out it appears you are using a new templating system :) > > That's all you would need to write to make 50 git dirs and add a custom > remote to each one. %role_name gets replaced with the current role in the > loop. > > *Re: "rebuild":* > Also he wanted to make a readme standard for all his roles. He wanted an > easy way to adjust a readme template for all his roles at once. By > providing just a tiny bit of information in your meta file it will create > an interesting readme file for you based on the stats it found by > inspecting your role. > This seems a bit specialized at first glance. 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. > > Since last night I've added a bit more documentation on rebuilding: > https://github.com/nickjj/ansigenome#example-rebuild-output > > You can see an example output there and how you would use it. > > > *Re: travis:*There's a lot of low quality roles on the galaxy that aren't > idempotent. The init command of ansigenome uses the standard ansible-galaxy > init structure but it adds a travis test that runs your role twice and > checks to make sure there are 0 changes. That's pretty useful to have for > free. If you're not a unix wizard (I'm not) and fairly new to ansible then > you might not be sure how to test ansible roles either. I just wanted to > give people a stepping stone. > 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. See our testing guide at http://docs.ansible.com/test_strategies.html for some pointers on testing in general. I don't think people would need to adopt an extra ecosystem tool in order to test things. > --- > > I tried to stick to the ansible-style way of making command line tools so > that maybe merging certain things into ansible-galaxy would be easier. What > was wrong with the syntax btw? I went for a stock pep8 setup. > Which syntax? > > Thanks again for ansible Michael. > You are welcome. I don't mean to be harsh above, but I do question when "ecosystem" tools instantly show up in PyPi without some attempt to discuss them first, or an attempt to build a stronger core. We were built on "batteries included" to a great degree. I agree we move slower now as we must be more conservative about making sure things are simple and robust than two years ago, and because we have thousands of people trying to throw code at Ansible all at once. But I generally don't believe recreating the problems, of say, other ecosystems with metaphor-filled tool names of varying utility, are ultimately good in the long run, because someone feels they need to use everything. There's a desire for minimalism, and making sure everything fits in. Right down to making sure we use the same ways of replacing variables. I don't mean to be a control freak - this may very well serve a purpose, but I think the needs of it are not the needs of many, per se, because most large internal projects will have roles in all in one repo, and in many cases, Travis doesn't apply, etc. So some decisions made are very specific to a few very specific use cases. That is not to say I think it should not exist. I'm just questioning how to make something more generally accessible to everyone, and also how to continue to evolve those tools around a hub everybody can collaborate around. Hope this makes sense. -- > 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/1942657a-1067-4001-9d45-624b22a66485%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/1942657a-1067-4001-9d45-624b22a66485%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%2BnsWgz%2BEB1Zz8WcNxP9buXf8HYgd77qb9O7Bc9D0Mh9AhW8XA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
