onceover 3.17.2 → 3.19.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (40) hide show
  1. checksums.yaml +4 -4
  2. data/.gitattributes +2 -0
  3. data/.github/workflows/tests.yaml +40 -0
  4. data/.rubocop.yml +20 -2
  5. data/Gemfile +0 -13
  6. data/README.md +201 -110
  7. data/Rakefile +8 -5
  8. data/factsets/CentOS-8.3.2011-64.json +485 -0
  9. data/factsets/Debian-10.4-64.json +476 -0
  10. data/factsets/Debian-8.11-64.json +480 -0
  11. data/factsets/Debian-9.12-64.json +476 -0
  12. data/factsets/Ubuntu-20.04-64.json +504 -0
  13. data/factsets/Windows_Server-2008r2-64.json +184 -183
  14. data/factsets/Windows_Server-2012r2-64.json +165 -164
  15. data/factsets/windows-10-64.json +104 -103
  16. data/features/cache.feature +1 -1
  17. data/features/step_definitions/cache.rb +4 -4
  18. data/features/step_definitions/common.rb +38 -10
  19. data/features/step_definitions/init.rb +2 -2
  20. data/features/windows.feature +5 -0
  21. data/features/zzz_run.feature +22 -3
  22. data/lib/onceover/controlrepo.rb +10 -4
  23. data/lib/onceover/deploy.rb +3 -1
  24. data/lib/onceover/group.rb +3 -1
  25. data/lib/onceover/rspec/formatters.rb +6 -1
  26. data/lib/onceover/runner.rb +7 -6
  27. data/lib/onceover/test.rb +3 -2
  28. data/lib/onceover/testconfig.rb +28 -5
  29. data/onceover.gemspec +5 -2
  30. data/spec/fixtures/controlrepos/basic/manifests_alternate/site.pp +2 -0
  31. data/spec/fixtures/controlrepos/caching/Puppetfile +17 -17
  32. data/spec/fixtures/controlrepos/caching/manifests/site.pp +1 -0
  33. data/spec/fixtures/controlrepos/custom_puppetfile/Puppetfile.custom +3 -0
  34. data/spec/fixtures/controlrepos/custom_puppetfile/environment.conf +7 -0
  35. data/spec/fixtures/controlrepos/windows/Puppetfile +6 -1
  36. data/spec/fixtures/controlrepos/windows/site-modules/role/manifests/choco.pp +9 -0
  37. data/templates/test_spec.rb.erb +1 -1
  38. metadata +75 -18
  39. data/.travis.yml +0 -19
  40. data/appveyor.yml +0 -38
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 2dca2d14bc7059827f3bcbe11eb8c0c00c43be5c37c45ac9fb3533562dab4e7b
4
- data.tar.gz: d45c009adb4edae1b828fee5a0b51552c02bfc4dc7eefcb5b09a1832e8509170
3
+ metadata.gz: 645e450894eb3599a076f3c32c94ad73f88ad9177bb739e7ae56964bdeab1d22
4
+ data.tar.gz: 3ff596aa3b7a2be1edf18c9407a8fefe61b354e3dfb6a9fe4ef95f1a3e0c59d0
5
5
  SHA512:
