chef-dk 0.12.0 → 0.13.21

Sign up to get free protection for your applications and to get access to all the features.
data/README.md CHANGED
@@ -1,307 +1,458 @@
1
- # Chef Development Kit
2
-
3
- Chef Development Kit (ChefDK) brings Chef and the development tools developed by the Chef Community together and acts as the consistent interface to this awesomeness. This awesomeness is composed of:
4
-
5
- * [Chef][]
6
- * [Berkshelf][]
7
- * [Test Kitchen][]
8
- * [ChefSpec][]
9
- * [Foodcritic][]
10
-
11
- This repository contains the code for the `chef` command. The full
12
- package is built with omnibus. Project and component build definitions
13
- are in the omnibus directory in this repo.
14
-
15
- ## Installation
16
-
17
- You can get the [latest release of ChefDK from the downloads page][ChefDK].
18
-
19
- On Mac OS X, you can also use [homebrew-cask](http://caskroom.io)
20
- to `brew cask install chefdk`.
21
-
22
- Once you install the package, the `chef-client` suite, `berks`,
23
- `kitchen`, and this application (`chef`) will be symlinked into your
24
- system bin directory, ready to use.
25
-
26
- ### Pre-release Candidates
27
-
28
- The following commands will download the latest ChefDK package from the `current` channel. The `current` channel holds builds that have passed testing and are candidates for release.
29
-
30
- #### Linux and OS/X:
31
-
32
- In a terminal, run:
33
-
34
- `curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -c current -P chefdk`
35
-
36
- To download a specific version, append the `-v` flag. EG, `-v 0.9.0`.
37
-
38
- #### Windows
39
-
40
- Open up a Powershell command prompt as Administrator and run:
41
-
42
- `. { iwr -useb https://omnitruck.chef.io/install.ps1 } | iex; install -channel current -project chefdk`
43
-
44
- To download a specific version, append the `-version` flag. EG, `-version 0.9.0`.
45
-
46
- ## Usage
47
-
48
- For help with [Berkshelf][], [Test Kitchen][], [ChefSpec][] or [Foodcritic][],
49
- visit those projects' homepages for documentation and guides. For help with
50
- `chef-client` and `knife`, visit the [Chef documentation][]
51
- and [Learn Chef][].
52
-
53
- ### The `chef` Command
54
-
55
- Our goal is for `chef` to become a workflow tool that builds on the
56
- ideas of Berkshelf to provide an awesome experience that encourages
57
- quick iteration and testing (and makes those things easy) and provides a
58
- way to easily, reliably, and repeatably roll out new automation code to
59
- your infrastructure.
60
-
61
- While we've got a long way to go before we reach that goal we do have
62
- some helpful bits of functionality already included in the `chef`
63
- command:
64
-
65
- #### `chef generate`
66
- The generate subcommand generates skeleton Chef code
67
- layouts so you can skip repetitive boilerplate and get down to
68
- automating your infrastructure quickly. Unlike other generators, it only
69
- generates the minimum required files when creating a cookbook so you can
70
- focus on the task at hand without getting overwhelmed by stuff you don't
71
- need.
72
-
73
- The following generators are built-in:
74
-
75
- * `chef generate app` Creates an "application" layout that supports
76
- multiple cookbooks. This is a somewhat experimental compromise between
77
- the one-repo-per-cookbook and monolithic-chef-repo styles of cookbook
78
- management.
79
-
80
- * `chef generate cookbook` Creates a single cookbook.
81
- * `chef generate recipe` Creates a new recipe file in an existing
82
- cookbook.
83
- * `chef generate attribute` Creates a new attributes file in an existing
84
- cookbook.
85
- * `chef generate template` Creates a new template file in an existing
86
- cookbook. Use the `-s SOURCE` option to copy a source file's content to
87
- populate the template.
88
- * `chef generate file` Creates a new cookbook file in an existing
89
- cookbook. Supports the `-s SOURCE` option similar to template.
90
- * `chef generate lwrp` Creates a new LWRP resource and provider in an
91
- existing cookbook.
92
-
93
- The `chef generate` command also accepts additional `--generator-arg key=value`
94
- pairs that can be used to supply ad-hoc data to a generator cookbook.
95
- For example, you might specify `--generator-arg database=mysql` and then only
96
- write a template for `recipes/mysql.rb` if `context.database == 'mysql'`.
97
-
98
- #### `chef gem`
99
- `chef gem` is a wrapper command that manages installation and updating
100
- of rubygems for the Ruby installation embedded in the ChefDK package.
101
- This allows you to install knife plugins, Test Kitchen drivers, and
102
- other Ruby applications that are not packaged with ChefDK.
103
-
104
- Gems are installed to a `.chefdk` directory in your home directory; any
105
- executables included with a gem you install will be created in
106
- `~/.chefdk/gem/ruby/2.1.0/bin`. You can run these executables with
107
- `chef exec`, or use `chef shell-init` to add ChefDK's paths to your
108
- environment. Those commands are documented below.
109
-
110
- ### `chef exec`
111
- `chef exec <command>` runs any arbitrary shell command with the PATH
112
- environment variable and the ruby environment variables (`GEM_HOME`,
113
- `GEM_PATH`, etc.) setup to point at the embedded ChefDK omnibus environment.
114
-
115
- ### `chef shell-init`
116
- `chef shell-init SHELL_NAME` emits shell commands that modify your
117
- environment to make ChefDK your primary ruby. It supports bash, zsh,
118
- fish and PowerShell (posh). For more information to help you decide if
119
- this is desirable and instructions, see "Using ChefDK as Your Primary
120
- Development Environment" below.
121
-
122
- ### `chef install`
123
- `chef install` reads a `Policyfile.rb` document, which contains a
124
- `run_list` and optional cookbook version constraints, finds a set of
125
- cookbooks that provide the desired recipes and meet dependency
126
- constraints, and emits a `Policyfile.lock.json` describing the expanded
127
- run list and locked cookbook set. The `Policyfile.lock.json` can be used
128
- to install the cookbooks on another machine. The policy lock can be
129
- uploaded to a Chef Server (via the `chef push` command) to apply the
130
- expanded run list and locked cookbook set to nodes in your
131
- infrastructure. See the POLICYFILE_README.md for further details.
132
-
133
- ### `chef push`
134
- `chef push POLICY_GROUP` uploads a Policyfile.lock.json along with the cookbooks it
135
- references to a Chef Server. The policy lock is applied to a
136
- `POLICY_GROUP`, which is a set of nodes that share the same run list and
137
- cookbook set. This command operates in compatibility mode and has the
138
- same caveats as `chef install`. See the POLICYFILE_README.md for further
139
- details.
140
-
141
- ### `chef update`
142
- `chef update` updates a Policyfile.lock.json with the latest cookbooks
143
- from upstream sources. It supports an `--attributes` flag which will
144
- cause only attributes from the Policyfile.rb to be updated.
145
-
146
- ### `chef diff`
147
- `chef diff` shows an itemized diff between Policyfile locks. It can
148
- compare Policyfile locks from local disk, git, and/or the Chef Server,
149
- based on the options given.
150
-
151
- #### `chef verify`
152
- `chef verify` tests the embedded applications. By default it runs a
153
- quick "smoke test" to verify that the embedded applications are
154
- installed correctly and can run basic commands. As an end user this is
155
- probably all you'll ever need, but `verify` can also optionally run unit
156
- and integration tests by supplying the `--unit` and `--integration`
157
- flags, respectively.
158
-
159
- *WARNING:* The integration tests will do dangerous things like start
160
- HTTP servers with access to your filesystem and even create users and
161
- groups if run with sufficient privileges. The tests may also be
162
- sensitive to your machine's configuration. If you choose to run these,
163
- we recommend to only run them on dedicated, isolated hosts (we do this
164
- in our build cluster to verify each build).
165
-
166
- ### Using ChefDK as Your Primary Development Environment
167
-
168
- By default, ChefDK only adds a few select applications to your `PATH`
169
- and packages them in such a way that they are isolated from any other
170
- Ruby development tools you have on your system. If you're happily using
171
- your system ruby, rvm, rbenv, chruby or any other development
172
- environment, you can continue to do so. Just ensure that the ChefDK
173
- provided applications appear first in your `PATH` before any
174
- gem-installed versions and you're good to go.
175
-
176
- If you'd like to use ChefDK as your primary Ruby/Chef development
177
- environment, however, you can do so by initializing your shell with
178
- ChefDK's environment.
179
-
180
- To try it temporarily, in a new terminal session, run:
181
-
182
- ```sh
183
- eval "$(chef shell-init SHELL_NAME)"
184
- ```
185
-
186
- where `SHELL_NAME` is the name of your shell (usually bash, but zsh is
187
- also common). This modifies your `PATH` and `GEM_*` environment
188
- variables to include ChefDK's paths (run without the `eval` to see the
189
- generated code). Now your default `ruby` and associated tools will be
190
- the ones from ChefDK:
191
-
192
- ```sh
193
- which ruby
194
- # => /opt/chefdk/embedded/bin/ruby
195
- ```
196
-
197
- To add ChefDK to your shell's environment permanently, add the
198
- initialization step to your shell's profile:
199
-
200
- ```sh
201
- echo 'eval "$(chef shell-init SHELL_NAME)"' >> ~/.YOUR_SHELL_PROFILE
202
- ```
203
-
204
- Where `YOUR_SHELL_PROFILE` is `~/.bash_profile` for most bash users,
205
- `~/.zshrc` for zsh, and `~/.bashrc` on Ubuntu.
206
-
207
- #### Powershell
208
-
209
- You can use `chef shell-init` with PowerShell on Windows.
210
-
211
- To try it in your current session:
212
-
213
- ```posh
214
- chef shell-init powershell | Invoke-Expression
215
- ```
216
-
217
- To enable it permanently:
218
-
219
- ```posh
220
- "chef shell-init powershell | Invoke-Expression" >> $PROFILE
221
- ```
222
-
223
- #### Fish
224
-
225
- `chef shell-init` also supports fish.
226
-
227
- To try it:
228
-
229
- ```fish
230
- eval (chef shell-init fish)
231
- ```
232
-
233
- To permanently enable:
234
-
235
- ```fish
236
- echo 'eval (chef shell-init SHELL_NAME)' >> ~/.config/fish/config.fish
237
- ```
238
-
239
- ## Uninstallation Instructions
240
-
241
- ### Mac OS X
242
-
243
- You can uninstall Chef Development Kit on Mac using the below commands.
244
-
245
- First, remove the main package files:
246
-
247
- ```sh
248
- # Remove the installed files
249
- sudo rm -rf /opt/chefdk
250
-
251
- # Remove the system installation entry
252
- sudo pkgutil --forget com.getchef.pkg.chefdk
253
- ```
254
-
255
- Next, remove the symlinks which the Chef Development Kit installs. The location for these differs based on your OS X version.
256
-
257
- Pre-El Capitan:
258
-
259
- ```sh
260
- # Symlinks are in /usr/bin
261
- ls -la /usr/bin | egrep '/opt/chefdk' | awk '{ print $9 }' | sudo xargs -I % rm -f /usr/bin/%
262
- ```
263
-
264
- Post-El Capitan:
265
-
266
- ```sh
267
- # Symlinks are in /usr/local/bin
268
- ls -la /usr/local/bin | egrep '/opt/chefdk' | awk '{ print $9 }' | sudo xargs -I % rm -f /usr/local/bin/%
269
- ```
270
-
271
- ### Windows
272
-
273
- You can use `Add / Remove Programs` on Windows to remove the Chef Development
274
- Kit from your system.
275
-
276
- ### RHEL
277
-
278
- You can use `rpm` to uninstall Chef Development Kit on RHEL based systems:
279
-
280
- ```sh
281
- rpm -qa *chefdk*
282
- yum remove <package>
283
- rm -rf /opt/chefdk
284
- rm -rf ~/.chefdk
285
- ```
286
-
287
- ### Ubuntu
288
-
289
- You can use `dpkg` to uninstall Chef Development Kit on Ubuntu based systems:
290
-
291
- ```sh
292
- dpkg --list | grep chefdk # or dpkg --status chefdk
293
-
294
- # Purge chefdk from the system.
295
- # see man dkpg for details
296
- dpkg -P chefdk
297
- ```
298
- - - -
299
-
300
- [Berkshelf]: http://berkshelf.com "Berkshelf"
301
- [Chef]: https://www.chef.io "Chef"
302
- [ChefDK]: https://downloads.chef.io/chef-dk "Chef Development Kit"
303
- [Chef Documentation]: https://docs.chef.io "Chef Documentation"
304
- [ChefSpec]: http://chefspec.org "ChefSpec"
305
- [Foodcritic]: http://foodcritic.io "Foodcritic"
306
- [Learn Chef]: https://learn.chef.io "Learn Chef"
307
- [Test Kitchen]: http://kitchen.ci "Test Kitchen"
1
+ # Chef Development Kit
2
+
3
+ Chef Development Kit (ChefDK) brings Chef and the development tools developed by the Chef Community together and acts as the consistent interface to this awesomeness. This awesomeness is composed of:
4
+
5
+ * [Chef][]
6
+ * [Berkshelf][]
7
+ * [Test Kitchen][]
8
+ * [ChefSpec][]
9
+ * [Foodcritic][]
10
+
11
+ This repository contains the code for the `chef` command. The full
12
+ package is built with omnibus. Project and component build definitions
13
+ are in the omnibus directory in this repository.
14
+
15
+ ## Installation
16
+
17
+ You can get the [latest release of ChefDK from the downloads page][ChefDK].
18
+
19
+ On Mac OS X, you can also use [homebrew-cask](http://caskroom.io)
20
+ to `brew cask install chefdk`.
21
+
22
+ Once you install the package, the `chef-client` suite, `berks`,
23
+ `kitchen`, and this application (`chef`) will be symlinked into your
24
+ system bin directory, ready to use.
25
+
26
+ ### Pre-release Candidates
27
+
28
+ The following commands will download the latest ChefDK package from the `current` channel. The `current` channel holds builds that have passed testing and are candidates for release.
29
+
30
+ #### Linux and OS/X:
31
+
32
+ In a terminal, run:
33
+
34
+ `curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -c current -P chefdk`
35
+
36
+ To download a specific version, append the `-v` flag. EG, `-v 0.9.0`.
37
+
38
+ #### Windows
39
+
40
+ Open up a Powershell command prompt as Administrator and run:
41
+
42
+ `. { iwr -useb https://omnitruck.chef.io/install.ps1 } | iex; install -channel current -project chefdk`
43
+
44
+ To download a specific version, append the `-version` flag. EG, `-version 0.9.0`.
45
+
46
+ ## Usage
47
+
48
+ For help with [Berkshelf][], [Test Kitchen][], [ChefSpec][] or [Foodcritic][],
49
+ visit those projects' homepages for documentation and guides. For help with
50
+ `chef-client` and `knife`, visit the [Chef documentation][]
51
+ and [Learn Chef][].
52
+
53
+ ### The `chef` Command
54
+
55
+ Our goal is for `chef` to become a workflow tool that builds on the
56
+ ideas of Berkshelf to provide an awesome experience that encourages
57
+ quick iteration and testing (and makes those things easy) and provides a
58
+ way to easily, reliably, and repeatably roll out new automation code to
59
+ your infrastructure.
60
+
61
+ While we've got a long way to go before we reach that goal we do have
62
+ some helpful bits of functionality already included in the `chef`
63
+ command:
64
+
65
+ #### `chef generate`
66
+ The generate subcommand generates skeleton Chef code
67
+ layouts so you can skip repetitive boilerplate and get down to
68
+ automating your infrastructure quickly. Unlike other generators, it only
69
+ generates the minimum required files when creating a cookbook so you can
70
+ focus on the task at hand without getting overwhelmed by stuff you don't
71
+ need.
72
+
73
+ The following generators are built-in:
74
+
75
+ * `chef generate app` Creates an "application" layout that supports
76
+ multiple cookbooks. This is a somewhat experimental compromise between
77
+ the one-repo-per-cookbook and monolithic-chef-repo styles of cookbook
78
+ management.
79
+
80
+ * `chef generate cookbook` Creates a single cookbook.
81
+ * `chef generate recipe` Creates a new recipe file in an existing
82
+ cookbook.
83
+ * `chef generate attribute` Creates a new attributes file in an existing
84
+ cookbook.
85
+ * `chef generate template` Creates a new template file in an existing
86
+ cookbook. Use the `-s SOURCE` option to copy a source file's content to
87
+ populate the template.
88
+ * `chef generate file` Creates a new cookbook file in an existing
89
+ cookbook. Supports the `-s SOURCE` option similar to template.
90
+ * `chef generate lwrp` Creates a new LWRP resource and provider in an
91
+ existing cookbook.
92
+
93
+ The `chef generate` command also accepts additional `--generator-arg key=value`
94
+ pairs that can be used to supply ad-hoc data to a generator cookbook.
95
+ For example, you might specify `--generator-arg database=mysql` and then only
96
+ write a template for `recipes/mysql.rb` if `context.database == 'mysql'`.
97
+
98
+ #### `chef gem`
99
+ `chef gem` is a wrapper command that manages installation and updating
100
+ of rubygems for the Ruby installation embedded in the ChefDK package.
101
+ This allows you to install knife plugins, Test Kitchen drivers, and
102
+ other Ruby applications that are not packaged with ChefDK.
103
+
104
+ Gems are installed to a `.chefdk` directory in your home directory; any
105
+ executables included with a gem you install will be created in
106
+ `~/.chefdk/gem/ruby/2.1.0/bin`. You can run these executables with
107
+ `chef exec`, or use `chef shell-init` to add ChefDK's paths to your
108
+ environment. Those commands are documented below.
109
+
110
+ ### `chef exec`
111
+ `chef exec <command>` runs any arbitrary shell command with the PATH
112
+ environment variable and the ruby environment variables (`GEM_HOME`,
113
+ `GEM_PATH`, etc.) setup to point at the embedded ChefDK omnibus environment.
114
+
115
+ ### `chef shell-init`
116
+ `chef shell-init SHELL_NAME` emits shell commands that modify your
117
+ environment to make ChefDK your primary ruby. It supports bash, zsh,
118
+ fish and PowerShell (posh). For more information to help you decide if
119
+ this is desirable and instructions, see "Using ChefDK as Your Primary
120
+ Development Environment" below.
121
+
122
+ ### `chef install`
123
+ `chef install` reads a `Policyfile.rb` document, which contains a
124
+ `run_list` and optional cookbook version constraints, finds a set of
125
+ cookbooks that provide the desired recipes and meet dependency
126
+ constraints, and emits a `Policyfile.lock.json` describing the expanded
127
+ run list and locked cookbook set. The `Policyfile.lock.json` can be used
128
+ to install the cookbooks on another machine. The policy lock can be
129
+ uploaded to a Chef Server (via the `chef push` command) to apply the
130
+ expanded run list and locked cookbook set to nodes in your
131
+ infrastructure. See the POLICYFILE_README.md for further details.
132
+
133
+ ### `chef push`
134
+ `chef push POLICY_GROUP` uploads a Policyfile.lock.json along with the cookbooks it
135
+ references to a Chef Server. The policy lock is applied to a
136
+ `POLICY_GROUP`, which is a set of nodes that share the same run list and
137
+ cookbook set. This command operates in compatibility mode and has the
138
+ same caveats as `chef install`. See the POLICYFILE_README.md for further
139
+ details.
140
+
141
+ ### `chef update`
142
+ `chef update` updates a Policyfile.lock.json with the latest cookbooks
143
+ from upstream sources. It supports an `--attributes` flag which will
144
+ cause only attributes from the Policyfile.rb to be updated.
145
+
146
+ ### `chef diff`
147
+ `chef diff` shows an itemized diff between Policyfile locks. It can
148
+ compare Policyfile locks from local disk, git, and/or the Chef Server,
149
+ based on the options given.
150
+
151
+ #### `chef verify`
152
+ `chef verify` tests the embedded applications. By default it runs a
153
+ quick "smoke test" to verify that the embedded applications are
154
+ installed correctly and can run basic commands. As an end user this is
155
+ probably all you'll ever need, but `verify` can also optionally run unit
156
+ and integration tests by supplying the `--unit` and `--integration`
157
+ flags, respectively.
158
+
159
+ *WARNING:* The integration tests will do dangerous things like start
160
+ HTTP servers with access to your filesystem and even create users and
161
+ groups if run with sufficient privileges. The tests may also be
162
+ sensitive to your machine's configuration. If you choose to run these,
163
+ we recommend to only run them on dedicated, isolated hosts (we do this
164
+ in our build cluster to verify each build).
165
+
166
+ ### Using ChefDK as Your Primary Development Environment
167
+
168
+ By default, ChefDK only adds a few select applications to your `PATH`
169
+ and packages them in such a way that they are isolated from any other
170
+ Ruby development tools you have on your system. If you're happily using
171
+ your system ruby, rvm, rbenv, chruby or any other development
172
+ environment, you can continue to do so. Just ensure that the ChefDK
173
+ provided applications appear first in your `PATH` before any
174
+ gem-installed versions and you're good to go.
175
+
176
+ If you'd like to use ChefDK as your primary Ruby/Chef development
177
+ environment, however, you can do so by initializing your shell with
178
+ ChefDK's environment.
179
+
180
+ To try it temporarily, in a new terminal session, run:
181
+
182
+ ```sh
183
+ eval "$(chef shell-init SHELL_NAME)"
184
+ ```
185
+
186
+ where `SHELL_NAME` is the name of your shell (usually bash, but zsh is
187
+ also common). This modifies your `PATH` and `GEM_*` environment
188
+ variables to include ChefDK's paths (run without the `eval` to see the
189
+ generated code). Now your default `ruby` and associated tools will be
190
+ the ones from ChefDK:
191
+
192
+ ```sh
193
+ which ruby
194
+ # => /opt/chefdk/embedded/bin/ruby
195
+ ```
196
+
197
+ To add ChefDK to your shell's environment permanently, add the
198
+ initialization step to your shell's profile:
199
+
200
+ ```sh
201
+ echo 'eval "$(chef shell-init SHELL_NAME)"' >> ~/.YOUR_SHELL_PROFILE
202
+ ```
203
+
204
+ Where `YOUR_SHELL_PROFILE` is `~/.bash_profile` for most bash users,
205
+ `~/.zshrc` for zsh, and `~/.bashrc` on Ubuntu.
206
+
207
+ #### Powershell
208
+
209
+ You can use `chef shell-init` with PowerShell on Windows.
210
+
211
+ To try it in your current session:
212
+
213
+ ```posh
214
+ chef shell-init powershell | Invoke-Expression
215
+ ```
216
+
217
+ To enable it permanently:
218
+
219
+ ```posh
220
+ "chef shell-init powershell | Invoke-Expression" >> $PROFILE
221
+ ```
222
+
223
+ #### Fish
224
+
225
+ `chef shell-init` also supports fish.
226
+
227
+ To try it:
228
+
229
+ ```fish
230
+ eval (chef shell-init fish)
231
+ ```
232
+
233
+ To permanently enable:
234
+
235
+ ```fish
236
+ echo 'eval (chef shell-init SHELL_NAME)' >> ~/.config/fish/config.fish
237
+ ```
238
+
239
+ ## Uninstallation Instructions
240
+
241
+ ### Mac OS X
242
+
243
+ You can uninstall Chef Development Kit on Mac using the below commands.
244
+
245
+ First, remove the main package files:
246
+
247
+ ```sh
248
+ # Remove the installed files
249
+ sudo rm -rf /opt/chefdk
250
+
251
+ # Remove the system installation entry
252
+ sudo pkgutil --forget com.getchef.pkg.chefdk
253
+ ```
254
+
255
+ Next, remove the symlinks which the Chef Development Kit installs. The location for these differs based on your OS X version.
256
+
257
+ Pre-El Capitan:
258
+
259
+ ```sh
260
+ # Symlinks are in /usr/bin
261
+ ls -la /usr/bin | egrep '/opt/chefdk' | awk '{ print $9 }' | sudo xargs -I % rm -f /usr/bin/%
262
+ ```
263
+
264
+ Post-El Capitan:
265
+
266
+ ```sh
267
+ # Symlinks are in /usr/local/bin
268
+ ls -la /usr/local/bin | egrep '/opt/chefdk' | awk '{ print $9 }' | sudo xargs -I % rm -f /usr/local/bin/%
269
+ ```
270
+
271
+ ### Windows
272
+
273
+ You can use `Add / Remove Programs` on Windows to remove the Chef Development
274
+ Kit from your system.
275
+
276
+ ### RHEL
277
+
278
+ You can use `rpm` to uninstall Chef Development Kit on RHEL based systems:
279
+
280
+ ```sh
281
+ rpm -qa *chefdk*
282
+ yum remove <package>
283
+ rm -rf /opt/chefdk
284
+ rm -rf ~/.chefdk
285
+ ```
286
+
287
+ ### Ubuntu
288
+
289
+ You can use `dpkg` to uninstall Chef Development Kit on Ubuntu based systems:
290
+
291
+ ```sh
292
+ dpkg --list | grep chefdk # or dpkg --status chefdk
293
+
294
+ # Purge chefdk from the system.
295
+ # see man dkpg for details
296
+ dpkg -P chefdk
297
+ ```
298
+
299
+ # For ChefDK Developers
300
+
301
+ ## Building the ChefDK
302
+
303
+ To build the chef-dk, we use the omnibus system. Go to the [omnibus README](omnibus/README.md) to find out how to build!
304
+
305
+ ## Updating Dependencies
306
+
307
+ If you want to change our constraints (change which packages and versions we accept in the chef-dk), there are several places to do so:
308
+
309
+ * To add or remove a package from the chef-dk, or update its version, edit [Gemfile](Gemfile).
310
+ * To change the version of binary packages, edit [version_policy.rb](version_policy.rb).
311
+ * To add new packages to the chef-dk, edit [omnibus/config/projects/chefdk.rb](omnibus/config/projects/chefdk.rb).
312
+
313
+ Once you've made any changes you want, you have to update the lockfiles that actually drive the build:
314
+ * To update the chef-dk's dependencies to the very latest versions available, run `rake bundle:update`.
315
+ * To update the chef-dk's dependencies *conservatively* (changing as little as possible), run `rake bundle:install`.
316
+ * To update specific gems only, run `rake bundle:update[gem1 gem2 ...]`
317
+ * **`bundle update` and `bundle install` will *not* work, on purpose:** the rake task handles both the windows and non-windows lockfiles and updates them in sync.
318
+
319
+ *
320
+
321
+
322
+ To perform a full update of all dependencies everywhere, run `rake dependencies`. This will update the `Gemfile.lock`, `Gemfile.windows.lock`, `omnibus/Gemfile.lock`, `acceptance/Gemfile.lock`, `omnibus/Berksfile.lock`, and `omnibus_overrides.rb`. It will also show you any outdated dependencies due to conflicting constraints. Some outdated dependencies are to be expected; it will inform you if any new ones appear that we don't know about, and tell you how to proceed.
323
+
324
+ # How the ChefDK Builds and Versions
325
+
326
+ The ChefDK is an amalgam of many components. These components update all the time, necessitating new builds. This is an overview of the process of versioning, building and releasing the ChefDK.
327
+
328
+ ## ChefDK Packages
329
+
330
+ The ChefDK is distributed as packages for debian, rhel, ubuntu, windows and os/x. It includes a large number of components from various sources, and these are versioned and maintained separately from the chef-dk project, which bundles them all together conveniently for the user.
331
+
332
+ These packages go through several milestones:
333
+ - `master`: When code is checked in to master, the patch version of chef-dk 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.
334
+ - `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.
335
+ - `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://omnitruck.chef.io/install.sh | sudo bash -s -- -c current -P chefdk`
336
+ - `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`.
337
+
338
+ Additionally, periodically Chef will update the desired versions of chef-dk components and check that in to `master`, triggering a new build with the updated components in it.
339
+
340
+ ## Automated Version Bumping
341
+
342
+ Whenever a change is checked in to `master`, the patch version of `chef-dk` is bumped. To do this, the `lita-versioner` bot listens to github for merged PRs, and when it finds one, takes these actions:
343
+
344
+ 1. Bumps the patch version in `lib/chef-dk/version.rb` (e.g. 0.9.14 -> 0.9.15).
345
+ 2. Runs `rake dependencies:update_conservative` to update the `Gemfile.lock` and `Gemfile.windows.lock` to include the new version.
346
+ 3. Pushes to `master` and submits a new build to Chef's Jenkins cluster.
347
+
348
+ ## Component Versions
349
+
350
+ The chef-dk has two sorts of component: ruby components like `berkshelf` and `test-kitchen`, and binary components like `openssl` and even `ruby` itself.
351
+
352
+ In general, you can find all chef-dk desired versions in the [Gemfile](Gemfile) and [version_policy.rb](version_policy.rb) files. The [Gemfile.lock](Gemfile.lock) is the locked version of the Gemfile, and [omnibus_overrides](omnibus_overrides.rb) is the locked version of omnibus. [build](omnibus/Gemfile) and [test](acceptance/Gemfile) Gemfiles and [Berksfile](omnibus/Berksfile) version the toolset we use to build and test.
353
+
354
+ ### Binary Components
355
+
356
+ The versions of binary components (as well as rubygems and bundler, which can't be versioned in a Gemfile) are stored in [version_policy.rb](version_policy.rb) (the `OMNIBUS_OVERRIDES` constant) and locked in [omnibus_overrides](omnibus_overrides.rb). `rake dependencies` will update the `bundler` version, and the rest are be updated manually by Chef every so often.
357
+
358
+ These have software definitions either in [omnibus/config/software](omnibus/config/software) or, more often, in the [omnibus-software](https://github.com/chef/omnibus-software/tree/master/config/software) project.
359
+
360
+ ### Rubygems Components
361
+
362
+ Most of the actual front-facing software in the chef-dk is composed of ruby projects. berkshelf, test-kitchen and even chef itself are made of ruby gems. Chef uses the typical ruby way of controlling rubygems versions, the `Gemfile`. Specifically, the `Gemfile` at the top of the chef-dk repository governs the version of every single gem we install into the chef-dk package. It's a one-stop shop.
363
+
364
+ Our rubygems component versions are locked down with `Gemfile.lock` and `Gemfile.windows.lock` (which affects windows), and can be updated with `rake dependencies`.
365
+
366
+ There are three gems versioned outside the `Gemfile`: `rubygems`, `bundler` and `chef`. `rubygems` and `bundler` are in the `RUBYGEMS_AT_LATEST_VERSION` constant in [version_policy.rb](version-policy.rb) and locked in [omnibus_overrides](omnibus_overrides.rb). `chef`'s version is stored in the [Gemfile](Gemfile) and pins to the latest `current` build of chef (the latest one to pass tests). They are kept up to date by `rake dependencies`.
367
+
368
+ **Windows**: [Gemfile.lock](Gemfile.lock) is generated platform-agnostic. In order to keep windows versions in sync, [Gemfile.windows](Gemfile.windows) reads the generic Gemfile.lock and explicitly pins all gems to those versions, allowing bundler to bring in windows-specific versions of the gems and new deps, but requiring that all gems shared between Windows and Unix have the same version.
369
+
370
+ The tool we use to generate Windows-specific lockfiles on non-Windows machines is [tasks/bin/bundle-platform](bundle-platform), which takes the first argument and sets `Gem.platforms`, and then calls `bundle` with the remaining arguments.
371
+
372
+ ### Build Tooling Versions
373
+
374
+ Of special mention is the software we use to build omnibus itself. There are two distinct bits of code that control the versions of compilers, make, git, and other tools we use to build.
375
+
376
+ First, the Jenkins machines that run the build are configured entirely by the [opscode-ci cookbook](https://github.com/chef-cookbooks/opscode-ci) cookbook. They install most of the tools we use via `build-essentials`, and standardize the build environment so we can tear down and bring up builders at will. These machines are kept alive long-running, are periodically updated by Chef to the latest opscode-ci, omnibus and build-essentials cookbooks.
377
+
378
+ Second, the version of omnibus we use to build the chef-dk is governed by `omnibus/Gemfile`. When software definitions or the omnibus framework is updated, this is the file that drives whether we pick it up.
379
+
380
+ The omnibus tooling versions are locked down with `omnibus/Gemfile.lock`, and can be updated by running `rake dependencies`.
381
+
382
+ ### Test Versions
383
+
384
+ chef-dk is tested by the [chef-acceptance framework](https://github.com/chef/chef-acceptance), which contains suites that are run on the Jenkins test machines. The definitions of the tests are in the `acceptance` directory. The version of chef-acceptance and test-kitchen, are governed by `acceptance/Gemfile`.
385
+
386
+ The test tooling versions are locked down with `acceptance/Gemfile.lock`, which can be updated by running `rake dependencies`.
387
+
388
+ ## The Build Process
389
+
390
+ The actual ChefDK build process is done with Omnibus, and has several general steps:
391
+
392
+ 1. `bundle install` from `chef-dk/Gemfile.lock`
393
+ 2. Reinstall any gems that came from git or path using `rake install`
394
+ 3. appbundle chef, chef-dk, test-kitchen and berkshelf
395
+ 4. Put miscellaneous powershell scripts and cleanup
396
+
397
+ ### Kicking Off The Build
398
+
399
+ The build is kicked off in Jenkins by running this on the machine (which is already the correct OS and already has the correct dependencies, loaded by the `omnibus` cookbook):
400
+
401
+ ```
402
+ load-omnibus-toolchain.bat
403
+ cd chef-dk/omnibus
404
+ bundle install
405
+ bundle exec omnibus build chefdk
406
+ ```
407
+
408
+ This causes the [chefdk project definition](omnibus/config/projects/chefdk.rb) to load, which runs the [chef-dk-complete](omnibus/config/software/chef-dk-complete.rb) software definition, the primary software definition driving the whole build process. The reason we embed it all in a software definiton instead of the project is to take advantage of omnibus caching: omnibus will invalidate the entire project (and recompile ruby, openssl, and everything else) if you change anything at all in the project file. Not so with a software definition.
409
+
410
+ ### Installing the Gems
411
+
412
+ The primary build definition that installs the many ChefDK rubygems is [`software/chef-dk.rb`](omnibus/software/chef-dk.rb). This has dependencies on any binary libraries, ruby, rubygems and bundler. It has a lot of steps, so it uses a [library](omnibus/files/chef-dk/build-chef-dk.rb) to help reuse code and make it manageable to look at.
413
+
414
+ What it does:
415
+
416
+ 1. Depends on software defs for pre-cached gems (see "Gems and Caching" below).
417
+ 2. Installs all gems from the bundle:
418
+ - Sets up a `.bundle/config` ([code](omnibus/files/chef-dk/build-chef-dk.rb#L17-L39)) with --retries=4, --jobs=1, --without=development,no_<platform>, and `build.config.nokogiri` to pass.
419
+ - Sets up a common environment, standardizing the compilers and flags we use, in [`env`](omnibus/files/chef-dk-gem/build-chef-dk-gem.rb#L32-L54).
420
+ - [Runs](omnibus/config/software/chef-dk.rb#L68) `bundle install --verbose`
421
+ 3. Reinstalls any gems that were installed via path:
422
+ - [Runs](omnibus/files/chef-dk/build-chef-dk.rb#L80) `bundle list --paths` to get the installed directories of all gems.
423
+ - For each gem not installed in the main gem dir, [runs](omnibus/files/chef-dk/build-chef-dk.rb#L89) `rake install` from the installed gem directory.
424
+ - [Deletes](omnibus/files/chef-dk/build-chef-dk.rb#L139-L143) the bundler git cache and path- and git-installed gems from the build.
425
+ 4. [Creates](omnibus/files/chef-dk/build-chef-dk.rb#L102-L152) `/opt/chefdk/Gemfile` and `/opt/chefdk/Gemfile.lock` with the gems that were installed in the build.
426
+
427
+ #### Gems and Caching
428
+
429
+ Some gems take a super long time to install (particularly native-compiled ones such as nokogiri and dep-selector-libgecode) and do not change version very often. In order to avoid doing this work every time, we take advantage of omnibus caching by separating out these gems into their own software definitions. [chef-dk-gem-dep-selector-libgecode](omnibus/config/software/chef-dk-gem-dep-selector-libgecode.rb) for example.
430
+
431
+ Each of these gems uses the `config/files/chef-dk-gem/build-chef-dk-gem` library to define itself. The name of the software definition itself indicates the .
432
+
433
+ We only create software definitions for long-running gems. Everything else is just installed in the [chef-dk](omnibus/config/software/chef-dk.rb) software definition in a big `bundle install` catchall.
434
+
435
+ Most gems we just install in the single `chef-dk` software definition.
436
+
437
+ The first thing
438
+
439
+ ### Appbundling
440
+
441
+ After the gems are installed, we *appbundle* them in [chef-dk-appbundle](omnibus/config/software/chef-dk-appbundle.rb). This creates binstubs that use the bundle to pin the software .
442
+
443
+ During the process of appbundling, we update the gem's `Gemfile` to include the locks in the top level `/opt/chefdk/Gemfile.lock`, so we can guarantee they will never pick up things outside the build. We then run `bundle lock` to update the gem's `Gemfile.lock`, and `bundle check` to ensure all the gems are actually installed. The appbundler then uses these pins.
444
+
445
+ ### Other Cleanup
446
+
447
+ Finally, the chef-dk does several more steps including installing powershell scripts and shortcuts, and removing extra documentation to keep the build slim.
448
+
449
+ - - -
450
+
451
+ [Berkshelf]: http://berkshelf.com "Berkshelf"
452
+ [Chef]: https://www.chef.io "Chef"
453
+ [ChefDK]: https://downloads.chef.io/chef-dk "Chef Development Kit"
454
+ [Chef Documentation]: https://docs.chef.io "Chef Documentation"
455
+ [ChefSpec]: http://chefspec.org "ChefSpec"
456
+ [Foodcritic]: http://foodcritic.io "Foodcritic"
457
+ [Learn Chef]: https://learn.chef.io "Learn Chef"
458
+ [Test Kitchen]: http://kitchen.ci "Test Kitchen"