|
|
This moves knife into /knife, in the same way that chef-utils and
chef-config are separated.
NOTES:
== File History ==
If you see this message as the first message in the history of
an knife file, you can see the complete history by using
'git log --follow', 'git config log.follow true' to make it the default
behavior in this repository, or 'git config --globa log.follow true' to
make it the global default.
== API Changes ==
At the API level, there is one breaking change:
CookbookSiteStreamingUploader has been moved out of chef and into
knife/core.
There were a combination of reasons we chose this path:
- CookbookSiteStreamingUploader (CSSU) is only used within Knife.
- CookbookSiteStreamingUploader (CSSU) references the
command Chef::Knife::CookbookMetadata in order to generate
a metadata file for the cookbook to upload
- Chef::Knife::CookbookMetadata is no longer available to Chef:: because
Knife has been moved to its own gem. Knife gem depends on the Chef gem,
so Chef can't depend on something in Knife.
A search for usage in related projects (berks, chef-cli) and the
Internet at large shows that there are no known external consumers of CSSU.
For now, we'll move this class into Knife::Core, as it's going to be
faster than splitting off the metadata generation and time is a concern. If we
find that we need the metadata generation in chef/ proper, we should evaluate
decoupling that functionality from Knife::CookbookMetadata and exposing
it via something like `Chef::Cookbook::Metadata#from_cookbook_files`
== spec changes ==
The specs are kept in their existing locations, though we have
separated out a `knife_spec_helper` so that we can ensure knife is not
directly accessing chef requires; and chef is relying on knife's at all.
We also now clear gem paths with each test, to force gem state to reset.
This works around a problem where a combination of tests
is corrupting the internal Gem state, causing failures in
rubygems_spec. See branch `mp/broken-gems` for many more details around
findings so far.
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
|
