chef-dk 0.13.21 → 0.14.25

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 722f7a9f5f65aa5ec8d60e293f8833f7c11ffe95
-  data.tar.gz: f8fd85790ea98e1af069db59e5642e4a29445000
+  metadata.gz: 56f3de2dac282a2ab7e2015ae5b42c32b5fe4d9d
+  data.tar.gz: d3af30f15ecc0141c7623e4a89973c943ca602d4
 SHA512:
-  metadata.gz: e034fb764e0325c9b4428b6404eb63ebc2a372d72c63b11b4554480a1259c76a4e8dccb81aa5f762808597f46fd9dc56fd068f2eee0ffc771dc5b8dffdffec21
-  data.tar.gz: 002e7e0f1e9562ec3adc14ea22fad26f9215d97041ca371ee1a82731a1f2c12cfed81b64a1e71a8517e30199ad879767e3e861c0292ab89b36b645495e5b2064
+  metadata.gz: d17189a949334660451375b67f9a1856fd28788257a82becd0bfdd5abf1477ac8ffcaf8314e6caaa81968e7c3751761cd1f0786e9a892562bdd3d24ab0073af7
+  data.tar.gz: a618a60884cb008a1a23b219325cc28de4d2c7e09601b4f3e956bf9474257fde639cc986fa50a3bcea7ef0276270ebbaafbf8c6e5bf12b039ee655cef93a5448

data/CONTRIBUTING.md

