kitchen-pester 1.2.0 → 1.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +443 -0
- data/kitchen-pester.gemspec +11 -8
- data/lib/kitchen/verifier/pester.rb +308 -81
- data/lib/kitchen/verifier/pester_version.rb +31 -1
- data/lib/support/modules/PesterUtil/PesterUtil.psm1 +20 -0
- metadata +13 -62
- data/Gemfile +0 -29
- data/Rakefile +0 -57
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 0b6c13739edbe22f0dedd8c258cf3ba1d65232872a5dbb43831e71af00adff8c
|
|
4
|
+
data.tar.gz: c8c94343f5e132fd79d1e5a39848a883d10f8506e6408bdd44a2bb645a0f3f1c
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 4e40212df8ac8701351185e97429cdfcd8a2c9366c06b2ecd8c198a175b748be682e7a5f2806bf42626ea928940d2383e65d851ca7bb06e860713d92651d70e2
|
|
7
|
+
data.tar.gz: d2cea264f19135c7c9b0660358a71b627e4ac2c28fe765b03e41572ca0113192c5b4ef15ef3fe2808dcf43fba56f29d8fa6e9aeab0d5c4293f3e175433c696e8
|
data/README.md
ADDED
|
@@ -0,0 +1,443 @@
|
|
|
1
|
+
# kitchen-pester
|
|
2
|
+
|
|
3
|
+
[](http://badge.fury.io/rb/kitchen-pester)
|
|
4
|
+
|
|
5
|
+
Run [Pester](https://pester.dev/) tests against a machine that
|
|
6
|
+
[Test Kitchen](https://kitchen.ci/) built for you.
|
|
7
|
+
|
|
8
|
+
Test Kitchen creates the machine, your provisioner configures it, and
|
|
9
|
+
kitchen-pester copies your `*.Tests.ps1` files onto it, installs Pester, runs
|
|
10
|
+
the tests, and brings the results back. No Busser layer in between.
|
|
11
|
+
|
|
12
|
+
It works on Windows and on Linux or macOS instances with
|
|
13
|
+
[PowerShell](https://github.com/PowerShell/PowerShell) installed.
|
|
14
|
+
|
|
15
|
+
## Quick start
|
|
16
|
+
|
|
17
|
+
### 1. Install the gem
|
|
18
|
+
|
|
19
|
+
This verifier ships as part of [Cinc Workstation](https://cinc.sh/start/workstation/).
|
|
20
|
+
If you have Cinc Workstation installed, there is nothing else to install.
|
|
21
|
+
|
|
22
|
+
To install it into a standalone Ruby:
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
gem install kitchen-pester
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
or add it to your `Gemfile`:
|
|
29
|
+
|
|
30
|
+
```ruby
|
|
31
|
+
gem "kitchen-pester"
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
The examples below use the `cinc` commands. Everything here works identically
|
|
35
|
+
with Chef Workstation — see [Using with Chef](#using-with-chef).
|
|
36
|
+
|
|
37
|
+
### 2. Point Test Kitchen at it
|
|
38
|
+
|
|
39
|
+
In `kitchen.yml`:
|
|
40
|
+
|
|
41
|
+
```yaml
|
|
42
|
+
verifier:
|
|
43
|
+
name: pester
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
You can set this at the top level, per platform, or per suite.
|
|
47
|
+
|
|
48
|
+
### 3. Put your tests where it will find them
|
|
49
|
+
|
|
50
|
+
For a suite named `default`, that is `tests/integration/default/`:
|
|
51
|
+
|
|
52
|
+
```text
|
|
53
|
+
tests/
|
|
54
|
+
└── integration/
|
|
55
|
+
├── default/
|
|
56
|
+
│ └── myapp.Tests.ps1
|
|
57
|
+
└── helpers/ # optional, copied to every suite
|
|
58
|
+
└── Assertions.ps1
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### 4. Write a test
|
|
62
|
+
|
|
63
|
+
An ordinary Pester file — nothing kitchen-specific:
|
|
64
|
+
|
|
65
|
+
```powershell
|
|
66
|
+
Describe 'myapp' {
|
|
67
|
+
It 'installed the binary' {
|
|
68
|
+
'C:\Program Files\myapp\myapp.exe' | Should -Exist
|
|
69
|
+
}
|
|
70
|
+
|
|
71
|
+
It 'is listening on 8080' {
|
|
72
|
+
Get-NetTCPConnection -LocalPort 8080 | Should -Not -BeNullOrEmpty
|
|
73
|
+
}
|
|
74
|
+
}
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### 5. Run it
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
cinc kitchen verify
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Results are written to `./testresults/PesterTestResults.xml` in NUnit format,
|
|
84
|
+
ready for a CI system to pick up. A failing Pester test fails `cinc kitchen verify`.
|
|
85
|
+
|
|
86
|
+
## How it works
|
|
87
|
+
|
|
88
|
+
Worth knowing when something goes wrong:
|
|
89
|
+
|
|
90
|
+
1. **Sandbox.** Your suite's tests, any `helpers/`, anything in `copy_folders`,
|
|
91
|
+
and kitchen-pester's own `PesterUtil` PowerShell module are staged into a
|
|
92
|
+
local temp directory.
|
|
93
|
+
2. **Transfer.** Test Kitchen ships that sandbox to the instance, under
|
|
94
|
+
`$env:TEMP/verifier` on Windows or `/tmp/verifier` elsewhere.
|
|
95
|
+
3. **Prepare.** kitchen-pester prepends the sandbox's `modules/` folder to
|
|
96
|
+
`$env:PSModulePath`, then installs Pester and anything in
|
|
97
|
+
`install_modules`.
|
|
98
|
+
4. **Run.** It writes a `kitchen_cmd.ps1` on the instance and invokes it. Your
|
|
99
|
+
tests run from the `suites/` folder inside the sandbox.
|
|
100
|
+
5. **Download.** Everything in `downloads` is copied back — including when the
|
|
101
|
+
run fails, so you always get the results file.
|
|
102
|
+
|
|
103
|
+
Every step is generated PowerShell. If a run misbehaves, `kitchen_cmd.ps1` on
|
|
104
|
+
the instance is the exact script that ran.
|
|
105
|
+
|
|
106
|
+
## Pester versions
|
|
107
|
+
|
|
108
|
+
kitchen-pester supports **Pester 5 and later** (the default) and **Pester 4**.
|
|
109
|
+
|
|
110
|
+
It detects the installed version on the instance and adapts: Pester 5 and
|
|
111
|
+
later get a `PesterConfiguration` object built from your
|
|
112
|
+
`pester_configuration`, Pester 4 and earlier get loose `Invoke-Pester`
|
|
113
|
+
parameters. You do not need to tell it which one you are on.
|
|
114
|
+
|
|
115
|
+
To stay on Pester 4, cap the install. `pester_install` is
|
|
116
|
+
[replaced, not merged](#map-options-are-replaced-not-merged), so repeat the
|
|
117
|
+
defaults you still want — without `SkipPublisherCheck` the install fails
|
|
118
|
+
against the Pester that ships with Windows:
|
|
119
|
+
|
|
120
|
+
```yaml
|
|
121
|
+
verifier:
|
|
122
|
+
name: pester
|
|
123
|
+
pester_install:
|
|
124
|
+
MaximumVersion: '4.99.999'
|
|
125
|
+
SkipPublisherCheck: true
|
|
126
|
+
Force: true
|
|
127
|
+
ErrorAction: Stop
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
## Configuration
|
|
131
|
+
|
|
132
|
+
All of these go under `verifier:` in `kitchen.yml`.
|
|
133
|
+
|
|
134
|
+
### Map options are replaced, not merged
|
|
135
|
+
|
|
136
|
+
Every option below whose type is **map** — `pester_install`,
|
|
137
|
+
`pester_configuration`, `bootstrap`, `environment`, `downloads` — replaces its
|
|
138
|
+
default outright. A plugin default applies only when the key is absent
|
|
139
|
+
altogether, so setting one key inside one of these maps discards every other
|
|
140
|
+
key the default supplied. (Merging between the top-level, platform and suite
|
|
141
|
+
`verifier:` blocks is unaffected — that part is a deep merge.)
|
|
142
|
+
|
|
143
|
+
This bites hardest on `pester_install` and `pester_configuration`, where the
|
|
144
|
+
discarded defaults are the ones that produce the results file. Whenever you set
|
|
145
|
+
a map option, write out the whole map, taking the defaults from the tables
|
|
146
|
+
below as your starting point.
|
|
147
|
+
|
|
148
|
+
### Common
|
|
149
|
+
|
|
150
|
+
| Option | Type | Default | What it does |
|
|
151
|
+
| --- | --- | --- | --- |
|
|
152
|
+
| `test_folder` | string | `tests` | Where your tests live. See [Test discovery](#test-discovery). |
|
|
153
|
+
| `downloads` | map | `{"./PesterTestResults.xml" => "./testresults/"}` | Files to copy back from the instance. See [Downloads](#downloads). |
|
|
154
|
+
| `environment` | map | `{}` | Environment variables to set for your tests. |
|
|
155
|
+
| `copy_folders` | array | `[]` | Local folders to copy to the instance and put on `$env:PSModulePath`. |
|
|
156
|
+
| `pester_configuration` | map | see [below](#pester_configuration) | Passed through to Pester. |
|
|
157
|
+
| `root_path` | string | driver default | Directory on the SUT the sandbox is copied into. Relative `copy_folders` sources and the `suites` directory resolve against it, and `PesterTestResults.xml` is written there. |
|
|
158
|
+
| `suite_name` | string | the suite name | Name of the suite, used when locating its tests. |
|
|
159
|
+
|
|
160
|
+
### Installing Pester and its dependencies
|
|
161
|
+
|
|
162
|
+
| Option | Type | Default | What it does |
|
|
163
|
+
| --- | --- | --- | --- |
|
|
164
|
+
| `pester_install` | map | `{SkipPublisherCheck: true, Force: true, ErrorAction: "Stop"}` | Splatted to `Install-Module -Name Pester`. |
|
|
165
|
+
| `skip_pester_install` | bool | `false` | Use whatever Pester is already on the box. |
|
|
166
|
+
| `install_modules` | array | `[]` | Extra modules to install from a gallery. |
|
|
167
|
+
| `register_repository` | array | `[]` | PSRepositories to register first, for private feeds. |
|
|
168
|
+
| `bootstrap` | map | `{repository_url: "https://www.powershellgallery.com/api/v2", modules: []}` | Modules to fetch straight from a NuGet feed, before PowerShellGet is usable. |
|
|
169
|
+
| `remove_builtin_pester` | bool | `true` | Remove the Pester 3.4.0 that ships with Windows. |
|
|
170
|
+
| `remove_builtin_powershellget` | bool | `true` | Remove the PowerShellGet and PackageManagement 1.0.0.1 that ship with Windows. |
|
|
171
|
+
|
|
172
|
+
### Platform and shell
|
|
173
|
+
|
|
174
|
+
| Option | Type | Default | What it does |
|
|
175
|
+
| --- | --- | --- | --- |
|
|
176
|
+
| `shell` | string | `nil` | Shell binary to use. Defaults to `powershell` on Windows, `pwsh` elsewhere. |
|
|
177
|
+
| `sudo` | bool | `false` | Run PowerShell under sudo. Non-Windows only. |
|
|
178
|
+
| `restart_winrm` | bool | `false` | Restart WinRM via a scheduled task before verifying. Windows only. |
|
|
179
|
+
|
|
180
|
+
### Test discovery
|
|
181
|
+
|
|
182
|
+
`test_folder` is where kitchen-pester starts looking. It may be relative to
|
|
183
|
+
the directory you run `kitchen` from, or absolute, and it must exist.
|
|
184
|
+
|
|
185
|
+
If `<test_folder>/integration` exists, that becomes the root instead — which is
|
|
186
|
+
why the default `tests` finds `tests/integration`. Within that root:
|
|
187
|
+
|
|
188
|
+
- `<root>/<suite_name>/` is copied to the instance and is what Pester runs.
|
|
189
|
+
Nest files however you like; Pester recurses.
|
|
190
|
+
- `<root>/helpers/` is copied alongside **every** suite.
|
|
191
|
+
|
|
192
|
+
### Downloads
|
|
193
|
+
|
|
194
|
+
The key is the file on the instance, the value is where to put it locally.
|
|
195
|
+
|
|
196
|
+
The **source** may be relative to the verifier folder (`$env:TEMP/verifier` by
|
|
197
|
+
default) or absolute (`/var/tmp/file.zip`, `C:\Windows\Temp\file.zip`).
|
|
198
|
+
|
|
199
|
+
The **destination** may be relative to the current directory or absolute, may
|
|
200
|
+
end in `/` or `\` to mean "a directory, keep the filename", and may contain
|
|
201
|
+
`%{instance_name}` to keep results from different instances apart:
|
|
202
|
+
|
|
203
|
+
```yaml
|
|
204
|
+
verifier:
|
|
205
|
+
name: pester
|
|
206
|
+
downloads:
|
|
207
|
+
PesterTestResults.xml: "testresults/%{instance_name}/"
|
|
208
|
+
kitchen_cmd.ps1: "testresults/%{instance_name}/"
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
Downloading `kitchen_cmd.ps1` like that is a useful debugging trick: it is the
|
|
212
|
+
generated script that actually ran.
|
|
213
|
+
|
|
214
|
+
### pester_configuration
|
|
215
|
+
|
|
216
|
+
Defaults to:
|
|
217
|
+
|
|
218
|
+
```yaml
|
|
219
|
+
run:
|
|
220
|
+
path: "."
|
|
221
|
+
PassThru: true
|
|
222
|
+
TestResult:
|
|
223
|
+
Enabled: true
|
|
224
|
+
OutputPath: PesterTestResults.xml
|
|
225
|
+
TestSuiteName: ""
|
|
226
|
+
Output:
|
|
227
|
+
Verbosity: Detailed
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
This map is [replaced, not merged](#map-options-are-replaced-not-merged), and
|
|
231
|
+
the defaults it replaces are load-bearing. `New-PesterConfiguration` defaults
|
|
232
|
+
both `TestResult.Enabled` and `Run.PassThru` to `$false`, so this:
|
|
233
|
+
|
|
234
|
+
```yaml
|
|
235
|
+
verifier:
|
|
236
|
+
name: pester
|
|
237
|
+
pester_configuration:
|
|
238
|
+
Output:
|
|
239
|
+
Verbosity: Diagnostic
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
turns off the NUnit results file — your `downloads` then have nothing to
|
|
243
|
+
fetch — and leaves the run without a result object to count failures from.
|
|
244
|
+
Copy the whole default map and edit the key you came for.
|
|
245
|
+
|
|
246
|
+
**On Pester 5**, this becomes a `PesterConfiguration` via
|
|
247
|
+
`New-PesterConfiguration -Hashtable`. Three keys are filled in for you if you
|
|
248
|
+
leave them unset:
|
|
249
|
+
|
|
250
|
+
| Key | Filled in with |
|
|
251
|
+
| --- | --- |
|
|
252
|
+
| `Run.Path` | `$env:TEMP/verifier/suites` |
|
|
253
|
+
| `TestResult.TestSuiteName` | `Pester - <kitchen instance name>` |
|
|
254
|
+
| `TestResult.OutputPath` | `$env:TEMP/verifier/PesterTestResults.xml` |
|
|
255
|
+
|
|
256
|
+
**On Pester 4**, keys matching a real `Invoke-Pester` parameter are used and
|
|
257
|
+
the rest are ignored. These defaults apply unless you set them:
|
|
258
|
+
|
|
259
|
+
| Parameter | Default |
|
|
260
|
+
| --- | --- |
|
|
261
|
+
| `Script` | `$env:TEMP/verifier/suites` |
|
|
262
|
+
| `OutputFile` | `$env:TEMP/verifier/PesterTestResults.xml` |
|
|
263
|
+
| `OutputFormat` | `NUnitXml` |
|
|
264
|
+
| `PassThru` | `true` |
|
|
265
|
+
| `PesterOption` | `New-PesterOption -TestSuiteName "Pester - <instance name>"` |
|
|
266
|
+
|
|
267
|
+
### register_repository
|
|
268
|
+
|
|
269
|
+
Each entry is splatted to `Register-PSRepository`, or `Set-PSRepository` if the
|
|
270
|
+
repository already exists:
|
|
271
|
+
|
|
272
|
+
```yaml
|
|
273
|
+
verifier:
|
|
274
|
+
name: pester
|
|
275
|
+
register_repository:
|
|
276
|
+
- Name: MyPrivateNuget
|
|
277
|
+
SourceLocation: https://mypsrepo.local/api/v2
|
|
278
|
+
InstallationPolicy: trusted
|
|
279
|
+
PackageManagementProvider: Nuget
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
### install_modules
|
|
283
|
+
|
|
284
|
+
Plain names, or maps splatted to `Install-Module`:
|
|
285
|
+
|
|
286
|
+
```yaml
|
|
287
|
+
verifier:
|
|
288
|
+
name: pester
|
|
289
|
+
install_modules:
|
|
290
|
+
- PSScriptAnalyzer
|
|
291
|
+
- Name: MyModule
|
|
292
|
+
Repository: MyPrivateRepo
|
|
293
|
+
SkipPublisherCheck: true
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
### bootstrap
|
|
297
|
+
|
|
298
|
+
For machines where PowerShellGet is too old to install anything — notably a
|
|
299
|
+
stock Windows image. Modules are downloaded and unzipped straight from the
|
|
300
|
+
NuGet API, bypassing `Install-Module` entirely.
|
|
301
|
+
|
|
302
|
+
The feed must serve `$repository_url/package/<ModuleName>`, which some private
|
|
303
|
+
feed implementations do not.
|
|
304
|
+
|
|
305
|
+
```yaml
|
|
306
|
+
verifier:
|
|
307
|
+
name: pester
|
|
308
|
+
bootstrap:
|
|
309
|
+
repository_url: https://www.powershellgallery.com/api/v2
|
|
310
|
+
modules:
|
|
311
|
+
- PackageManagement
|
|
312
|
+
- PowerShellGet
|
|
313
|
+
```
|
|
314
|
+
|
|
315
|
+
> **Note:** this key is
|
|
316
|
+
> [replaced, not merged](#map-options-are-replaced-not-merged). If you set
|
|
317
|
+
> `modules`, set `repository_url` too.
|
|
318
|
+
|
|
319
|
+
## Examples
|
|
320
|
+
|
|
321
|
+
### Testing a PowerShell module you just built
|
|
322
|
+
|
|
323
|
+
`copy_folders` puts your build output on the instance's `$env:PSModulePath`,
|
|
324
|
+
so your tests can `Import-Module MyModule` as if it were installed:
|
|
325
|
+
|
|
326
|
+
```yaml
|
|
327
|
+
verifier:
|
|
328
|
+
name: pester
|
|
329
|
+
copy_folders:
|
|
330
|
+
- output/MyModule
|
|
331
|
+
downloads:
|
|
332
|
+
PesterTestResults.xml: "testresults/%{instance_name}/"
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
### A stock Windows image
|
|
336
|
+
|
|
337
|
+
Windows ships Pester 3.4.0 and PowerShellGet 1.0.0.1, neither of which can
|
|
338
|
+
install a modern Pester on its own. The defaults already remove both; bootstrap
|
|
339
|
+
replacements from NuGet so the install has something to work with:
|
|
340
|
+
|
|
341
|
+
```yaml
|
|
342
|
+
verifier:
|
|
343
|
+
name: pester
|
|
344
|
+
bootstrap:
|
|
345
|
+
repository_url: https://www.powershellgallery.com/api/v2
|
|
346
|
+
modules:
|
|
347
|
+
- PackageManagement
|
|
348
|
+
- PowerShellGet
|
|
349
|
+
```
|
|
350
|
+
|
|
351
|
+
### Linux, with PowerShell installed on the fly
|
|
352
|
+
|
|
353
|
+
Use Test Kitchen's lifecycle hooks to install `pwsh` after the machine comes
|
|
354
|
+
up. A recent `pwsh` ships a usable PowerShellGet, so no bootstrap is needed:
|
|
355
|
+
|
|
356
|
+
```yaml
|
|
357
|
+
provisioner:
|
|
358
|
+
name: shell
|
|
359
|
+
script: tests/integration/provisioning.ps1
|
|
360
|
+
|
|
361
|
+
verifier:
|
|
362
|
+
name: pester
|
|
363
|
+
|
|
364
|
+
platforms:
|
|
365
|
+
- name: ubuntu-22.04
|
|
366
|
+
lifecycle:
|
|
367
|
+
post_create:
|
|
368
|
+
- remote: sudo snap install powershell --classic
|
|
369
|
+
|
|
370
|
+
suites:
|
|
371
|
+
- name: default
|
|
372
|
+
```
|
|
373
|
+
|
|
374
|
+
If `pwsh` is only reachable through sudo — as with a snap install on some
|
|
375
|
+
systems — add `sudo: true` to the verifier.
|
|
376
|
+
|
|
377
|
+
### Passing secrets and settings to your tests
|
|
378
|
+
|
|
379
|
+
```yaml
|
|
380
|
+
verifier:
|
|
381
|
+
name: pester
|
|
382
|
+
environment:
|
|
383
|
+
API_KEY: <%= ENV['API_KEY'] %>
|
|
384
|
+
PUSH_URI: https://push.example.com
|
|
385
|
+
```
|
|
386
|
+
|
|
387
|
+
```powershell
|
|
388
|
+
Describe 'configuration' {
|
|
389
|
+
It 'received the API key' {
|
|
390
|
+
$env:API_KEY | Should -Not -BeNullOrEmpty
|
|
391
|
+
}
|
|
392
|
+
}
|
|
393
|
+
```
|
|
394
|
+
|
|
395
|
+
## Troubleshooting
|
|
396
|
+
|
|
397
|
+
**`cinc kitchen verify` fails but I get no results file.** You should still get one
|
|
398
|
+
— downloads run even when the verify fails. If the file is missing, the run
|
|
399
|
+
died before Pester started; check the `cinc kitchen verify` output for the install
|
|
400
|
+
step.
|
|
401
|
+
|
|
402
|
+
**I set one `pester_configuration` key and the results file stopped appearing.**
|
|
403
|
+
Map options replace their default rather than merging into it, and the default
|
|
404
|
+
is what enables the results file. See
|
|
405
|
+
[Map options are replaced, not merged](#map-options-are-replaced-not-merged).
|
|
406
|
+
|
|
407
|
+
**I want to see the script that ran.** Add `kitchen_cmd.ps1` to `downloads`,
|
|
408
|
+
or look for it in `$env:TEMP/verifier` on the instance.
|
|
409
|
+
|
|
410
|
+
**`Install-Module` cannot find a repository.** The built-in PowerShellGet was
|
|
411
|
+
removed (the default) and nothing replaced it. Either `bootstrap` a newer
|
|
412
|
+
PowerShellGet, or set `remove_builtin_powershellget: false` if the machine's
|
|
413
|
+
own copy works.
|
|
414
|
+
|
|
415
|
+
**Tests are not found.** Check that your files are under
|
|
416
|
+
`<test_folder>/integration/<suite_name>/` and match Pester's discovery
|
|
417
|
+
pattern (`*.Tests.ps1`), and that the suite name in `kitchen.yml` matches the
|
|
418
|
+
folder name.
|
|
419
|
+
|
|
420
|
+
**PowerShell is not installed on a Linux instance.** kitchen-pester does not
|
|
421
|
+
install it. Use a lifecycle hook or your provisioner.
|
|
422
|
+
|
|
423
|
+
## Using with Chef
|
|
424
|
+
|
|
425
|
+
This verifier runs Pester and does not depend on Cinc or Chef being installed on
|
|
426
|
+
the system under test — it works with any Test Kitchen driver and provisioner.
|
|
427
|
+
|
|
428
|
+
The examples above use [Cinc Workstation](https://cinc.sh/start/workstation/) and
|
|
429
|
+
the `cinc kitchen` commands. With
|
|
430
|
+
[Chef Workstation](https://www.chef.io/downloads/tools/workstation) run `kitchen`
|
|
431
|
+
instead of `cinc kitchen`. No verifier configuration changes are needed.
|
|
432
|
+
|
|
433
|
+
## Contributing
|
|
434
|
+
|
|
435
|
+
Bug reports and pull requests are welcome on
|
|
436
|
+
[GitHub](https://github.com/test-kitchen/kitchen-pester). See
|
|
437
|
+
[CONTRIBUTING.md](CONTRIBUTING.md) for development setup, how to run the unit
|
|
438
|
+
specs, the PowerShell module specs, and the integration suite, and how the
|
|
439
|
+
documentation is generated.
|
|
440
|
+
|
|
441
|
+
## License
|
|
442
|
+
|
|
443
|
+
MIT. See [LICENSE](LICENSE).
|
data/kitchen-pester.gemspec
CHANGED
|
@@ -1,24 +1,27 @@
|
|
|
1
|
+
# frozen_string_literal: true
|
|
2
|
+
|
|
1
3
|
lib = File.expand_path("lib", __dir__)
|
|
2
4
|
$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
|
|
3
5
|
|
|
4
6
|
require "kitchen/verifier/pester_version"
|
|
5
7
|
|
|
6
8
|
Gem::Specification.new do |spec|
|
|
7
|
-
spec.name
|
|
9
|
+
spec.name = "kitchen-pester"
|
|
10
|
+
spec.required_ruby_version = ">= 3.1"
|
|
8
11
|
spec.version = Kitchen::Verifier::PESTER_VERSION
|
|
9
12
|
spec.authors = ["Steven Murawski"]
|
|
10
13
|
spec.email = ["steven.murawski@gmail.com"]
|
|
11
14
|
spec.summary = "Test-Kitchen verifier for Pester."
|
|
12
15
|
spec.description = "Skip all that Busser stuff and jump right into Pester."
|
|
13
16
|
spec.homepage = "https://github.com/test-kitchen/kitchen-pester"
|
|
14
|
-
spec.license = "
|
|
17
|
+
spec.license = "MIT"
|
|
15
18
|
|
|
16
|
-
|
|
19
|
+
# README.md is what YARD picks up as the front page of the generated docs,
|
|
20
|
+
# which is how rubydoc.info renders this gem.
|
|
21
|
+
spec.files = %w{LICENSE README.md kitchen-pester.gemspec} + Dir.glob("lib/**/*")
|
|
17
22
|
spec.require_paths = ["lib"]
|
|
18
23
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
spec.
|
|
22
|
-
|
|
23
|
-
spec.add_dependency "test-kitchen", ">= 1.10", "< 4"
|
|
24
|
+
# 3.6.0 is the first release to require Ruby >= 3.1, which this gem also
|
|
25
|
+
# requires, so anything older cannot be installed alongside it in practice.
|
|
26
|
+
spec.add_dependency "test-kitchen", ">= 3.6", "< 5"
|
|
24
27
|
end
|