chef 13.12.14-universal-mingw32 → 14.0.190-universal-mingw32

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 7d32c80fb2917db8cdd064e6a0d981b6d3f2564c7b3570c03af37574ece1ee9e
-  data.tar.gz: 4891751cc51dd9d90624ad9d874952c6063e62e6271e69763d252a0e3995659b
+  metadata.gz: 7a378319870954e8105126159aa40db523d18e5c2e8acf9a5b27385fb98d18bf
+  data.tar.gz: 673386d0877c12dcf880feb1420d20669c45d0ec667e348d5cd52b2cf1d11f75
 SHA512:
-  metadata.gz: c338e5c0f79c6f5bff45702a0a769fd2729df7a756ca26e74b43d30bf44bece8fee67a04703afce3fd43c293d2a9ff20fff1bbe4e545bd41d6aec129921953ad
-  data.tar.gz: 39865034b1dc623e54771f6d6749ac7037733069e3b091ebd3d9a2f2f22d2f7d0b21f90c8381c6c583edf60f1b40836db6c282005e1c00207b39830dbf60940d
+  metadata.gz: 1d31d38504623a1d60c8373f822321bd5009ee53ab3b920830c4760a1db69acaad8e2d249ac298ce6c2bed1d76c36cd548f733b09d71dfd4192ebe292dec884f
+  data.tar.gz: 13f77acdd5761f78377969264c46748f5702a607cceb25dd30201bcf405360ee43174e23c60c0428530218e1524ca3a64ad1c8379697924fd6e8b19a42cfce5c

data/CONTRIBUTING.md

