File: README.md

package info (click to toggle)
ruby-cheffish 13.1.0-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 564 kB
  • sloc: ruby: 6,886; makefile: 10
file content (120 lines) | stat: -rw-r--r-- 4,971 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
# Cheffish

[![Status](https://travis-ci.org/chef/cheffish.svg?branch=master)](https://travis-ci.org/chef/cheffish)
[![Gem Version](https://badge.fury.io/rb/cheffish.svg)](http://badge.fury.io/rb/cheffish)

This library provides a variety of convergent resources for interacting with the Chef Server; along the way, it happens to provide some very useful and sophisticated ways of running Chef resources as recipes in RSpec examples.

**This document may have errors, but it should have enough pointers to get you oriented.**

There are essentially 3 collections here:

## Resource/Provider Pairs for Manipulating Chef Servers

You'd use these in recipes/cookbooks. They are documented on the [main Chef docs site](https://docs.chef.io).

- [chef_acl](https://docs.chef.io/resource_chef_acl.html)
- [chef_client](https://docs.chef.io/resource_chef_client.html)
- [chef_container](https://docs.chef.io/resource_chef_container.html)
- [chef_data_bag](https://docs.chef.io/resource_chef_data_bag.html)
- [chef_data_bag_item](https://docs.chef.io/resource_chef_data_bag_item.html)
- [chef_environment](https://docs.chef.io/resource_chef_environment.html)
- [chef_group](https://docs.chef.io/resource_chef_group.html)
- [chef_mirror](https://docs.chef.io/resource_chef_mirror.html)
- [chef_node](https://docs.chef.io/resource_chef_node.html)
- [chef_organization](https://docs.chef.io/resource_chef_organization.html)
- [chef_resolved_cookbooks](https://docs.chef.io/resource_chef_resolved_cookbooks.html)
- [chef_role](https://docs.chef.io/resource_chef_role.html)
- [chef_user](https://docs.chef.io/resource_chef_user.html)
- [private_key](https://docs.chef.io/resource_private_key.html)
- [public_key](https://docs.chef.io/resource_public_key.html)

## Base/Helper Classes

To support the resource/provider pairs.


## RSpec Support

Most of these RSpec...things were developed for testing the resource/provider pairs above; *however*, you can also `require cheffish/rspec/chef_run_support` for any RSpec `expect`s you'd like, as we do for `chef-provisioning` and its drivers (especially `chef-provisioning-aws`).

The awesomeness here is that instead of instantiating a `run_context` and a `node` and a `resource` as Ruby objects, you can test your resources in an actual recipe:

```ruby
when_the_chef_12_server "exists", organization: 'some-org', server_scope: :context, port: 8900..9000 do
  file "/tmp/something_important.json" do
    content "A resource in its native environment."
  end
end
```

An enclosing context that spins up `chef-zero` (local mode) Chef servers as dictated by `server_scope`. `Chef::Config` will be set up with the appropriate server URLs (see the `with_*` operators below).

`server_scope`:
- `:context`
- `:example` *[default?]*
- ?

`port`:
- port number (8900 is the default)
- port range (server will continue trying up this range until it finds a free port)

```ruby
expect_recipe {
  # unquoted recipe DSL here.
}.to be_truthy    # or write your own matchers.
```

Converges the recipe using `expect()` (parentheses), which tests for a value and **cannot** be used with `raise_error`.

```ruby
expect_converge {
  # unquoted recipe DSL here.
}.to raise_error(ArgumentException)
```

Converges the recipe using `expect{ }` (curly brackets), which wraps the block in a `begin..rescue..end` to detect when the block raises an exception; hence, this is **only** for `raise_error`.

The blocks for the following appear to be mostly optional: what they actually do is set the `Chef::Config` variable in the name to the given value, and if you provide a block, the change is scoped to that block. Probably this would be clearer if it were aliased to (and preferring) `using` rather than `with`.

- with_chef_server(server_url, options = {}, &block)
- with_chef_local_server(options, &block)
- with_chef_environment(name, &block)
- with_chef_data_bag_item_encryption(encryption_options, &block)
- with_chef_data_bag(name)
  - Takes a block, though this is not noted in the method signature.



get_private_key(name)


### RSpec matchers

These are used with `expect_recipe` or `expect_converge`:

```ruby
expect_recipe {
  file "/tmp/a_file.json" do
    content "Very important content."
  end
}.to be_idempotent.and emit_no_warnings_or_errors
```

`be_idempotent`

- Runs the provided recipe *again* (`expect_(recipe|converge)` ran it the first time) and asks the Chef run if it updated anything (using `updated?`, which appears to be defined on `Chef::Resource` instead of `Chef::Client`, so there's some clarification to be done there); the matcher is satisfied if the answer is "no."


`emit_no_warnings_or_errors`

- Greps the Chef client run's log output for WARN/ERROR lines; matcher is satisfied if there aren't any.

`have_updated`

- Sifts the recipe's event stream(!) to determine if any resources were updated; matcher is satisfied is the answer is "yes."
- This is *not* the opposite of `be_idempotent`.

`partially_match`

- TBD