Closed jf647 closed 9 years ago
So this option exists today: the -d
flag. The -d
flag specifies which directory to create your project structure in. It defaults to the value Chef::Config[:knife][:dockerfiles_path]
which you can set in your knife.rb.
However, it appears this feature is broken. I will work on fixing it today and get a bugfix release out soon. In the long term I envision the container init stuff will be integrated into the chef generate commands and follow the models that it provides.
Thanks for the feedback!
Okay, just built and release v0.2.3 of knife-container. This should fix the issue I mentioned above. You should now be able to specify which directory you want to create your repo in by using the -d
flag. You should be able to use relative paths (i.e. ./
for the current directory).
-d doesn't really work though. That's the path to the parent of my project, not to my project itself. -d:
Let's say that I name my container projects in git as container-whatever. I have to override the default name when I git clone. If I forget to, then I either get directory not found when I try to build (if I build with the correct name) or create an incorrectly named container (if I for example use tab completion)
Why can't I just say "this directory is where my project is are - use it"?
Right now this plug-in requires that I use the monolithic chef repo model or organize my directories in a particular fashion - one per repo under some directory that I set in knife.rb
Given that a) there is a 1:1 mapping from cookbooks to deployable artifacts in the grand vision and that Chef is committed to supporting the one repo per cookbook model, I think knife-container should too.
To that end, I think the path to the directory to work on should be a CLI arg or default to the current directory, making the interaction much more like Berkshelf. Integrating the current functionality into a CI pipeline is needlessly painful.