-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workflow experiment #117
base: master
Are you sure you want to change the base?
Workflow experiment #117
Conversation
Conflicts: lib/cucumber/chef/steps/ssh_steps.rb
👍 From a cursory glance I like all of this; just got into the office; but I will post some thoughts on this before EOD. |
I just put my cucumber-chef tests in the same repo as my chef-repo. Why do you think it's better to have your cucumber tests in a separate repository? |
Ya at present I always place everything directly in the |
Normally I'm in favor of adding flexibility when it doesn't paint us into a corner, but in this case I think divorcing the cucumber-chef tests from the chef-repo does more harm than good. When I view a chef-repo, the features serve as documentation (in addition to their normal purpose of maintainability); they show me how to use the roles and environments and cookbooks in this repo. If the features are moved into a separate repo, then I either 1) won't know they exist, or 2) will have to hunt for them and keep two repositories open just to manage one. And because the features are separate, it's much easier to forget to update them when a role/whatever changes. One last, smaller point: if two repositories are used, then two pull requests are required for one change-set. Not a problem for people who don't use pull requests, but seeing as it's a popular feature on GitHub I think encouraging its misuse is a bad idea. |
@anujbiyani Point taken, but my proposal would not break your current workflow, it just allows a bit of flexibility. Also, I'm finding that a lot of my Chef work these days consists of hunting down the appropriate community cookbooks and then setting a few attributes, either in an environment (which then belongs in the chef-repo) or in a role (which quite likely belongs firmly within a specific project), which has led me to this idea. If you're working on your own cookbooks, then yeah, I can see why this idea will not appeal to you. I see this as a nice smooth path to getting dev thinking about ops (and the other way around). And combined with the Magic Space Future of Vagrant 1.1, we can ship pretty much entirely self-contained projects out of Github. This really appeals. But maybe that's just me ;) There is at least one more potential banana skin here: creating a feature attempts to create And yeah, the code in this PR is bit lashed-together, I don't recommend merging it just yet :) |
True.
Not sure why this idea is any better or worse for working with community cookbooks and just setting attributes. Further, when I write my own cookbooks I don't put them in a
I think I take the opposite view point. Speaking as a dev who was brand new to ops 4 months ago (when I started learning about and working aggressively on Chef stuff), I'm used to seeing tests live next to code. The two (tests and implementation) would co-exist in every sense of the word; one commit would contain both implementation and tests, one pull request would show both, and one repo would contain both. |
Here's my thoughts on a few things:
I briefly went down a road of making cucumber-chef "aware" of librarian for example, but I dropped that in favor of just defining cookbook_paths, that is cucumber-chef should be ignorant because at the end of the day it just wants to upload items from directories and run your tests. Adding internals logic (like saying oh we should look in "site-cookbooks" because we know we're using librarian) is just asking for trouble. That being said, I am highly in favor of configuration options like the ones suggested by @pikesley. I feel it is great to allow this level of configuration flexibility, especially if it helps to bring non-standard chef-repo models into "the fold" as it were and allows them to pursue test driven infrastructure. Bottom line; as long as the default out-of-the-box operation revolves around the standard best practice of running everything out of a single chef-repo and we continue to support that model as the default model I am happy. I am also happy if we can break down a barrier of entry for people with non-standard chef-repo setups and let them start doing test driven infrastructure (the whole time gently nudging them towards the best practice model of course ;)). |
I can confirm that this is necessary. I set up a new chef repo while testing out some things but connected it to the same AWS account as another repo, and sure enough the new chef repo tried to use the old cucumber-chef server.
Heh I do the exact same thing.
I think that a feature init tesk is necessary (one that just creates |
I'm about to disappear to Cornwall for a week, so there'll be no further contributions from me until at least the 22nd, but I'll clean the code up when I'm back and see how I get on... |
@pikesley Have a safe trip; I may get around to implementing some of the configuration changes (namely the path ones) while your out; if I fiddle with this I'll be sure to post here. |
This PR is really just intended to initiate a discussion around some ideas I have for workflow. So, get this:
At the moment, we have a separate repo for our cucumber-chef stuff. Our features live over there, our site-cookbooks, our Cheffile, the whole thing.
And this feels like a bit of a non-DevOps silo. My thinking is that I would really like to run a cucumber-chef test-lab per-project, but use the cookbooks, environments etc from the existing repo (because these will be common across projects). So I would add cucumber-chef to the Gemfile of some-project and bundle it, then do
then fix up the Labfile and construct the feature as required, and
which I guess will run all of the tests in that project, from the ground up, which strikes me as a Good Thing.
This PR represents my first cut at actually implementing this. We need to specify the location from which we'll pull the cookbooks, so we can now do things like this in
.cucumber-chef/config.rb
:which client.rb can now understand via this in config.rb
I'm now thinking, however, that further abstractions could be made and we could just have something like
and work it all out from there.
So at the moment, I have this working for a very simple case.
Things to think about:
Does anybody else think this idea has legs? Is there something I've not thought of that's going to bite me on the bum?