pdqtest 1.4.1 → 1.9.9beta2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.travis.yml +9 -3
- data/doc/acceptance_tests.md +100 -22
- data/doc/caching.md +5 -1
- data/doc/development.md +16 -5
- data/doc/emoji.md +20 -9
- data/doc/enabling_testing.md +15 -3
- data/doc/examples.md +25 -6
- data/doc/hiera.md +30 -11
- data/doc/installation.md +59 -8
- data/doc/pdk.md +334 -0
- data/doc/puppet_facts.md +45 -3
- data/doc/puppet_module_dependencies.md +34 -16
- data/doc/running_tests.md +35 -15
- data/doc/test_generation.md +11 -19
- data/doc/tips_and_tricks.md +17 -8
- data/doc/troubleshooting.md +19 -8
- data/doc/upgrading.md +125 -6
- data/doc/windows.md +51 -0
- data/docker_images/centos/Dockerfile +4 -3
- data/docker_images/centos/Makefile +1 -1
- data/docker_images/ubuntu/Dockerfile +3 -3
- data/docker_images/windows/Dockerfile +26 -0
- data/docker_images/windows/make.ps1 +2 -0
- data/exe/pdqtest +73 -28
- data/lib/pdqtest/core.rb +1 -1
- data/lib/pdqtest/docker.rb +143 -51
- data/lib/pdqtest/emoji.rb +33 -7
- data/lib/pdqtest/fastcheck.rb +19 -0
- data/lib/pdqtest/instance.rb +16 -15
- data/lib/pdqtest/logger.rb +35 -0
- data/lib/pdqtest/pdk.rb +98 -0
- data/lib/pdqtest/pdqtest1x.rb +115 -0
- data/lib/pdqtest/puppet.rb +277 -134
- data/lib/pdqtest/skeleton.rb +119 -39
- data/lib/pdqtest/upgrade.rb +42 -42
- data/lib/pdqtest/util.rb +82 -2
- data/lib/pdqtest/version.rb +1 -2
- data/pdqtest.gemspec +8 -13
- data/res/{skeleton → acceptance}/init.bats +0 -0
- data/res/{skeleton → acceptance}/init__before.bats +0 -0
- data/res/{skeleton → acceptance}/init__setup.sh +0 -0
- data/res/skeleton/.puppet-lint.rc +5 -0
- data/res/skeleton/{dot_travis.yml → .travis.yml} +0 -0
- data/res/skeleton/Makefile +20 -5
- data/res/skeleton/make.ps1 +66 -0
- data/res/skeleton/spec/fixtures/hiera.yaml +13 -0
- data/res/skeleton/spec/fixtures/hieradata/test.yaml +11 -0
- data/res/templates/examples_init.pp.erb +1 -1
- metadata +47 -115
- data/lib/pdqtest/lint.rb +0 -31
- data/lib/pdqtest/rspec.rb +0 -69
- data/lib/pdqtest/syntax.rb +0 -20
- data/res/skeleton/Gemfile +0 -7
- data/res/skeleton/Rakefile +0 -3
- data/res/skeleton/dot_gitignore +0 -9
- data/res/skeleton/dot_rspec +0 -2
- data/res/skeleton/hiera.yaml +0 -7
- data/res/skeleton/spec_helper.rb +0 -4
- data/res/skeleton/test.yaml +0 -3
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 133ce9046197e77d059c3096f234f584869345117cc5bb4e390d4dadca28e0c8
|
|
4
|
+
data.tar.gz: e49e82c1178044f981dcfb4d07a7549918acbe0e04d9d96f58ead72031a529a6
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 0be32828cc23fa885eb8876cb66bd8da89e5a2e18ba1f3173c7fd76bc7b32034011a723903533ec046f7af3dcd4f4b1f9d01f08d91bb0fef498169b8aaae37cc
|
|
7
|
+
data.tar.gz: 974ad82acd6cbeaf3f02df995eb422386a68843b9708f72b7ad610105e4fc06bafc8e9bb2f38967f931cb662d4aab3a598c44cec33985335ed59d2b5618dd00b
|
data/.travis.yml
CHANGED
|
@@ -3,6 +3,12 @@ language: ruby
|
|
|
3
3
|
services:
|
|
4
4
|
- docker
|
|
5
5
|
rvm:
|
|
6
|
-
- 2.
|
|
7
|
-
before_install:
|
|
8
|
-
|
|
6
|
+
- 2.5.1
|
|
7
|
+
before_install:
|
|
8
|
+
- wget https://apt.puppetlabs.com/puppet5-release-trusty.deb
|
|
9
|
+
- sudo dpkg -i puppet5-release-trusty.deb
|
|
10
|
+
- sudo apt-get update
|
|
11
|
+
- sudo apt install -y pdk
|
|
12
|
+
- gem install bundler
|
|
13
|
+
script:
|
|
14
|
+
- bundle exec pdqtest setup && bundle exec rake spec
|
data/doc/acceptance_tests.md
CHANGED
|
@@ -1,37 +1,65 @@
|
|
|
1
1
|
# Acceptance tests
|
|
2
2
|
* Acceptance tests run within a Docker container managed by PDQTest
|
|
3
3
|
* The Docker container breaks all the rules of Docker and runs a full version of Systemd to allow complete testing of Puppet code in the most portable way (basically treat docker as a high speed VM)... This is deliberate - PDQTest exists to get results, not be a perfect Docker app.
|
|
4
|
-
* There are
|
|
4
|
+
* There are three supported docker images:
|
|
5
|
+
* Centos 7
|
|
6
|
+
* Ubuntu 16.04
|
|
7
|
+
* Windows (microsoft/windowsservercore)
|
|
5
8
|
* Centos is used by default
|
|
6
9
|
* Ubuntu will be used if your `metadata.json` declares compatibility with Ubuntu
|
|
7
|
-
*
|
|
8
|
-
|
|
9
|
-
*
|
|
10
|
-
|
|
11
|
-
*
|
|
10
|
+
* Windows will be used if your `metadata.json` declares compatibility with
|
|
11
|
+
Windows
|
|
12
|
+
* Centos is great for mocking systems like AIX... if you replace OS binaries as
|
|
13
|
+
required in the `__setup.sh` scripts
|
|
14
|
+
* If you have a specific container you want to use, pass `--image-name` on the
|
|
15
|
+
command line, it accepts a comma delimited list of image names to test on
|
|
16
|
+
* The container will only be started if at least one example file is present
|
|
17
|
+
**and contains the correct magic marker**
|
|
18
|
+
* You can get a shell on the docker container if needed, see
|
|
19
|
+
[Debugging failed builds](#debugging-failed-builds)
|
|
12
20
|
* See the [docker_images](../docker_images) folder for examples
|
|
13
21
|
|
|
14
22
|
### Test workflow
|
|
15
|
-
1. Scan for all example files under `/examples`. Files must end in `.pp` and
|
|
23
|
+
1. Scan for all example files under `/examples`. Files must end in `.pp` and
|
|
24
|
+
contain the magic marker `#@PDQTest` or `#@PDQTestWin` to be processed
|
|
16
25
|
2. If example files are present, start the docker container
|
|
17
26
|
3. For each example file:
|
|
18
|
-
* Check for a file at `/spec/acceptance/EXAMPLE_NAME__setup.sh`,
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
27
|
+
* Check for a file at `/spec/acceptance/EXAMPLE_NAME__setup.(sh|ps1)`, If it
|
|
28
|
+
exists, run it inside the container. This is a useful place to install
|
|
29
|
+
preqrequisites, edit files, install mock services, clean up after other
|
|
30
|
+
tests, etc.
|
|
31
|
+
* Check for a file at `/spec/acceptance/EXAMPLE_NAME__before.(bats|pats)`, If
|
|
32
|
+
it exists run BATS or PATS against it. This is normally used to check the
|
|
33
|
+
system state is clean or that any test prerequisites have been setup
|
|
34
|
+
correctly
|
|
35
|
+
* Run `puppet apply` on the example file twice (to check idempotency)
|
|
36
|
+
* Check for a file at `/spec/acceptance/EXAMPLE_NAME.(bats|pats)`, If it
|
|
37
|
+
exists run BATS against it. This is normally used to check the state of the
|
|
38
|
+
system after running puppet. You can do things like check services are
|
|
39
|
+
running, check files edited correctly, or basically anything that you can
|
|
40
|
+
write in bash!
|
|
22
41
|
4. Destroy the container unless we were asked to keep it with `--keep-container`
|
|
23
42
|
|
|
24
|
-
Note: `EXAMPLE_NAME` is the example filename minus the directory and `.pp`, eg
|
|
43
|
+
Note: `EXAMPLE_NAME` is the example filename minus the directory and `.pp`, eg
|
|
44
|
+
the `EXAMPLE_NAME` for `examples/foo.pp` would just be `foo`.
|
|
25
45
|
|
|
26
46
|
### Example files
|
|
27
47
|
* Found inside `/examples`
|
|
28
48
|
* Regular puppet code
|
|
29
49
|
* Will be executed _twice_ (to check for idempotency) with `puppet apply`
|
|
30
|
-
* _MUST_ contain the magic marker `#@PDQTest` on a line at the
|
|
31
|
-
|
|
50
|
+
* _MUST_ contain the magic marker `#@PDQTest` or `#@PDQTestWin` on a line at the
|
|
51
|
+
top of the file to indicate that this test should be processed by PDQTest
|
|
52
|
+
* Basically the same as a regular puppet
|
|
53
|
+
[smoke test](https://docs.puppet.com/puppet/latest/tests_smoke.html#module-smoke-testing) but run automatically and with system state tests
|
|
32
54
|
|
|
33
55
|
### BATS tests
|
|
34
|
-
If you've never seen a BATS test
|
|
56
|
+
If you've never seen a [BATS](https://github.com/bats-core/bats-core) test
|
|
57
|
+
before and have previously been writing server spec code, you'll probably kick
|
|
58
|
+
youself when you see how simple they are.
|
|
59
|
+
|
|
60
|
+
BATS lets you run tests anywhere you can run BASH.
|
|
61
|
+
|
|
62
|
+
Here's an example:
|
|
35
63
|
|
|
36
64
|
```BASH
|
|
37
65
|
# Tests are really easy! just the exit status of running a command...
|
|
@@ -41,9 +69,13 @@ If you've never seen a BATS test before and have previously been writing server
|
|
|
41
69
|
}
|
|
42
70
|
```
|
|
43
71
|
|
|
44
|
-
Tests are all written in BASH and the testcase passes if the stanza returns
|
|
72
|
+
Tests are all written in BASH and the testcase passes if the stanza returns
|
|
73
|
+
zero. This means that basically any Linux/Unix sysadmin is now empowered to
|
|
74
|
+
write Testcases and do TDD - score!
|
|
45
75
|
|
|
46
|
-
Since our tests are written in BASH, there are of course all the usual bash
|
|
76
|
+
Since our tests are written in BASH, there are of course all the usual bash
|
|
77
|
+
quirks such as failing on incorrect spacing, bizzare variable quoting etc,
|
|
78
|
+
but given the simplicity gained its a worthwhile tradeoff.
|
|
47
79
|
|
|
48
80
|
Consider the following (real) test:
|
|
49
81
|
|
|
@@ -53,10 +85,43 @@ Consider the following (real) test:
|
|
|
53
85
|
}
|
|
54
86
|
```
|
|
55
87
|
|
|
56
|
-
Here, we have done exactly what it looks like we have done - checked for the
|
|
88
|
+
Here, we have done exactly what it looks like we have done - checked for the
|
|
89
|
+
value of a particular setting in a text file. Since our tests our plain old
|
|
90
|
+
BASH, it means we can do things like test daemons are running with `systemctl`,
|
|
91
|
+
test ports are open with `netstat` and do complete system tests `wget` and
|
|
92
|
+
`curl`. Cool!
|
|
93
|
+
|
|
94
|
+
### PATS tests
|
|
95
|
+
[PATS](https://github.com/declarativesystems/pats) is to testing with PowerShell
|
|
96
|
+
as BATS is to testing with BASH. PATS is currently experimental and lets you
|
|
97
|
+
write your tests using the same syntax as BATS but with the body of the tests
|
|
98
|
+
being executed with PowerShell. As always, the exit status of your PowerShell
|
|
99
|
+
fragment is the result of the test. Here's an example that tests the timezone
|
|
100
|
+
has been set as desired. In this case we have shelled out to run `cmd.exe` but
|
|
101
|
+
you could just run pure PowerShell if you like:
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
@test "sets the timezone correctly" {
|
|
105
|
+
cmd /C "tzutil /g | findstr /C:`"New Zealand Standard Time`" "
|
|
106
|
+
}
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
PATS is used for testing on Windows.
|
|
110
|
+
|
|
111
|
+
#### What if my project needs testing on Windows and Linux?
|
|
112
|
+
At present you would need to run `pdqtest` twice - once in a Windows environment
|
|
113
|
+
and again in Linux.
|
|
114
|
+
|
|
115
|
+
This is because Docker doesn't let us run Windows and Linux on the same platform
|
|
116
|
+
at the same time (Because it's not magic...).
|
|
117
|
+
|
|
118
|
+
This probably isn't as big an issue as it looks since most projects are going to
|
|
119
|
+
cater to one specific OS family.
|
|
57
120
|
|
|
58
121
|
#### Worked Example
|
|
59
|
-
Lets say you have two examples, `foo.pp` and `init.pp`. In this case, the full
|
|
122
|
+
Lets say you have two examples, `foo.pp` and `init.pp`. In this case, the full
|
|
123
|
+
range of files to create for acceptance testing would look like this:
|
|
124
|
+
|
|
60
125
|
```
|
|
61
126
|
mycoolmodule
|
|
62
127
|
├── examples
|
|
@@ -78,21 +143,34 @@ mycoolmodule
|
|
|
78
143
|
PDQTest makes it easy to debug failed builds:
|
|
79
144
|
|
|
80
145
|
```shell
|
|
146
|
+
# Centos
|
|
81
147
|
pdqtest shell
|
|
148
|
+
|
|
149
|
+
# Ubuntu
|
|
150
|
+
pdqtest --image-name declarativesystems/pdqtest-ubuntu:2018-08-29-0 shell
|
|
82
151
|
```
|
|
83
152
|
|
|
84
|
-
* Opens a shell inside the docker container that would be used to run
|
|
153
|
+
* Opens a shell inside the default docker container that would be used to run
|
|
154
|
+
tests
|
|
85
155
|
* Your code is available at `/testcase`
|
|
156
|
+
* Use `--image-name` to use a different image (Ubuntu)
|
|
157
|
+
|
|
86
158
|
|
|
87
159
|
```shell
|
|
88
160
|
pdqtest --keep-container all
|
|
89
161
|
```
|
|
90
162
|
* Runs all tests, report pass/fail status
|
|
91
163
|
* Keeps the container Running
|
|
92
|
-
* After testing, the container used to run tests will be left running and a
|
|
164
|
+
* After testing, the container used to run tests will be left running and a
|
|
165
|
+
message will be printed showing how to enter the container used for testing.
|
|
166
|
+
Your code is avaiable at `/testcase`
|
|
93
167
|
* User is responsible for cleaning up the containers created in this mode
|
|
168
|
+
* Shortcut: `make shell` or `.\make.ps1 shell`
|
|
94
169
|
|
|
95
170
|
### Docker privileged mode
|
|
96
|
-
Sometimes you need to run in Docker privileged mode to enable tests to work -
|
|
171
|
+
Sometimes you need to run in Docker privileged mode to enable tests to work -
|
|
172
|
+
not ideal and if anyone else has a better idea please open a ticket with the
|
|
173
|
+
details. When privileged mode is required, run `pdqtest --privileged` and you
|
|
174
|
+
will have access.
|
|
97
175
|
|
|
98
176
|
WARNING: This grants the container access to the host
|
data/doc/caching.md
CHANGED
|
@@ -3,4 +3,8 @@ PDQTest will attempt to cache:
|
|
|
3
3
|
* Puppet modules (via r10k) in `~/.r10k/cache`
|
|
4
4
|
* The yum cache in `~/.pdqtest/cache/yum`
|
|
5
5
|
|
|
6
|
-
Note that since the yum cache is writen to via a docker volume from the
|
|
6
|
+
Note that since the yum cache is writen to via a docker volume from the
|
|
7
|
+
container your running tests in, the files in this directory will be root owned.
|
|
8
|
+
If you need to clear your cache for whatever reason, delete the
|
|
9
|
+
`~/.pdqtest/cache` directory (you will likely need `sudo`) and PDQtest will
|
|
10
|
+
recreate it next time it runs.
|
data/doc/development.md
CHANGED
|
@@ -1,15 +1,26 @@
|
|
|
1
1
|
# Development
|
|
2
2
|
|
|
3
|
-
PRs welcome :) Please ensure suitable tests cover any new functionality and
|
|
3
|
+
PRs welcome :) Please ensure suitable tests cover any new functionality and
|
|
4
|
+
that all tests are passing before and after your development work.
|
|
4
5
|
|
|
5
6
|
## Support
|
|
6
|
-
Interested in commercial support of PDQTest? Please email
|
|
7
|
+
Interested in commercial support of PDQTest? Please email
|
|
8
|
+
sales@declarativesystems.com to discuss your needs.
|
|
9
|
+
|
|
10
|
+
## Debugging
|
|
11
|
+
* run with `--verbosity debug`
|
|
12
|
+
* Debug docker API calls: `export EXCON_DEBUG=debug` or `set EXCON_DEBUG=debug`
|
|
13
|
+
then run `pdqtest` as normal
|
|
7
14
|
|
|
8
15
|
## Contributing
|
|
9
|
-
Bug reports and pull requests are welcome on GitHub at
|
|
16
|
+
Bug reports and pull requests are welcome on GitHub at
|
|
17
|
+
https://github.com/declarativesystems/pdqtest.
|
|
10
18
|
|
|
11
19
|
### Running tests
|
|
12
|
-
* PDQTest includes a comprehensive tests for core library functions. Please
|
|
20
|
+
* PDQTest includes a comprehensive tests for core library functions. Please
|
|
21
|
+
ensure tests pass before and after any PRs
|
|
13
22
|
* Run all tests `bundle exec rake spec`
|
|
14
23
|
* Run specific test file `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb`
|
|
15
|
-
* Run specific test case `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb:99`
|
|
24
|
+
* Run specific test case `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb:99`
|
|
25
|
+
(where 99 is the line number of the test)
|
|
26
|
+
* If your using RubyMine, you can just right-click -> debug
|
data/doc/emoji.md
CHANGED
|
@@ -1,22 +1,33 @@
|
|
|
1
1
|
# Emoji
|
|
2
2
|
|
|
3
|
-
Emoji are used within PDQTest to indicate progress and overall status at the
|
|
3
|
+
Emoji are used within PDQTest to indicate progress and overall status at the
|
|
4
|
+
request of PDQTest user. Emoji are great because by visually scanning for a
|
|
5
|
+
distinctive symbol, the user is able to understand the overall test status
|
|
6
|
+
without having to scan through all of the debug messages.
|
|
4
7
|
|
|
5
|
-
|
|
8
|
+
On windows, there is very limited support for Unicode in the terminal except in
|
|
9
|
+
PowerShell ISE which is not compatible with PDK
|
|
10
|
+
[PDK-1168](https://tickets.puppetlabs.com/browse/PDK-1168).
|
|
6
11
|
|
|
7
|
-
|
|
8
|
-
`😬` Test passed
|
|
12
|
+
On windows, we fallback to output emoticons instead of Emoji
|
|
9
13
|
|
|
10
|
-
|
|
14
|
+
## What do the emoji mean?
|
|
11
15
|
|
|
12
|
-
|
|
13
|
-
`😎` All tests passed
|
|
16
|
+
### Progress
|
|
14
17
|
|
|
15
|
-
|
|
18
|
+
| Symbol | Meaning | Platform |
|
|
19
|
+
| --- | --- | --- |
|
|
20
|
+
| Progress: Test passed | `😬` | `:-)` |
|
|
21
|
+
| Progress: Test failed | `💣` | `●~*` |
|
|
22
|
+
| Overall Status: All tests passed | `😎` | `=D` |
|
|
23
|
+
| Overall Status: One or more tests failed | `💩` | `><(((*>` |
|
|
24
|
+
| Slow operation | `🐌` | `(-_-)zzz` |
|
|
25
|
+
| Platform issue/limitation | - | `(-_-)` |
|
|
16
26
|
|
|
17
27
|
|
|
18
28
|
## Disabling emoji
|
|
19
|
-
In some cases it may be desirable to
|
|
29
|
+
In some cases it may be desirable to disable the emoji, in this case use the
|
|
30
|
+
argument:
|
|
20
31
|
|
|
21
32
|
```
|
|
22
33
|
--disable-emoji
|
data/doc/enabling_testing.md
CHANGED
|
@@ -3,9 +3,21 @@ To add PDQTest to a new or existing puppet module, run the commands:
|
|
|
3
3
|
|
|
4
4
|
```shell
|
|
5
5
|
pdqtest init
|
|
6
|
-
bundle install
|
|
6
|
+
pdk bundle install
|
|
7
7
|
```
|
|
8
8
|
|
|
9
|
-
From the top level directory of your puppet module. This will install PDQTest
|
|
9
|
+
From the top level directory of your puppet module. This will install PDQTest
|
|
10
|
+
into the `Gemfile.project` (for PDK's bundler), and generate an example set of
|
|
11
|
+
acceptance tests.
|
|
10
12
|
|
|
11
|
-
|
|
13
|
+
You **must** run `pdk bundle install` to install PDQTest into PDK's bundle and
|
|
14
|
+
you **must not* run `bundle install` (ever!).
|
|
15
|
+
|
|
16
|
+
For more info see (PDK-1172)[https://tickets.puppetlabs.com/browse/PDK-1172]
|
|
17
|
+
|
|
18
|
+
PDK must already be present on the system for this to work.
|
|
19
|
+
|
|
20
|
+
Note: Your puppet module *must* have a valid `metatadata.json` file. Create
|
|
21
|
+
one before running `pdqtest init` if you don't already have one. If your
|
|
22
|
+
creating a puppet module from scratch, try `pdk new module` to create a
|
|
23
|
+
complete module skeleton that includes a valid version of this file.
|
data/doc/examples.md
CHANGED
|
@@ -1,10 +1,29 @@
|
|
|
1
1
|
# Examples
|
|
2
2
|
|
|
3
3
|
Here are some projects that use PDQTest:
|
|
4
|
-
* https://github.com/geoffwilliams/puppet-motd
|
|
5
|
-
* https://github.com/declarativesystems/download_and_do
|
|
6
|
-
* https://github.com/GeoffWilliams/puppet-filemagic
|
|
7
|
-
* https://github.com/declarativesystems/ssh
|
|
8
|
-
* https://github.com/declarativesystems/puppet-chown_r/tree/master/spec/acceptance
|
|
9
4
|
|
|
10
|
-
|
|
5
|
+
## Linux projects
|
|
6
|
+
* [realmd](https://github.com/GeoffWilliams/puppet-realmd)
|
|
7
|
+
Features mock realmd command
|
|
8
|
+
* [sshkeys](https://github.com/GeoffWilliams/sshkeys)
|
|
9
|
+
Runs real SSH commands to test keys)
|
|
10
|
+
* [sysctl](https://github.com/geoffwilliams/puppet-sysctl)
|
|
11
|
+
Features mock sysctl command that saves state between puppet runs
|
|
12
|
+
* [motd](https://github.com/geoffwilliams/puppet-motd)
|
|
13
|
+
A basic module with testing
|
|
14
|
+
* [download_and_do](https://github.com/declarativesystems/download_and_do)
|
|
15
|
+
Test downloading files from local directory and running scripts
|
|
16
|
+
* [filemagic](https://github.com/GeoffWilliams/puppet-filemagic)
|
|
17
|
+
Complicated! and uses rspec tests on the ruby component of the module
|
|
18
|
+
* [ssh](https://github.com/declarativesystems/ssh)
|
|
19
|
+
Fires up a real SSH server and tests status
|
|
20
|
+
* [chown_r](https://github.com/declarativesystems/puppet-chown_r)
|
|
21
|
+
Checks permissions of files are correct after doing bulk operations with
|
|
22
|
+
`chown -r` in an exec
|
|
23
|
+
|
|
24
|
+
## Windows projects
|
|
25
|
+
* Coming soon!
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
Do you use PDQTest on your own projects? If you have a good public example let
|
|
29
|
+
me know!
|
data/doc/hiera.md
CHANGED
|
@@ -1,15 +1,25 @@
|
|
|
1
1
|
# Hiera
|
|
2
|
-
Under normal circumstances, only a `profile` module would be consuming Hiera
|
|
2
|
+
Under normal circumstances, only a `profile` module would be consuming Hiera
|
|
3
|
+
data directly using the `hiera()` function, and its suggested by many that these
|
|
4
|
+
too fall back to automatic data binding parameters rather then use the `hiera()`
|
|
5
|
+
function directly. In this case it makes more sense to use the excellent
|
|
6
|
+
[Onceover](https://github.com/dylanratcliffe/onceover) tool to perform
|
|
7
|
+
end-to-end testing of your Hiera data, puppet control repository and
|
|
8
|
+
roles/profile modules.
|
|
3
9
|
|
|
4
10
|
That said, there may be occasions where you need to mock hiera data:
|
|
5
|
-
* You have implemented Roles and Profiles as a namespace inside a team module
|
|
6
|
-
|
|
7
|
-
* You
|
|
11
|
+
* You have implemented Roles and Profiles as a namespace inside a team module
|
|
12
|
+
(for multi-tennanting)
|
|
13
|
+
* You have a module that performs `lookup()` lookups directly
|
|
14
|
+
* You intend to drive your module by adding data to hiera and including a class
|
|
15
|
+
to make something happen
|
|
8
16
|
* Your class fails to compile due to missing hiera data
|
|
9
|
-
* You have a separate git repository for your `profile` module and want to be
|
|
17
|
+
* You have a separate git repository for your `profile` module and want to be
|
|
18
|
+
able to test it
|
|
10
19
|
|
|
11
20
|
## Alternative method
|
|
12
|
-
In some cases where it may be easiest to directly inject strings in lieu of
|
|
21
|
+
In some cases where it may be easiest to directly inject strings in lieu of
|
|
22
|
+
setting up a fake hiera:
|
|
13
23
|
|
|
14
24
|
### RSpec Tests
|
|
15
25
|
```ruby
|
|
@@ -29,15 +39,24 @@ class { "foo":
|
|
|
29
39
|
}
|
|
30
40
|
```
|
|
31
41
|
|
|
32
|
-
Note that you would need to duplicate your hard-coded mock data between the
|
|
42
|
+
Note that you would need to duplicate your hard-coded mock data between the
|
|
43
|
+
rspec tests and any acceptance tests.
|
|
33
44
|
|
|
34
|
-
In the more complex cases it may instead be desireable to mock the hiera data in
|
|
45
|
+
In the more complex cases it may instead be desireable to mock the hiera data in
|
|
46
|
+
order to enable Puppet's regular lookup systems to work.
|
|
35
47
|
|
|
36
|
-
## Mocking
|
|
37
|
-
PDQTest
|
|
48
|
+
## Mocking Hiera (RSpec tests)
|
|
49
|
+
PDQTest fully delegates RSpec tests to PDK, so see
|
|
50
|
+
[RSpec docs](https://rspec-puppet.com/documentation/configuration/) for how to
|
|
51
|
+
do this.
|
|
52
|
+
|
|
53
|
+
## Mocking hiera (Acceptance tests)
|
|
54
|
+
PDQTest supports full mocking of Hiera acceptance tests and support for this is
|
|
55
|
+
enabled automatically when `pdqtest init` is run.
|
|
38
56
|
|
|
39
57
|
A basic one-level hierachy is created for you:
|
|
40
58
|
* Hiera configuration file at `spec/fixtures/hiera.yaml`
|
|
41
59
|
* Single hiera data file at `spec/fixtures/hieradata/test.yaml`
|
|
42
60
|
|
|
43
|
-
Any required hiera data can be added to `test.yaml` and will immediately show up
|
|
61
|
+
Any required hiera data can be added to `test.yaml` and will immediately show up
|
|
62
|
+
when lookups are made.
|
data/doc/installation.md
CHANGED
|
@@ -1,15 +1,66 @@
|
|
|
1
1
|
# Installation
|
|
2
|
-
PDQTest
|
|
2
|
+
PDQTest runs on Linux/MAC and Windows systems, with the caveat that:
|
|
3
|
+
* Windows acceptance tests can only be run on Windows
|
|
4
|
+
* Linux acceptance tests can only run on Linux
|
|
5
|
+
If you are using Windows and want to test Linux modules, the easiest way for you
|
|
6
|
+
to run PDQTest is to install virtualisation software and then use
|
|
7
|
+
[Vagrant](http://vagrantup.com/) to create a VM that shares a filesystem with
|
|
8
|
+
your main Windows desktop. This will allow you to edit your puppet code as you
|
|
9
|
+
please and have it instantly show up inside of a Linux VM where you can run
|
|
10
|
+
PDQTest and Docker.
|
|
3
11
|
|
|
4
|
-
|
|
12
|
+
**Do NOT run PDQTest on a managed Puppet node, you may damage the agent**
|
|
13
|
+
|
|
14
|
+
## Linux Instructions
|
|
15
|
+
|
|
16
|
+
1. Install Ruby - you will need a fairly new version of Ruby as Puppet requires
|
|
17
|
+
this. On linux you will probably need development libraries, eg
|
|
18
|
+
`yum groupinstall 'Development Tools'`. Once ruby is installed follow any
|
|
19
|
+
additional setup steps to activate the environment and then check it really
|
|
20
|
+
worked by running `ruby --version` before proceeding. Note that `pdqtest`
|
|
21
|
+
should not be run as `root`. Easy ways to install an up-to-date Ruby:
|
|
22
|
+
* [RVM](https://rvm.io/)
|
|
23
|
+
* [RBENV](https://github.com/rbenv/rbenv)
|
|
5
24
|
2. Make sure `git` is installed - `yum install git`
|
|
6
|
-
3. Install the
|
|
25
|
+
3. Install the [PDK OS package](https://puppet.com/docs/pdk/1.x/pdk_install.html)
|
|
7
26
|
4. Install PDQTest - `gem install pdqtest`
|
|
8
|
-
5. Install bundler (the only sane way to manage Ruby dependencies)
|
|
27
|
+
5. Install bundler (the only sane way to manage Ruby dependencies)
|
|
28
|
+
`gem install bundler`
|
|
9
29
|
6. Install [Docker CE](www.docker.com)
|
|
10
|
-
7. Start the `docker` daemon and make sure the user your running as is in the
|
|
11
|
-
|
|
30
|
+
7. Start the `docker` daemon and make sure the user your running as is in the
|
|
31
|
+
`docker` group. You will need to log out and back in again after doing this
|
|
32
|
+
8. Install the PDQTest docker images by typing `pdqtest setup`
|
|
33
|
+
|
|
34
|
+
## Windows Instructions
|
|
35
|
+
|
|
36
|
+
1. You will need Windows 10 (Windows 10 Enterprise, Professional, or Education)
|
|
37
|
+
and the system your running on must enable
|
|
38
|
+
[VTx](https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_(VT-x))
|
|
39
|
+
which is needed for
|
|
40
|
+
[Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-10)
|
|
41
|
+
running under
|
|
42
|
+
[Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/)
|
|
43
|
+
which we use for testing:
|
|
44
|
+
* Laptops/Desktops - enable VTx in BIOS/UEFI
|
|
45
|
+
* VMs - You **must** run under VMWare and enable VTx in VM settings (as well
|
|
46
|
+
as enabling on the host)
|
|
47
|
+
* Make sure to allocate plenty of CPU and memory
|
|
48
|
+
* Enable Hyper-V (The Hyper-V role cannot be installed on Windows 10 Home)
|
|
49
|
+
2. Install [Docker](http://docker.com/)
|
|
50
|
+
* [Docker for Windows](https://docs.docker.com/docker-for-windows/install)
|
|
51
|
+
installed and
|
|
52
|
+
[windows containers enabled](https://docs.docker.com/docker-for-windows/#switch-between-windows-and-linux-containers)
|
|
53
|
+
* [Docker API port enabled for localhost access](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon)
|
|
54
|
+
```json
|
|
55
|
+
"hosts": ["tcp://127.0.0.1:2375"]
|
|
56
|
+
```
|
|
57
|
+
3. Install [Chocolatey](https://chocolatey.org/install)
|
|
58
|
+
4. Install Ruby 2.4 (Ruby 2.5 doesn't work yet
|
|
59
|
+
[PDK-1171](https://tickets.puppetlabs.com/browse/PDK-1171)):
|
|
60
|
+
`choco install ruby --version 2.4.3.1`
|
|
61
|
+
5. Install PDK: `choco install pdk`
|
|
62
|
+
6. Install bundler `gem install bundler`
|
|
12
63
|
|
|
13
|
-
|
|
64
|
+
**Be sure to read the [Windows notes](windows.md) for guidance on how to run tests
|
|
65
|
+
on Windows**
|
|
14
66
|
|
|
15
|
-
Note: Do *NOT* run PDQTest on a managed Puppet node, you may damage the agent.
|