@@ -0,0 +1,151 @@
+# Contributing to Chef Projects
+
+We're glad you want to contribute to a Chef project! This document will help answer common questions you may have during your first contribution.
+
+## Submitting Issues
+
+Not every contribution comes in the form of code. Submitting, confirming, and triaging issues is an important task for any project. At Chef we use Github to track all project issues.
+
+If you are familiar with Chef and know the component, that is causing you a problem, 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/). All projects include Github issue templates to help gather information needed for a thorough review.
+
+We ask you not to submit security concerns via Github. For details on submitting potential security issues please see <https://www.chef.io/security/>
+
+In addition to Github issues, we also utilize a feedback site that helps our product team track and rank feature requests. If you have a feature request, this is an excellent place to start <https://feedback.chef.io>
+
+## Contribution Process
+
+We have a 3 step process for contributions:
+
+1. Commit changes to a git branch, making sure to sign-off those changes for the [Developer Certificate of Origin](#developer-certification-of-origin-dco).
+2. Create a Github Pull Request for your change, following the instructions in the pull request template.
+3. Perform a [Code Review](#code-review-process) with the project maintainers on the pull request.
+
+### Pull Request Requirements
+
+Chef Projects are built to last. We strive to ensure high quality throughout the experience. In order to ensure this, we require that all pull requests to Chef projects meet these specifications:
+
+1. **Tests:** To ensure high quality code and protect against future regressions, we require all the code in Chef Projects to have at least unit test coverage. We use [RSpec](http://rspec.info/) for unit testing.
+2. **Green CI Tests:** We use [Travis CI](https://travis-ci.org/) and/or [AppVeyor](https://www.appveyor.com/) CI systems to test all pull requests. We require these test runs to succeed on every pull request before being merged.
+
+### Code Review Process
+
+Code review takes place in Github pull requests. See [this article](https://help.github.com/articles/about-pull-requests/) if you're not familiar with Github Pull Requests.
+
+Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
+
+1. Two thumbs-up (:+1:) are required from project maintainers. See the master maintainers document for Chef projects at <https://github.com/chef/chef/blob/master/MAINTAINERS.md>.
+2. When ready, your pull request will be tagged with label `Ready For Merge`.
+3. Your change will be merged into the project's `master` branch and will be noted in the project's `CHANGELOG.md` at the time of release.
+
+If you would like to learn about when your code will be available in a release of Chef, read more about [Chef Release Cycles](#release-cycles).
+
+### Developer Certification of Origin (DCO)
+
+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 on behalf of a company.
+
+To make a good faith effort to ensure these criteria are met, Chef requires the Developer Certificate of Origin (DCO) process to be followed.
+
+The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at <http://developercertificate.org/>.
+
+```
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the
+    best of my knowledge, is covered under an appropriate open
+    source license and I have the right under that license to   
+    submit that work with modifications, whether created in whole
+    or in part by me, under the same open source license (unless
+    I am permitted to submit under a different license), as
+    Indicated in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including
+    all personal information I submit with it, including my
+    sign-off) is maintained indefinitely and may be redistributed
+    consistent with this project or the open source license(s)
+    involved.
+```
+
+For more information on the change see the Chef Blog post [Introducing Developer Certificate of Origin](https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/)
+
+#### DCO Sign-Off Methods
+
+The DCO requires a sign-off message in the following format appear on each commit in the pull request:
+
+```
+Signed-off-by: Julia Child <juliachild@chef.io>
+```
+
+The DCO text can either be manually added to your commit body, or you can add either **-s** or **--signoff** to your usual git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running **git commit --amend -s**. If you've pushed your changes to Github already you'll need to force push your branch after this with **git push -f**.
+
+### 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 without signing the contribution for the DCO.
+
+As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. Assuming the change does not affect functionality, some common obvious fix 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: Julia Child <juliachild@chef.io>
+Date:   Wed Sep 18 11:44:40 2015 -0700
+
+  Fix typo in the README.
+
+  Obvious fix.
+
+------------------------------------------------------------------------
+```
+
+## 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 roughly 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
+
+After shipping a release of Chef we bump the `Minor` version by one to start development of the next minor release. All merges to master trigger an increment of the `Patch` version, and a build through our internal testing pipeline. We do a `Minor` release approximately every month, which consist of shipping one of the already auto-incremented and tested `Patch` versions. For example after shiping 12.10.24, we incremented Chef to 12.11.0\. From there 18 commits where merged bringing the version to 12.11.18, which we shipped as an omnibus package.
+
+Announcements of releases are made to the [chef mailing list](https://discourse.chef.io/c/chef-release) 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 Mailing List](https://discourse.chef.io/)
+- [Chef Community Slack](https://community-slack.chef.io/)
+
+Also here are some additional pointers to some awesome Chef content:
+
+- [Chef Docs](https://docs.chef.io/)
+- [Learn Chef](https://learn.chef.io/)
+- [Chef Website](https://www.chef.io/)

data/Gemfile

@@ -7,15 +7,18 @@ source "https://rubygems.org"
 # of bundler versions prior to 1.12.0 (https://github.com/bundler/bundler/commit/193a14fe5e0d56294c7b370a0e59f93b2c216eed)
 gem "chef", path: "."
 
-gem "ohai", "~> 13"
-
 gem "chef-config", path: File.expand_path("../chef-config", __FILE__) if File.exist?(File.expand_path("../chef-config", __FILE__))
-gem "cheffish", "~> 13" # required for rspec tests
+gem "cheffish", "~> 14"
 
 group(:omnibus_package) do
+  # override for unf_ext for inspec 2 until
+  # https://github.com/knu/ruby-unf_ext/pull/39
+  # is merged and released
+  gem "unf_ext", "=0.0.7.6", :git => "https://github.com/jquick/ruby-unf_ext.git"
+
   gem "appbundler"
   gem "rb-readline"
-  gem "inspec", "~> 1"
+  gem "inspec", "~> 2"
   gem "chef-vault"
 end
 
@@ -49,13 +52,13 @@ group(:ruby_shadow) do
 end
 
 group(:development, :test) do
-  # we pin rake as a copy of rake is installed from the ruby source
-  # if you bump the ruby version you should confirm we don't end up with
-  # two rake gems installed again
-  gem "rake", "<= 12.0.0"
+  gem "rake"
   gem "simplecov"
   gem "webmock"
-  gem "chefstyle", "0.6.0"
+
+  # for testing new chefstyle rules
+  # gem 'chefstyle', github: 'chef/chefstyle'
+  gem "chefstyle", git: "https://github.com/chef/chefstyle.git", branch: "master"
 end
 
 group(:travis) do

data/README.md

@@ -26,7 +26,7 @@ If you just want to use Chef, check out these resources:
 - [learnchef](https://learn.chef.io): Getting started guide
 - [docs.chef.io](https://docs.chef.io): Comprehensive User Docs
 - [Installer Downloads](https://downloads.chef.io/chef/): Install Chef as a complete package
-- [chef/chef](https://hub.docker.com/r/chef/chef/): Docker image for use with [kitchen-dokken](https://github.com/someara/kitchen-dokken/)
+- [chef/chef](https://hub.docker.com/r/chef/chef): Docker image for use with [kitchen-dokken](https://github.com/someara/kitchen-dokken)
 
 ## Reporting Issues
 
@@ -43,9 +43,9 @@ against the repository you think best fits and it will be directed to the approp
 
 ## Installing From Git for Developers
 
-**NOTE:** As a Chef user, please download the [Chef](https://downloads.chef.io/chef) or [Chef-DK](https://downloads.chef.io/chef) packages, which provide Ruby and other necessary libraries for running Chef.
+**NOTE:** As a Chef user, please download the omnibus package of [Chef](https://downloads.chef.io/chef) or [Chef-DK](https://downloads.chef.io/chef)
 
-We do not recommend end users install Chef from gems or build from source. The following instructions apply only to those doing software development on Chef.
+We do not recommend installing from gems, or building from source.  The following instructions apply only to those doing software development on Chef.
 
 ### Prerequisites
 
@@ -53,7 +53,7 @@ Install:
 
 * git
 * C compiler, header files, etc.
-* ruby 2.3.3 or later
+* ruby 2.4 or later
 * rubygems
 * bundler gem
 
@@ -63,31 +63,36 @@ note about downloading the pre-built omnibus install if you do not understand ho
 
 ### Chef Installation
 
-Once you have your development environment configured you can clone the Chef repository and install Chef:
+Then get the source and install it:
 
 ```bash
 git clone https://github.com/chef/chef.git
 cd chef
 bundle install
+bundle exec rake gem
 bundle exec rake install
 ```
 
 ## Contributing/Development
 
-Please read our [Community Contributions Guidelines](https://docs.chef.io/community_contributions.html), and ensure you are signing all your commits with DCO sign-off.
+Please read our [Community Contributions Guidelines](https://docs.chef.io/community_contributions.html), and
+ensure you are signing all your commits with DCO sign-off.
 
 The general development process is:
 
 1. Fork this repo and clone it to your workstation.
 2. Create a feature branch for your change.
 3. Write code and tests.
-4. Push your feature branch to GitHub and open a pull request against master.
+4. Push your feature branch to github and open a pull request against master.
 
-Once your repository is set up, you can start working on the code. We do utilize RSpec for test driven development, so you'll need to get a development environment running. Follow the above procedure ("Installing from Git") to get your local copy of the source running.
+Once your repository is set up, you can start working on the code. We do utilize
+RSpec for test driven development, so you'll need to get a development
+environment running. Follow the above procedure ("Installing from Git") to get
+your local copy of the source running.
 
 ## Testing
 
-This repository uses rspec for testing.
+This repository only uses rspec for testing.
 
 ```bash
 # all tests
@@ -100,11 +105,11 @@ bundle exec rspec spec/PATH/TO/FILE_spec.rb
 bundle exec rspec spec/PATH/TO/DIR
 ```
 
-When you submit a PR rspec tests will run automatically on [Travis-CI](https://travis-ci.org/) and [AppVeyor](https://www.appveyor.com/).
+When you submit a PR rspec tests will run automatically on travis and appveyor.
 
 ## Building the Full Package
 
-To build Chef as a standalone package, we use the [omnibus](omnibus/README.md) packaging system.
+To build chef as a standalone package, we use the [omnibus](omnibus/README.md) system.
 
 To build:
 
@@ -115,7 +120,9 @@ bundle install
 bundle exec omnibus build chef
 ```
 
-The prerequisites necessary to run omnibus itself are not documented in this repository. See the [Omnibus repository](https://github.com/chef/omnibus) for additional details.
+The prerequisites necessary to run omnibus itself are not documented here.  The automation we use is
+the [opscode-ci cookbook](https://github.com/chef-cookbooks/opscode-ci) cookbook, which serves as the most
+current documentation.
 
 ## Updating Dependencies
 
@@ -144,13 +151,13 @@ Chef is an amalgam of many components. These components update all the time, nec
 
 ## Chef Packages
 
-Chef is distributed as packages for debian, rhel, ubuntu, windows, solaris, aix, and macos. It includes a large number of components from various sources, and these are versioned and maintained separately from the chef project, which bundles them all together conveniently for the user.
+Chef is distributed as packages for debian, rhel, ubuntu, windows, solaris, aix, and os x. It includes a large number of components from various sources, and these are versioned and maintained separately from chef project, which bundles them all together conveniently for the user.
 
 These packages go through several milestones:
-- `master`: When code is checked in to master, the patch version of chef is bumped (e.g. 14.5.1 -> 14.5.2) and a build is kicked off automatically to create and test the packages in Chef's internal CI cluster.
+- `master`: When code is checked in to master, the patch version of chef is bumped (e.g. 0.9.10 -> 0.9.11) and a build is kicked off automatically to create and test the packages in Chef's Jenkins cluster.
 - `unstable`: When a package is built, it enters the unstable channel. When all packages for all OS's have successfully built, the test phase is kicked off in Jenkins across all supported OS's. These builds are password-protected and generally only available to the test systems.
-- `current`: If the packages pass all the tests on all supported OS's, it is promoted as a unit to `current`, and is available by running `curl https://www.chef.io/chef/install.sh | sudo bash -s -- -c current -P chef` or at <https://downloads.chef.io/chef/current>
-- `stable`: Periodically, Chef will pick a release to "bless" for folks who would like a slower update schedule than "every time a build passes the tests." When this happens, it is manually promoted to stable and an announcement is sent to the list. It can be reached at <https://downloads.chef.io> or installed using the `curl` command without specifying `-c current`. Packages in `stable` are no longer available in `current`.
+- `current`: If the packages pass all the tests on all supported OS's, it is promoted as a unit to `current`, and is available via Chef's artifactory by running `curl https://www.chef.io/chef/install.sh | sudo bash -s -- -c current -P chef`
+- `stable`: Periodically, Chef will pick a release to "bless" for folks who would like a slower update schedule than "every time a build passes the tests." When this happens, it is manually promoted to stable and an announcement is sent to the list. It can be reached at https://downloads.chef.io or installed using the `curl` command without specifying `-c current`. Packages in `stable` are no longer available in `current`.
 
 Additionally, periodically Chef will update the desired versions of chef components and check that in to `master`, triggering a new build with the updated components in it.
 
@@ -170,25 +177,20 @@ After each "official" stable release we need to bump the minor version. To do th
 
 Submit a PR with the changes made by the above.
 
-## Branch Structure
+## Addressing a Regression
 
-We develop and ship the current release of Chef off the master branch of this repository. Our goal is that master should always be in a shipable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-13 or chef-12). We do not perform direct development on these stable branches except to resolve build failures. Instead we backport fixes from our master branch to these stable branches. Stable branches receive critical bugfixes and security releases and stable Chef releases are made as necessary for security purposes.
+Sometimes, regressions split through the cracks. Since new functionality is always being added and the minor version is bumped immediately after release, we can't simply roll forward. In this scenario, we'll need to perform a special regression release process. In the example that follows, the stable release with a regression is `1.10.60` while master is currently sitting at `1.11.30`. *Note:* To perform this process, you must be a Chef employee.
 
-## Backporting Fixes to Stable Releases
-
-If there is a critical fix you believe should be backported from master to a stable branch please follow these steps to backport your change:
-
-1. Ask in the #chef-dev channel on [Chef Community Slack](https://community-slack.chef.io/) if this is an appropriate change to backport.
-3. Inspect the Git history and find the `SHA`(s) associated with the fix.
-4. Backport the fix to a branch via cherry-pick:
-  1. Check out the stable release branch: `git checkout chef-13`
-  1. Create a branch for your backport: `git checkout -b my_great_bug_packport`
+1. If the regression has not already been addressed, open a Pull Request against master with the fix.
+2. Wait until that Pull Request has been merged and `1.11.31` has passed all the necessary tests and is available in the current channel.
+3. Inspect the Git history and find the `SHA` associated with the Merge Commit for the Pull Request above.
+4. Apply the fix for the regression via a cherry-pick:
+  1. Check out the stable release tag: `git checkout v1.10.60`
   2. Cherry Pick the SHA with the fix: `git cherry-pick SHA`
   3. Address any conflicts (if necessary)
-  5. Push the new branch to your origin: `git push origin`
-5. Open a PR for your backport
-  1. The PR title should be `Backport: ORIGINAL_PR_TEXT`
-  2. The description should link to the original PR and include a description of why it needs to be backported
+  4. Tag the sha with the appropriate version: `git tag -a v1.10.61 -m "Release v1.10.61"`
+  5. Push the new tag to origin: `git push origin --tags`
+5. Log in to Jenkins and trigger a `chef-trigger-release` job specifying the new tag as the `GIT_REF`.
 
 ## Component Versions
 
@@ -225,7 +227,7 @@ Chef - A configuration management system
 |                      |                                          |
 |:---------------------|:-----------------------------------------|
 | **Author:**          | Adam Jacob (<adam@chef.io>)
-| **Copyright:**       | Copyright 2008-2018, Chef Software, Inc.
+| **Copyright:**       | Copyright 2008-2016, Chef Software, Inc.
 | **License:**         | Apache License, Version 2.0
 
 ```

data/Rakefile

@@ -1,7 +1,7 @@
 #
 # Author:: Adam Jacob (<adam@chef.io>)
 # Author:: Daniel DeLeo (<dan@chef.io>)
-# Copyright:: Copyright 2008-2018, Chef Software Inc.
+# Copyright:: Copyright 2008-2016, Chef Software Inc.
 # License:: Apache License, Version 2.0
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
@@ -17,24 +17,24 @@
 # limitations under the License.
 #
 
+VERSION = IO.read(File.expand_path("../VERSION", __FILE__)).strip
+
+require "rubygems"
+require "chef/version"
+require "chef-config/package_task"
+require "rdoc/task"
 require_relative "tasks/rspec"
 require_relative "tasks/maintainers"
+require_relative "tasks/cbgb"
 require_relative "tasks/dependencies"
 require_relative "tasks/announce"
 
-# hack the chef-config install to run before the traditional install task
-task :super_install do
-  chef_config_path = ::File.join(::File.dirname(__FILE__), "chef-config")
-  Dir.chdir(chef_config_path)
-  sh("rake install")
+ChefConfig::PackageTask.new(File.expand_path("..", __FILE__), "Chef", "chef") do |package|
+  package.component_paths = ["chef-config"]
+  package.generate_version_class = true
+  package.use_versionstring = true
 end
 
-task install: :super_install
-
-# make sure we build the correct gemspec on windows
-gemspec = Gem.win_platform? ? "chef-universal-mingw32" : "chef"
-Bundler::GemHelper.install_tasks name: gemspec
-
 task :pedant, :chef_zero_spec
 
 task :build_eventlog do
@@ -56,17 +56,21 @@ begin
     task.options += ["--display-cop-names", "--no-color"]
   end
 rescue LoadError
-  puts "chefstyle/rubocop is not available. bundle install first to make sure all dependencies are installed."
+  puts "chefstyle/rubocop is not available.  gem install chefstyle to do style checking."
 end
 
 begin
   require "yard"
-  DOC_FILES = [ "spec/tiny_server.rb", "lib/**/*.rb" ].freeze
+  DOC_FILES = [ "README.rdoc", "LICENSE", "spec/tiny_server.rb", "lib/**/*.rb" ]
+  namespace :yard do
+    desc "Create YARD documentation"
 
-  YARD::Rake::YardocTask.new(:docs) do |t|
-    t.files = DOC_FILES
-    t.options = ["--format", "html"]
+    YARD::Rake::YardocTask.new(:html) do |t|
+      t.files = DOC_FILES
+      t.options = ["--format", "html"]
+    end
   end
+
 rescue LoadError
-  puts "yard is not available. bundle install first to make sure all dependencies are installed."
+  puts "yard is not available. (sudo) gem install yard to generate yard documentation."
 end

data/VERSION

@@ -0,0 +1 @@
+14.0.190

data/acceptance/.shared/kitchen_acceptance/.kitchen.digitalocean.yml

@@ -0,0 +1,33 @@
+# Not quite ready yet
+
+driver:
+  name: digitalocean
+  digitalocean_access_token: <%= ENV['DIGITALOCEAN_API_TOKEN'] %>
+  region: <%= ENV['DIGITALOCEAN_REGION'] %>
+  size: 2gb
+  ssh_key_ids: <%= ENV['DIGITALOCEAN_SSH_KEYS'] %>
+  transport:
+    ssh_key: <%= ENV['DIGITALOCEAN_SSH_KEY_PATH'] %>
+
+provisioner:
+  name: chef_zero
+  product_name: chef
+  product_version: latest
+  channel: current
+
+# busser installation relies on this
+<% if ENV["KITCHEN_CHEF_PRODUCT"] %>
+verifier:
+  chef_omnibus_root: "/opt/<%= ENV["KITCHEN_CHEF_PRODUCT"] %>"
+<% end %>
+
+platforms:
+<% %w(centos-6.5 centos-7.0
+      fedora-21
+      debian-8.1
+      ubuntu-12.04 ubuntu-14.04 ubuntu-15.10
+).each do |platform| %>
+  - name: #{platform}
+    driver_config:
+      image: <%= "#{platform.gsub('.', '-')}-x64" %>
+<% end %>