6
- metadata.gz: 13b3969909f9966f78663ba0568f96b557ef769c1a13a0d999d15d50a057ffa3584570b2c6e3c31b79aa09980c8088b62dc4ec665b073b60157243beb11d55cb
7
- data.tar.gz: 3209f3771d3db26c9ba8f40a06225ac29b452fc012c08e9dfa6ea60cb485ad173448eb9d3aa491f0ed76d5ccdb068ffde61583a1a7fbe232fe352d5cd4874960
6
+ metadata.gz: 5ec23df5e72580ffa318b881def6a89f0fa336e11476dd9ce37ebdd3611976dfb26a0b48e3395f1e6d0c031fb63aaf517efcf9c7523c199115efafb2ecbae095
7
+ data.tar.gz: 3b505e9c89887b0656d197066d36b75004b2a899eed3941c93948c2349623412a6b78036af38e02eecac1a3f7131870be8027299337b807621363304f467f228
@@ -0,0 +1,2 @@
1
+ # force LF line endings, even when on Windows
2
+ * text eol=lf
@@ -0,0 +1,40 @@
1
+ name: Tests
2
+ on:
3
+ - push
4
+ - pull_request
5
+ jobs:
6
+ full_tests:
7
+ strategy:
8
+ fail-fast: false
9
+ matrix:
10
+ os:
11
+ - windows-2016
12
+ - ubuntu-latest
13
+ - macos-latest
14
+ puppet:
15
+ - "~> 5.0"
16
+ - "~> 6.0"
17
+ - "~> 7.0"
18
+ include:
19
+ - puppet: "~> 5.0"
20
+ ruby: 2.4
21
+ - puppet: "~> 6.0"
22
+ ruby: 2.5
23
+ - puppet: "~> 7.0"
24
+ ruby: 2.7
25
+
26
+ runs-on: ${{ matrix.os }}
27
+ steps:
28
+ - uses: actions/checkout@v2
29
+ - uses: ruby/setup-ruby@v1
30
+ with:
31
+ ruby-version: ${{ matrix.ruby }}
32
+ bundler-cache: true # runs 'bundle install' and caches installed gems automatically
33
+ env:
34
+ PUPPET_VERSION: ${{ matrix.puppet }}
35
+ - name: Set long paths on Windows
36
+ if: ${{ matrix.os == 'windows-2016' }}
37
+ run: Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\FileSystem' -Name 'LongPathsEnabled' -value 1
38
+ - env:
39
+ PUPPET_VERSION: ${{ matrix.puppet }}
40
+ run: bundle exec rake full_tests
@@ -1,4 +1,6 @@
1
1
  AllCops:
2
+ TargetRubyVersion: 2.4 # this should match the oldest version in .github/workflows/tests.yaml's matrix
3
+ NewCops: enable
2
4
  Include:
3
5
  - "lib/**/*.rb"
4
6
  - "ext/**/*.rb"
@@ -10,6 +12,21 @@ AllCops:
10
12
  - "tasks/**/*"
11
13
  - "vendor/**/*"
12
14
 
15
+ # Turning off some failing checks until it is determined which one is breaking things
16
+ Style/AccessorGrouping:
17
+ Enabled: false
18
+ Style/CaseLikeIf:
19
+ Enabled: false
20
+ Style/GlobalStdStream:
21
+ Enabled: false
22
+ Style/RedundantRegexpCharacterClass:
23
+ Enabled: false
24
+ Style/SoleNestedConditional:
25
+ Enabled: false
26
+ Style/StringConcatenation:
27
+ Enabled: false
28
+ # end turning things off for debugging
29
+
13
30
  Layout/ConditionPosition:
14
31
  Enabled: true
15
32
 
@@ -19,7 +36,7 @@ Lint/ElseLayout:
19
36
  Lint/UnreachableCode:
20
37
  Enabled: true
21
38
 
22
- Lint/UselessComparison:
39
+ Lint/BinaryOperatorWithIdenticalOperands:
23
40
  Enabled: true
24
41
 
25
42
  # MAYBE useful - no return inside ensure block.
@@ -650,7 +667,8 @@ Style/ZeroLengthPredicate:
650
667
 
651
668
  Bundler/OrderedGems:
652
669
  Enabled: false
653
- # Enforce LF line endings, even when on Windows
670
+
671
+ # Enforce LF line endings, even when on Windows
654
672
  Layout/EndOfLine:
655
673
  EnforcedStyle: lf
656
674
 
data/Gemfile CHANGED
@@ -17,16 +17,3 @@ end
17
17
  if File.exist?(File.join(Dir.home, '.gemfile'))
18
18
  eval(File.read(File.join(Dir.home, '.gemfile')), binding)
19
19
  end