@@ -1,186 +1,186 @@
-# Contributing to Chef
-
-We are glad you want to contribute to Chef!
-
-We utilize **Github Issues** for issue tracking and contributions. You can contribute in two ways:
-
-1. Reporting an issue or making a feature request [here](#issues).
-2. Adding features or fixing bugs yourself and contributing your code to Chef.
-
-## Contribution Process
-
-We have a 3 step process that utilizes **Github Issues**:
-
-1. Sign or be added to an existing [Contributor License Agreement (CLA)](https://supermarket.chef.io/become-a-contributor).
-2. Create a Github Pull Request.
-3. Do [Code Review](#cr) with the **Chef Engineering Team** or **Chef Core Committers** on the pull request.
-
-### <a name="pulls"></a> Chef Pull Requests
-
-Chef is built to last. We strive to ensure high quality throughout the Chef experience. In order to ensure
-  this, we require a couple of things for all pull requests to Chef:
-
-1. **Tests:** To ensure high quality code and protect against future regressions, we require all the
-  code in Chef to have at least unit test coverage. Run ```bundle exec rspec``` from the project root
-  to execute the tests.
-2. **Green Travis Run:** We use [Travis CI](https://travis-ci.org/) in order to run our tests
-  continuously on all the pull requests. We require the Travis runs to succeed on every pull
-  request before being merged.
-
-In addition to this it would be nice to include the description of the problem you are solving
-  with your change. You can use [Chef Issue Template](#issuetemplate) in the description section
-  of the pull request.
-
-### <a name="cr"></a> Chef Code Review Process
-
-The Chef Code Review process happens on Github pull requests. See
-  [this article](https://help.github.com/articles/using-pull-requests) if you're not
-  familiar with Github Pull Requests.
-
-Once you a pull request, the **Chef Engineering Team** or **Chef Core Committers** will review your code
-  and respond to you with any feedback they might have. The process at this point is as follows:
-
-1. 2 thumbs-ups are required from the **Chef Engineering Team** or **Chef Core Committers** for all merges.
-2. When ready, your pull request will be tagged with label `Ready For Merge`.
-3. Your patch will be merged into `master` including necessary documentation updates
-  and you will be included in `CHANGELOG.md`. Our goal is to have patches merged in 2 weeks
-  after they are marked to be merged.
-
-If you would like to learn about when your code will be available in a release of Chef, read more about
-  [Chef Release Process](#release).
-
-### Contributor License Agreement (CLA)
-Licensing is very important to open source projects. It helps ensure the
-  software continues to be available under the terms that the author desired.
-
-Chef uses [the Apache 2.0 license](https://github.com/chef/chef/blob/master/LICENSE)
-  to strike a balance between open contribution and allowing you to use the
-  software however you would like to.
-
-The license tells you what rights you have that are provided by the copyright holder.
-  It is important that the contributor fully understands what rights they are
-  licensing and agrees to them. Sometimes the copyright holder isn't the contributor,
-  such as when the contributor is doing work for a company.
-
-To make a good faith effort to ensure these criteria are met, Chef requires an Individual CLA
-  or a Corporate CLA for contributions. This agreement helps ensure you are aware of the
-  terms of the license you are contributing your copyrighted works under, which helps to
-  prevent the inclusion of works in the projects that the contributor does not hold the rights
-  to share.
-
-It only takes a few minutes to complete a CLA, and you retain the copyright to your contribution.
-
-You can complete our
-  [Individual CLA](https://supermarket.chef.io/icla-signatures/new) online.
-  If you're contributing on behalf of your employer and they retain the copyright for your works,
-  have your employer fill out our
-  [Corporate CLA](https://supermarket.chef.io/ccla-signatures/new) instead.
-
-### Chef Obvious Fix Policy
-
-Small contributions such as fixing spelling errors, where the content is small enough
-  to not be considered intellectual property, can be submitted by a contributor as a patch,
-  without a CLA.
-
-As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality
-  or creative thinking. As long as the change does not affect functionality, some likely
-  examples include the following:
-
-* Spelling / grammar fixes
-* Typo correction, white space and formatting changes
-* Comment clean up
-* Bug fixes that change default return values or error codes stored in constants
-* Adding logging messages or debugging output
-* Changes to ‘metadata’ files like Gemfile, .gitignore, build scripts, etc.
-* Moving source files from one directory or package to another
-
-**Whenever you invoke the “obvious fix” rule, please say so in your commit message:**
-
-```
-------------------------------------------------------------------------
-commit 370adb3f82d55d912b0cf9c1d1e99b132a8ed3b5
-Author: danielsdeleo <dan@chef.io>
-Date:   Wed Sep 18 11:44:40 2013 -0700
-
-  Fix typo in config file docs.
-
-  Obvious fix.
-
-------------------------------------------------------------------------
-```
-
-## <a name="issues"></a> Chef Issue Tracking
-
-Chef Issue Tracking is handled using Github Issues.
-
-If you are familiar with Chef and know the component that is causing you a problem or if you
-  have a feature request on a specific component you can file an issue in the corresponding
-  Github project. All of our Open Source Software can be found in our
-  [Github organization](https://github.com/chef/).
-
-Otherwise you can file your issue in the [Chef project](https://github.com/chef/chef/issues)
-  and we will make sure it gets filed against the appropriate project.
-
-In order to decrease the back and forth in issues, and to help us get to the bottom of them quickly
-  we use the below issue template. You can copy/paste this template into the issue you are opening and
-  edit it accordingly.
-
-<a name="issuetemplate"></a>
-```
-### Version:
-[Version of the project installed]
-
-### Environment: [Details about the environment such as the Operating System, cookbook details, etc...]
-
-### Scenario:
-[What you are trying to achieve and you can't?]
-
-### Steps to Reproduce:
-[If you are filing an issue what are the things we need to do in order to repro your problem?]
-
-### Expected Result:
-[What are you expecting to happen as the consequence of above reproduction steps?]
-
-### Actual Result:
-[What actually happens after the reproduction steps?]
-```
-
-## <a name="release"></a> Chef Release Cycles
-
-Our primary shipping vehicle is operating system specific packages that includes
-  all the requirements of Chef. We call these [Omnibus packages](https://github.com/chef/omnibus)
-
-We also release our software as gems to [Rubygems](https://rubygems.org/) but we strongly
-  recommend using Chef packages since they are the only combination of native libraries &
-  gems required by Chef that we test throughly.
-
-Our version numbering closely follows [Semantic Versioning](http://semver.org/) standard. Our
-  standard version numbers look like X.Y.Z which mean:
-
-* X is a major release, which may not be fully compatible with prior major releases
-* Y is a minor release, which adds both new features and bug fixes
-* Z is a patch release, which adds just bug fixes
-
-We frequently make `alpha` and `beta` releases with version numbers that look like
-  `X.Y.Z.alpha.0` or `X.Y.Z.beta.1`. These releases are still well tested but not as
-  throughly as **Minor** or **Patch** releases.
-
-We do a `Minor` release approximately every 3 months and `Patch` releases on a when-needed
-  basis for regressions, significant bugs, and security issues.
-
-Announcements of releases are available on [Chef Blog](https://www.chef.io/blog/) when they are
-  available.
-
-## Chef Community
-
-Chef is made possible by a strong community of developers and system administrators. If you have
-  any questions or if you would like to get involved in the Chef community you can check out:
-
-* [chef](http://lists.opscode.com/sympa/info/chef) and [chef-dev](http://lists.opscode.com/sympa/info/chef-dev) mailing lists
-* [\#chef](https://botbot.me/freenode/chef) and [\#chef-hacking](https://botbot.me/freenode/chef-hacking) IRC channels on irc.freenode.net
-
-Also here are some additional pointers to some awesome Chef content:
-
-* [Chef Docs](https://docs.chef.io/)
-* [Learn Chef](https://learn.chef.io/)
-* [Chef Inc](https://www.chef.io/)
+# Contributing to Chef
+
+We are glad you want to contribute to Chef!
+
+We utilize **Github Issues** for issue tracking and contributions. You can contribute in two ways:
+
+1. Reporting an issue or making a feature request [here](#issues).
+2. Adding features or fixing bugs yourself and contributing your code to Chef.
+
+## Contribution Process
+
+We have a 3 step process that utilizes **Github Issues**:
+
+1. Sign or be added to an existing [Contributor License Agreement (CLA)](https://supermarket.chef.io/become-a-contributor).
+2. Create a Github Pull Request.
+3. Do [Code Review](#cr) with the **Chef Engineering Team** or **Chef Core Committers** on the pull request.
+
+### <a name="pulls"></a> Chef Pull Requests
+
+Chef is built to last. We strive to ensure high quality throughout the Chef experience. In order to ensure
+  this, we require a couple of things for all pull requests to Chef:
+
+1. **Tests:** To ensure high quality code and protect against future regressions, we require all the
+  code in Chef to have at least unit test coverage. Run ```bundle exec rspec``` from the project root
+  to execute the tests.
+2. **Green Travis Run:** We use [Travis CI](https://travis-ci.org/) in order to run our tests
+  continuously on all the pull requests. We require the Travis runs to succeed on every pull
+  request before being merged.
+
+In addition to this it would be nice to include the description of the problem you are solving
+  with your change. You can use [Chef Issue Template](#issuetemplate) in the description section
+  of the pull request.
+
+### <a name="cr"></a> Chef Code Review Process
+
+The Chef Code Review process happens on Github pull requests. See
+  [this article](https://help.github.com/articles/using-pull-requests) if you're not
+  familiar with Github Pull Requests.
+
+Once you a pull request, the **Chef Engineering Team** or **Chef Core Committers** will review your code
+  and respond to you with any feedback they might have. The process at this point is as follows:
+
+1. 2 thumbs-ups are required from the **Chef Engineering Team** or **Chef Core Committers** for all merges.
+2. When ready, your pull request will be tagged with label `Ready For Merge`.
+3. Your patch will be merged into `master` including necessary documentation updates
+  and you will be included in `CHANGELOG.md`. Our goal is to have patches merged in 2 weeks
+  after they are marked to be merged.
+
+If you would like to learn about when your code will be available in a release of Chef, read more about
+  [Chef Release Process](#release).
+
+### Contributor License Agreement (CLA)
+Licensing is very important to open source projects. It helps ensure the
+  software continues to be available under the terms that the author desired.
+
+Chef uses [the Apache 2.0 license](https://github.com/chef/chef/blob/master/LICENSE)
+  to strike a balance between open contribution and allowing you to use the
+  software however you would like to.
+
+The license tells you what rights you have that are provided by the copyright holder.
+  It is important that the contributor fully understands what rights they are
+  licensing and agrees to them. Sometimes the copyright holder isn't the contributor,
+  such as when the contributor is doing work for a company.
+
+To make a good faith effort to ensure these criteria are met, Chef requires an Individual CLA
+  or a Corporate CLA for contributions. This agreement helps ensure you are aware of the
+  terms of the license you are contributing your copyrighted works under, which helps to
+  prevent the inclusion of works in the projects that the contributor does not hold the rights
+  to share.
+
+It only takes a few minutes to complete a CLA, and you retain the copyright to your contribution.
+
+You can complete our
+  [Individual CLA](https://supermarket.chef.io/icla-signatures/new) online.
+  If you're contributing on behalf of your employer and they retain the copyright for your works,
+  have your employer fill out our
+  [Corporate CLA](https://supermarket.chef.io/ccla-signatures/new) instead.
+
+### Chef Obvious Fix Policy
+
+Small contributions such as fixing spelling errors, where the content is small enough
+  to not be considered intellectual property, can be submitted by a contributor as a patch,
+  without a CLA.
+
+As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality
+  or creative thinking. As long as the change does not affect functionality, some likely
+  examples include the following:
+
+* Spelling / grammar fixes
+* Typo correction, white space and formatting changes
+* Comment clean up
+* Bug fixes that change default return values or error codes stored in constants
+* Adding logging messages or debugging output
+* Changes to ‘metadata’ files like Gemfile, .gitignore, build scripts, etc.
+* Moving source files from one directory or package to another
+
+**Whenever you invoke the “obvious fix” rule, please say so in your commit message:**
+
+```
+------------------------------------------------------------------------
+commit 370adb3f82d55d912b0cf9c1d1e99b132a8ed3b5
+Author: danielsdeleo <dan@chef.io>
+Date:   Wed Sep 18 11:44:40 2013 -0700
+
+  Fix typo in config file docs.
+
+  Obvious fix.
+
+------------------------------------------------------------------------
+```
+
+## <a name="issues"></a> Chef Issue Tracking
+
+Chef Issue Tracking is handled using Github Issues.
+
+If you are familiar with Chef and know the component that is causing you a problem or if you
+  have a feature request on a specific component you can file an issue in the corresponding
+  Github project. All of our Open Source Software can be found in our
+  [Github organization](https://github.com/chef/).
+
+Otherwise you can file your issue in the [Chef project](https://github.com/chef/chef/issues)
+  and we will make sure it gets filed against the appropriate project.
+
+In order to decrease the back and forth in issues, and to help us get to the bottom of them quickly
+  we use the below issue template. You can copy/paste this template into the issue you are opening and
+  edit it accordingly.
+
+<a name="issuetemplate"></a>
+```
+### Version:
+[Version of the project installed]
+
+### Environment: [Details about the environment such as the Operating System, cookbook details, etc...]
+
+### Scenario:
+[What you are trying to achieve and you can't?]
+
+### Steps to Reproduce:
+[If you are filing an issue what are the things we need to do in order to repro your problem?]
+
+### Expected Result:
+[What are you expecting to happen as the consequence of above reproduction steps?]
+
+### Actual Result:
+[What actually happens after the reproduction steps?]
+```
+
+## <a name="release"></a> Chef Release Cycles
+
+Our primary shipping vehicle is operating system specific packages that includes
+  all the requirements of Chef. We call these [Omnibus packages](https://github.com/chef/omnibus)
+
+We also release our software as gems to [Rubygems](https://rubygems.org/) but we strongly
+  recommend using Chef packages since they are the only combination of native libraries &
+  gems required by Chef that we test throughly.
+
+Our version numbering closely follows [Semantic Versioning](http://semver.org/) standard. Our
+  standard version numbers look like X.Y.Z which mean:
+
+* X is a major release, which may not be fully compatible with prior major releases
+* Y is a minor release, which adds both new features and bug fixes
+* Z is a patch release, which adds just bug fixes
+
+We frequently make `alpha` and `beta` releases with version numbers that look like
+  `X.Y.Z.alpha.0` or `X.Y.Z.beta.1`. These releases are still well tested but not as
+  throughly as **Minor** or **Patch** releases.
+
+We do a `Minor` release approximately every 3 months and `Patch` releases on a when-needed
+  basis for regressions, significant bugs, and security issues.
+
+Announcements of releases are available on [Chef Blog](https://www.chef.io/blog/) when they are
+  available.
+
+## Chef Community
+
+Chef is made possible by a strong community of developers and system administrators. If you have
+  any questions or if you would like to get involved in the Chef community you can check out:
+
+* [chef](https://discourse.chef.io/) and [chef-dev](https://discourse.chef.io/c/dev) mailing lists and mailing list [FAQ](https://discourse.chef.io/t/welcome-to-the-chef-mailing-list/7070)
+* [\#chef](https://botbot.me/freenode/chef) and [\#chef-hacking](https://botbot.me/freenode/chef-hacking) IRC channels on irc.freenode.net
+
+Also here are some additional pointers to some awesome Chef content:
+
+* [Chef Docs](https://docs.chef.io/)
+* [Learn Chef](https://learn.chef.io/)
+* [Chef Inc](https://www.chef.io/)

data/Gemfile

@@ -17,15 +17,12 @@
 
 source 'https://rubygems.org'
 
-# path is needed because when we attempt to load this gemspec to look at it from
-# another bundle, it will expand the path relative to the other bundle rather than
-# this file.
-gemspec path: File.dirname(__FILE__), name: "chef-dk"
+gemspec name: "chef-dk"
 
 # EXPERIMENTAL: ALL gems specified here will be installed in chef-dk omnibus.
 # This represents all gems that will be part of chef-dk.
 
-group(:omnibus_package, :development) do
+group(:omnibus_package, :development, :test) do
   gem "pry"
 end
 
@@ -44,7 +41,7 @@ group(:omnibus_package) do
   gem "chef-provisioning-vagrant", ">= 0.11.0"
   gem "chef-vault"
   # The chef version is pinned by "rake dependencies", which grabs the current version from omnibus.
-  gem "chef", github: "chef/chef", branch: "v12.9.41"
+  gem "chef", github: "chef/chef", branch: "v12.10.24"
   gem "cheffish", ">= 2.0.3"
   gem "chefspec"
   gem "fauxhai"
@@ -56,6 +53,19 @@ group(:omnibus_package) do
   gem "knife-windows"
   gem "ohai", ">= 8.13.0"
   gem "test-kitchen"
+  # Until listen supports Ruby 2.0 and 2.1
+  gem "listen", "< 3.1.0"
+  gem "mixlib-install"
+
+  # For Delivery build node
+  gem "chef-sugar"
+  gem "knife-supermarket"
+  gem "mixlib-versioning"
+  gem "artifactory"
+  # The opscode-pushy-client version is pinned by "rake dependencies", which grabs the current version from omnibus.
+  gem "opscode-pushy-client", github: "chef/opscode-pushy-client", branch: "1.3.4"
+  gem "ffi-rzmq-core"
+  gem "knife-push"
 
   # All of the following used to be software definitions we included:
   gem "knife-spork"
@@ -65,8 +75,10 @@ group(:omnibus_package) do
   gem "pry-remote"
   gem "pry-stack_explorer"
   gem "rb-readline"
-  gem "rubocop", "~> 0.37.2"
+  gem "rubocop"
+  gem "cookstyle"
   gem "winrm-fs"
+  gem "winrm-elevated"
 
   # bundled or development dependencies we want to ship
   gem "dep_selector"
@@ -77,11 +89,22 @@ group(:omnibus_package) do
   gem "yard"
 end
 
-# NOTE this needs to be excluded from AIX too, but we don't support that on
-# ChefDK and putting a thing in multiple groups :no_windows, :no_aix won't work
-# because it --without no_aix will still install things in group :no_windows.
-# Need to specify groups positively; investigate.
-# http://stackoverflow.com/questions/8420414/how-to-add-mac-specific-gems-to-bundle-on-mac-but-not-on-linux
-group(:no_windows) do
-  gem "ruby-shadow"
+# Everything except AIX and Windows
+group(:linux, :bsd, :mac_os_x, :solaris) do
+  gem "ruby-shadow", platform: :ruby
+end
+
+# TODO delete this when we figure out how to include the pushy windows dependencies
+# correctly
+platforms :mswin, :mingw do
+  gem "ffi"
+  gem "rdp-ruby-wmi"
+  gem "windows-api"
+  gem "windows-pr"
+  gem "win32-api"
+  gem "win32-dir"
+  gem "win32-event"
+  gem "win32-mutex"
+  gem "win32-process", "~> 0.8.2"
+  gem "win32-service"
 end