20
-
21
- if ENV['APPVEYOR'] == 'True'
22
- # R10k needs to be pinned to this until the next release after 3.1.1
23
- # in order to not have symlinks and therefor work on windows
24
- gem 'r10k', git: 'https://github.com/puppetlabs/r10k.git'
25
- end
26
-
27
- group :development do
28
- gem 'cucumber', '~> 2.0'
29
- gem 'pry', '~> 0.10.0'
30
- gem 'rubocop', '~> 0.82.0'
31
- gem 'rubygems-tasks', '~> 0.2.0'
32
- end
data/README.md CHANGED
@@ -2,21 +2,23 @@
2
2
 
3
3
  *The gateway drug to automated infrastructure testing with Puppet*
4
4
 
5
- Onceover is a tool to automatically run basic tests on an entire Puppet controlrepo. It includes automatic parsing of the `Puppetfile`, `environment.conf` and others in order to stop silly mistakes ever reaching your Puppet Master!
5
+ Onceover is a tool to automatically run basic tests on an entire Puppet control repository.
6
6
 
7
- **🍺🥳 New in v3.17.1: Heaps more Windows fixes! Windows code is now more likely to compile on Non-Windows.**
7
+ It includes automatic parsing of the `Puppetfile`, `environment.conf` and others in order to stop silly mistakes ever reaching your Puppet Master!
8
+
9
+ **New in v3.19.1: I've reversed the decision to have onceover use `site.pp` in the same way Puppet does. From now on your `manifest` setting in `environment.conf` will be ignored and your `site.pp` will only be used if you explicitly set the `manifest` option in the CLI or config file.**
10
+
11
+ [![Build Status](https://travis-ci.com/dylanratcliffe/onceover.svg?branch=master)](https://travis-ci.com/dylanratcliffe/onceover) [![Build status](https://ci.appveyor.com/api/projects/status/2ys2ggkgln69hmyf/branch/master?svg=true)](https://ci.appveyor.com/project/dylanratcliffe/onceover/branch/master)
8
12
 
9
13
  ## Table of Contents
10
14
 
11
15
  - [Overview](#overview)
12
16
  - [Quick Start](#quick-start)
13
- - [Installation](#installation)
14
- - [Config files](#config-files)
17
+ - [Configuration](#configuration)
15
18
  - [onceover.yaml](#onceoveryaml)
16
- - [factsets](#factsets)
17
- - [Hiera Data](#hiera-data)
18
- - [r10k](#r10k)
19
- - [r10k Config](#r10k-config)
19
+ - [Factsets](#factsets)
20
+ - [Hiera](#hiera)
21
+ - [Puppetfile](#puppetfile)
20
22
  - [Spec testing](#spec-testing)
21
23
  - [Adding your own spec tests](#adding-your-own-spec-tests)
22
24
  - [Using Workarounds](#using-workarounds)
@@ -32,120 +34,220 @@ Onceover is a tool to automatically run basic tests on an entire Puppet controlr
32
34
  - [Rake tasks](#rake-tasks)
33
35
  - [generate_fixtures](#generate_fixtures)
34
36
 
37
+ ## Overview
38
+
39
+ This gem provides a toolset for testing _Puppet control repository_ (ie. Repos used with r10k).
40
+
41
+ The main purpose of this project is to provide a set of tools to help smooth out the process of setting up and running `rspec-puppet` tests for a controlrepo.
42
+
43
+ Due to the fact that controlrepos are fairly standardised in nature it seemed ridiculous that you would need to set up the same testing framework that we would normally use within a module for a controlrepo. This is because at this level we are normally just running very basic tests that cover a lot of code. It would also mean that we would need to essentially duplicated our `Puppetfile` into a `.fixtures.yml` file, along with a few other things.
44
+
45
+ This toolset requires some [configuration](#configuration) before it can be used so definitely read that section before getting started.
46
+
35
47
  ## Quick Start
36
48
 
37
- **Note:** This assumes you are inside the root of your controlrepo.
49
+ **Note:** This assumes you are inside the root of your control-repo.
38
50
 
39
- Install the Gem:
51
+ 1. Add `onceover` to your `Gemfile`:
40
52
 
41
- `gem install onceover`
53
+ ```ruby
54
+ gem 'onceover'
55
+ ```
42
56
 
43
- Set up your config:
57
+ 1. Run _Bundler_ to install `onceover`
44
58
 
45
- `onceover init`
59
+ ```shell
60
+ bundle install
61
+ ```
46
62
 
47
- Run your spec tests!
63
+ 1. Set up your configuration
48
64
 
49
- `onceover run spec`
65
+ ```shell
66
+ bundle exec onceover init
67
+ ```
68
+ 1. Run your spec tests!
50
69
 
51
- **Hint:** Don't forget you can use Bundler to install onceover by adding this to your Gemfile:
70
+ ```shell
71
+ bundle exec onceover run spec
72
+ ```
52
73
 
53
- ```ruby
54
- gem 'onceover'
55
- ```
74
+ ## Configuration
56
75
 
57
- Here is an example using Bundler:
76
+ This project uses one main config file to determine what Puppet classes we should be testing and how: [onceover.yaml](#onceoveryaml).
58
77
 
59
- Install the Gem:
78
+ As `onceover` tests Puppet classes, it need sets of facts to compile the Puppet code against, these are stored in [factsets](#factsets).
60
79
 
61
- `bundle install`
80
+ ### onceover.yaml
62
81
 
63
- Set up your config:
82
+ Usually located at `spec/onceover.yaml`, this path could be overrided with environment variable: `ONCEOVER_YAML`.
64
83
 
65
- `bundle exec onceover init`
84
+ Hopefully this config file will be fairly self explanatory once you see it, but basically this is the place where we define what classes we want to test and the [factsets](#factsets) that we want to test them against.
66
85
 
67
- Run your spec tests!
86
+ #### Main settings
68
87
 
69
- `bundle exec onceover run spec`
88
+ - `classes`
70
89
 
71
- ## Overview
90
+ A list (array) of classes that we want to test
72
91
 
73
- This gem provides a toolset for testing Puppet Controlrepos (Repos used with r10k). The main purpose of this project is to provide a set of tools to help smooth out the process of setting up and running `rspec-puppet` tests for a controlrepo. Due to the fact that controlrepos are fairly standardised in nature it seemed ridiculous that you would need to set up the same testing framework that we would normally use within a module for a controlrepo. This is because at this level we are normally just running very basic tests that cover a lot of code. It would also mean that we would need to essentially duplicated our `Puppetfile` into a `.fixtures.yml` file, along with a few other things.
92
+ Classes are specified as string or **regular expressions**.
93
+ The recommended setting to have a good coverage is `/^role::/` if you use [roles and profiles method](https://puppet.com/docs/pe/latest/the_roles_and_profiles_method.html) and if you dont, you [should](https://puppet.com/docs/pe/2019.8/the_roles_and_profiles_method.html).
74
94
 
75
- This toolset requires some config before it can be used so definitely read that section before getting started.
95
+ - `nodes`
76
96
 
77
- ## Installation
97
+ A list (array) of nodes that we want to test against.
78
98
 
79
- `gem install onceover`
99
+ The nodes that we list here map directly to a [factset](#factsets), e.g. `Debian-7.8-64`
80
100
 
81
- This gem can just be installed using `gem install` however I would recommend using [Bundler](http://bundler.io/) to manage your gems.
101
+ - `node_groups`
82
102
 
83
- ## Config Files
103
+ An hash of named node groups.
84
104
 
85
- This project uses one main config file to determine what classes we should be testing and how, this is [onceover.yaml](#onceoveryaml). The `onceover.yaml` config file provides information about what classes to test when, however it needs more information than that:
105
+ We can create groups by simply specifying an array of nodes to be in the group, or use the subtractive [include/exclude syntax](#includeexclude-syntax).
86
106
 
87
- If we are doing spec testing we need sets of facts to compile the puppet code against, these are stored in [factsets](#factsets). (A few are provided out of the box for you)
107
+ **Note:** A _node group_ named `all_nodes` is automatically created by `onceover`.
88
108
 
89
- ### onceover.yaml
109
+ **Important:** The names used for the actual `class_groups` and `node_groups` must be unique.
90
110
 
91
- `spec/onceover.yaml` _(override with environment variable: `ONCEOVER_YAML`)_
111
+ - `class_groups`
92
112
 
93
- Hopefully this config file will be fairly self explanatory once you see it, but basically this is the place where we define what classes we want to test and the [factsets](#factsets) that we want to test them against. The config file must contain the following sections:
113
+ An hash of named class groups.
94
114
 
95
- **classes:** A list (array) of classes that we want to test, usually this would be your roles, possibly profiles if you want. (If you don't know what roles and profiles are please [READ THIS](http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/)). To make life easier you can also specify one or many **regular expressions** in this section. A good one to start with would be `/^role::/`. Regular expressions are just strings that start and end with a forward slash.
115
+ We can create groups by simply specifying an array of classes (string or regexp) to be in the group, or use the subtractive [include/exclude syntax](#includeexclude-syntax).
96
116
 
97
- **nodes:** The nodes that we want to test against. The nodes that we list here map directly to a [factset](#factsets).
117
+ **Note:** A _class group_ named `all_classes` is automatically created by `onceover`.
98
118
 
99
- **node_groups:** The `node_groups` section is just for saving us some typing. Here we can set up groups of nodes which we can then refer to in our test matrix. We can create groups by simply specifying an array of servers to be in the group, or we can use the subtractive *include/exclude* syntax. The names used for the actual `class_groups` and `node_groups` must be unique.
119
+ **Important:** The names used for the actual `class_groups` and `node_groups` must be unique.
100
120
 
101
- **class_groups:** The `class_groups` section is much the same as the `node_groups` sections, except that it creates groups of classes, not groups of nodes (duh). All the same rules apply and you can also use the *include/exclude* syntax. This, like the classes section can also accept regular expressions. This means that as long as you name your roles according to a naming convention that includes the desired operating system, you should be able to define your class groups once and never touch them again. The names used for the actual `class_groups` and `node_groups` must be unique.
121
+ - `test_matrix`
102
122
 
103
- **test_matrix:** This where the action happens! This is the section where we set up which classes are going to be tested against which nodes. It should be an array of hashes with the following format:
123
+ An array of hashes with the following format:
104
124
 
105
- ```yaml
106
- - {nodes_to_test}: # The name of a node or node group
107
- classes: '{classes_to_test}' # the name of a class or
108
- tests: '{all_tests|acceptance|spec}' # acceptance deprecated/broken, set to spec
109
- {valid_option}: {value} # Check the doco for available options
110
- ```
125
+ ```yaml
126
+ - {nodes_to_test}: # The name of a node or node group
127
+ classes: '{classes_to_test}' # the name of a class or
128
+ tests: '{all_tests|acceptance|spec}' # acceptance deprecated/broken, set to spec
129
+ {valid_option}: {value} # See below
130
+ ```
111
131
 
112
- Why an array of hashes? Well, that is so that we can refer to the same node or node group twice, which we may want/need to do.
132
+ Valid options:
113
133
 
114
- In the example below we have referred to `centos6a` and `centos7b` in all of our tests as they are in `all_nodes`, `non_windows_servers` and `centos_severs`. However we have *left the more specific references to last*. This is because entries in the test_matrix will override entries above them if applicable. Meaning that we are still only testing each class on the two Centos servers once (Because the gem does de-duplication before running the tests), but also making sure we run `roles::frontend_webserver` twice before checking for idempotency.
134
+ - `tags`
115
135
 
116
- **functions** In this section we can add functions that we want to mock when running spec tests. Each function takes the following arguments:
136
+ Default: `nil`
117
137
 
118
- - **returns** *Optional: A value to return*
138
+ One or many tags that tests in this group should be tagged with.
139
+ This allows you to run only certain tests using the `--tags` command line parameter.
119
140
 
120
- **before and after conditions** We can set `before` and `after` blocks before each spec test. These are usually used when the functions to stub are conditional: stub function `x` if the OS is windows, stub function `y` if the fact java_installed is true. The facts are available through the `node_facts` hash and the trusted facts as `trusted_facts`.
141
+ #### Advanced settings
121
142
 
122
- ```yaml
123
- before:
124
- - "Puppet::Util::Platform.stubs(:'windows?').returns(node_facts['kernel'] == 'windows')"
143
+ - `functions`
125
144
 
126
- after:
127
- - "puts 'Test finished running'"
128
- ```
145
+ Default: `nil`
146
+
147
+ In this section we can add functions that we want to mock when running spec tests.
148
+
149
+ Each function takes the `return` arguments, e.g.
150
+
151
+ ```yaml
152
+ functions:
153
+ puppetdb_query:
154
+ returns: []
155
+ ```
156
+
157
+ - `before`
158
+
159
+ Default: `nil`
160
+
161
+ A block to run **before** each spec test.
162
+
163
+ For example, this can be used when the functions to stub are conditional, the following stub function `x` if the OS is windows, stub function `y` if the fact `java_installed` is true.
164
+
165
+ **Note**: The facts are available through the `node_facts` hash and the trusted facts as `trusted_facts`.
166
+
167
+ Example:
168
+ ```yaml
169
+ before:
170
+ - "Puppet::Util::Platform.stubs(:'windows?').returns(node_facts['kernel'] == 'windows')"
171
+ ```
172
+
173
+ - `after`
174
+
175
+ Default: `nil`
176
+
177
+ A block to run **after** each spec test.
178
+
179
+ **Note**: The facts are available through the `node_facts` hash and the trusted facts as `trusted_facts`.
180
+
181
+ Exmaple:
182
+ ```yaml
183
+ after:
184
+ - "puts 'Test finished running'"
185
+ ```
186
+
187
+ - `include_spec_files`
188
+
189
+ Default: `[**/*]`
190
+
191
+ Glob to select additionnal files to be run during `onceover` spec tests.
192
+
193
+ Default is to select all files located in the repo spec directory, usually `spec/`.
194
+ If you have some RSpec tests that depend on a different RSpec configuration than `onceover` or want, for example, to have a different job in your CI to run your own unit tests, you can use this option to select which spec files to run during `onceover` spec tests.
195
+
196
+ - `opts`
197
+
198
+ Default: `{}`
199
+
200
+ This setting overrides defaults for the `Onceover::Controlrepo` class' `opts` hash.
201
+
202
+ Example:
203
+ ```yaml
204
+ opts:
205
+ :facts_dirs: # Remember: `opts` keys are symbols!
206
+ - 'spec/factsets' # Limit factsets to files in this repository
207
+ :debug: true # Set the `logger.level` to debug
208
+ :profile_regex: '^(profile|site)::' # Profiles include a legacy module named `site::`
209
+ :facts_files: # Factset filenames use the extension`.facts` instead of `.json`
210
+ - 'spec/factsets/*.facts'
211
+ :manifest: 'manifests/site.pp' # Manifest to use while compiling (nil by default)
212
+ ```
213
+
214
+ #### Include/Exclude syntax
129
215
 
130
- **opts** The `opts` section overrides defaults for the `Onceover::Controlrepo` class' `opts` hash.
216
+ This can be used with either `node_groups` or `class_groups` and allows us to save some time by using existing groups to create new ones e.g.
131
217
 
132
218
  ```yaml
133
- opts:
134
- :facts_dirs: # Remember: `opts` keys are symbols!
135
- - 'spec/factsets' # Limit factsets to files in this repository
136
- :debug: true # set the `logger.level` to debug
219
+ node_groups:
220
+ windows_nodes: # This has to be defined first
221
+ - sevrer2008r2
222
+ - server2012r2
223
+ non_windows:
224
+ include: 'all_nodes' # Start with all nodes
225
+ exclude: 'windows_nodes' # Then remove the windows ones from that list
137
226
  ```
138
227
 
228
+ It's important to note that in order to reference a group using the *include/exclude* syntax is has to have been defined already i.e. it has to come above the group that references it
229
+
230
+ #### Examples
231
+
232
+ ##### Minimal
233
+
139
234
  ```yaml
140
- opts:
141
- # profiles include a legacy module named `site::`
142
- :profile_regex: '^(profile|site)::'
235
+ classes:
236
+ - /^role::/
143
237
 
144
- # factset filenames use the extension`.facts` instead of `.json`
145
- :facts_files:
146
- - 'spec/factsets/*.facts'
238
+ nodes:
239
+ - Debian-10-amd64
240
+
241
+ test_matrix:
242
+ - all_nodes:
243
+ classes: 'all_classes'
244
+ tests: 'spec'
147
245
  ```
148
246
 
247
+ ##### Advanced
248
+
249
+ In the example below we have referred to `centos6a` and `centos7b` in all of our tests as they are in `all_nodes`, `non_windows_servers` and `centos_severs`. However we have *left the more specific references to last*. This is because entries in the test_matrix will override entries above them if applicable. Meaning that we are still only testing each class on the two Centos servers once (Because the gem does de-duplication before running the tests), but also making sure we run `roles::frontend_webserver` twice before checking for idempotency.
250
+
149
251
  A full example:
150
252
 
151
253
  ```yaml
@@ -155,7 +257,7 @@ classes:
155
257
  - 'roles::load_balancer'
156
258
  - 'roles::syd_f5_load_balancer'
157
259
  - 'roles::windows_server'
158
- - '/^role/'
260
+ - '/^role/' # Note that this regex format requires `/`
159
261
 
160
262
  nodes:
161
263
  - centos6a
@@ -209,47 +311,26 @@ functions:
209
311
  opts:
210
312
  :facts_dirs:
211
313
  - spec/factsets
314
+ :profile_regex: '^(profile|site)::' # Note that this regex _doesn't_ use `/`
212
315
  ```
213
316
 
214
- **Include/Exclude syntax:** This can be used with either `node_groups` or `class_groups` and allows us to save some time by using existing groups to create new ones e.g.
215
-
216
- ```yaml
217
- node_groups:
218
- windows_nodes: # This has to be defined first
219
- - sevrer2008r2
220
- - server2012r2
221
- non_windows:
222
- include: 'all_nodes' # Start with all nodes
223
- exclude: 'windows_nodes' # Then remove the windows ones from that list
224
- ```
317
+ ### Factsets
225
318
 
226
- It's important to note that in order to reference a group using the *include/exclude* syntax is has to have been defined already i.e. it has to come above the group that references it (Makes sense right?)
319
+ Factsets are used by the onceover gem to generate spec tests, which compile a given class against a certain set of facts.
227
320
 
228
- #### Optional test parameters
321
+ This gem comes with a few pre-canned factsets, these are listed under the `nodes` sections of `onceover.yaml` when you run `onceover init`.
229
322
 
230
- **tags** *Default: nil*
323
+ You can, and its a good pratice, add your own factsets by putting them in `spec/factsets/*.json`.
231
324
 
232
- One or many tags that tests in this group should be tagged with. This allows you to run only certain tests using the `--tags` command line parameter. **NOTE:** Custom spec tests will always be run as they are not subject to tags
325
+ To generate these factsets all we need to do is log onto a real machine that has puppet installed and run:
233
326
 
234
- ### factsets
235
-
236
- This gem comes with a few pre-canned factsets. These are listed under the `nodes` sections of `onceover.yaml` when you run `onceover init`. You can also add your own factsets by putting them in:
237
-
238
- `spec/factsets/*.json`
239
-
240
- Factsets are used by the onceover gem to generate spec tests, which compile a given class against a certain set of facts. To create these factsets all we need to do is log onto a real machine that has puppet installed and run:
241
-
242
- `puppet facts`
243
-
244
- Which will give raw json output of every fact which puppet knows about. Usually I would recommend running this on each of the types of machines that you run in your infrastructure so that you have good coverage. To make life easier you might want to direct it into a file instead of copying it from the command line:
245
-
246
- `puppet facts > fact_set_name.json`
247
-
248
- Once we have our factset all we need to do is copy it into `spec/factsets/` inside our controlrepo and commit it to version control. Factsets are named based on their filename, not the name of the server they came from (Although you can, if you want). i.e the following factset file:
327
+ ```shell
328
+ puppet facts > fact_set_name.json
329
+ ```
249
330
 
250
- `spec/factsets/server2008r2.json`
331
+ Its recommended to run this on each of the types of nodes that you run in your infrastructure to have good coverage.
251
332
 
252
- Would map to a node named `server2008r2` in `onceover.yaml`
333
+ Factsets are named based on their filename, i.e. `myfactset` in `onceover.yaml` refers `spec/factsets/myfactset.json`
253
334
 
254
335
  #### Trusted Facts
255
336
 
@@ -270,13 +351,17 @@ You can add trusted facts to the factsets by creating a new section called trust
270
351
 
271
352
  Notice that the `extensions` part is implied. The first fact in that example translates to `$trusted['extensions']['pp_role']` in Puppet code.
272
353
 
273
- ### Hiera Data
354
+ ### Hiera
274
355
 
275
- If you have hiera data inside your controlrepo (or somewhere else) Onceover can be configured to use it. It is however worth noting the the `hiera.yaml` file that you currently use may not be applicable for testing right away. For example; if you are using `hiera-eyaml` I recommend creating a `hiera.yaml` purely for testing that simply uses the `yaml` backend, meaning that you don't need to provide the private keys to the testing machines.
356
+ If you have hiera data inside your controlrepo (or somewhere else) `onceover` can be configured to use it.
357
+ It is however worth noting the `hiera.yaml` file that you currently use may not be applicable for testing right away.
358
+ For example; if you are using `hiera-eyaml` I recommend creating a `hiera.yaml` purely for testing that simply uses the `yaml` backend, meaning that you don't need to provide the private keys to the testing machines.
276
359
 
277
- It is also worth noting that any hiera hierarchies that are based on custom facts will not work unless those facts are part of your factsets. Trusted facts will also not work at all as the catalogs are being compiled without the node's certificate. In these instances it may be worth creating a hierarchy level that simply includes dummy data for testing purposes in order to avoid hiera lookup errors.
360
+ It is also worth noting that any hiera hierarchies that are based on custom facts will not work unless those facts are part of your factsets.
361
+ Trusted facts will also not work at all as the catalogs are being compiled without the node's certificate.
362
+ In these instances it may be worth creating a hierarchy level that simply includes dummy data for testing purposes in order to avoid hiera lookup errors.
278
363
 
279
- ### r10k
364
+ ### Puppetfile
280
365
 
281
366
  Organisations often reference modules from their own git servers in the `Puppetfile`, like this:
282
367
 
@@ -286,7 +371,9 @@ mod "puppetlabs-apache",
286
371
  :tag => "v5.4.0"
287
372
  ```
288
373
 
289
- Under the hood, Onceover uses r10k to download the modules in your `Puppetfile`. If you get errors downloading modules from Git, its because `r10k`'s call to your underlying `git` command has failed. Onceover tells you the command that `r10k` tried to run, so if you get an error like this:
374
+ Under the hood, `onceover` uses `r10k` to download the modules in your `Puppetfile`.
375
+ If you get errors downloading modules from `git`, its because `r10k`'s call to your underlying `git` command has failed.
376
+ `onceover` tells you the command that `r10k` tried to run, so if you get an error like this:
290
377
 
291
378
  ```
292
379
  INFO -> Updating module /Users/dylan/control-repo/.onceover/etc/puppetlabs/code/environments
@@ -321,7 +408,7 @@ Warning: Permanently added 'git.megacorp.com,123.456.789.101' (RSA) to the list
321
408
 
322
409
  The other way to resolve this would have been to install the `ssh_askpass` program, but this can spam the screen with modal dialogs on some platforms.
323
410
 
324
- #### r10k Config
411
+ #### r10k configuration
325
412
 
326
413
  If you have custom r10k config that you want to use, place the `r10k.yaml` file in one of the following locations:
327
414
 
@@ -701,3 +788,7 @@ Cheers to all of those who helped out:
701
788
  - @tequeter
702
789
  - @alexjfisher
703
790
  - @smortex
791
+ - @16c7x
792
+ - @neomilium
793
+ - @chlawren
794
+