cem_acpt 0.2.10-universal-java-17 → 0.2.11-universal-java-17
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile.lock +2 -2
- data/README.md +67 -59
- data/lib/cem_acpt/test_runner/run_handler.rb +27 -4
- data/lib/cem_acpt/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: c97a0886b1604384a7e03f5edec960b594842f69502e5b1fcd4d2a6a18ecb3fc
|
4
|
+
data.tar.gz: 8ad5f879c25f70d0050ec0f7fd24891339b7a80271193d2549e8a6a7224d7727
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 2279fa0e8ab932d0f02982cf8cacf6aaf4bf8c0a5e709eeb7e3cd0d093a4712f501c175f2a57f64cd0c441e56fa0c51e4238ab1a196d89037f719194981536a1
|
7
|
+
data.tar.gz: 76ca3f9c58e4f1450b3e442b0edc825b68ea5b533796b34e90963630dc219731238128f44dbe1267979199d06efa1a3cef99913318bb3684af663e377ec8b97f
|
data/Gemfile.lock
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
PATH
|
2
2
|
remote: .
|
3
3
|
specs:
|
4
|
-
cem_acpt (0.2.
|
4
|
+
cem_acpt (0.2.11-universal-java-17)
|
5
5
|
concurrent-ruby (>= 1.1, < 2.0)
|
6
6
|
deep_merge (>= 1.2, < 2.0)
|
7
7
|
ed25519 (>= 1.2, < 2.0)
|
@@ -68,7 +68,7 @@ GEM
|
|
68
68
|
rspec-its
|
69
69
|
specinfra (~> 2.83.1)
|
70
70
|
sfl (2.3)
|
71
|
-
specinfra (2.83.
|
71
|
+
specinfra (2.83.3)
|
72
72
|
net-scp
|
73
73
|
net-ssh (>= 2.7)
|
74
74
|
net-telnet (= 0.1.1)
|
data/README.md
CHANGED
@@ -1,8 +1,8 @@
|
|
1
1
|
# CemAcpt
|
2
2
|
|
3
|
-
CemAcpt is an acceptance testing library / command line application for running acceptance tests
|
3
|
+
CemAcpt is an acceptance testing library / command line application for running acceptance tests for the CEM modules. It is heavily inspired by Puppet Litmus. CemAcpt is fully compatible with Puppet Litmus acceptance tests.
|
4
4
|
|
5
|
-
CemAcpt was written to facilitate running a single acceptance test file against one or more test nodes concurrently. This is useful when your module supports a lot of different operating systems and modifies low-level components of those operating systems. For CEM, we manage things such as firewall and bootloader configurations which requires us to test against multiple base images of a single operating system (i.e. RHEL 8 with `iptables` and RHEL 8 with `firewalld`). Additionally, we test our module using both Puppet 6 and Puppet 7. As you can see, we now need to test against four test nodes that are all RHEL 8 with slightly different baseline configs. CemAcpt allows us to do so quickly in parallel.
|
5
|
+
CemAcpt was written to facilitate running a single acceptance test file against one or more individual test nodes concurrently, and have each additional acceptance test file do the same. This is useful when your module supports a lot of different operating systems and modifies low-level components of those operating systems. For CEM, we manage things such as firewall and bootloader configurations which requires us to test against multiple base images of a single operating system (i.e. RHEL 8 with `iptables` and RHEL 8 with `firewalld`). Additionally, we test our module using both Puppet 6 and Puppet 7. As you can see, we now need to test against four test nodes that are all RHEL 8 with slightly different baseline configs. CemAcpt allows us to do so quickly in parallel.
|
6
6
|
|
7
7
|
Major differences between Puppet Litmus and CemAcpt are:
|
8
8
|
|
@@ -10,8 +10,72 @@ Major differences between Puppet Litmus and CemAcpt are:
|
|
10
10
|
- Test node image names can be dynamically defined by configurable parsing of the acceptance test name.
|
11
11
|
- This allows your acceptance test names to define the node it will run against.
|
12
12
|
- CemAcpt has it's own CLI for running provisioning of hosts and the test suite and does not use `rake`.
|
13
|
-
- CemAcpt runs everything, including provisioning the test node, creating a temporary manifest on the test node, and running the acceptance test on the test node, in parallel. No matter how many test / host combinations there are, running the test suite will only take as long as the longest running single test / host combo.
|
13
|
+
- CemAcpt runs everything, including provisioning the test node(s), creating a temporary manifest on the test node(s), and running the acceptance test on the test node(s), in parallel. No matter how many test / host combinations there are, running the test suite will only take as long as the longest running single test / host combo.
|
14
14
|
- CemAcpt is configurable via a YAML file.
|
15
|
+
- CemAcpt provides extensive logging, including the ability to save logs to a file and an option to format log output on `stdout` specifically for GitHub Actions.
|
16
|
+
|
17
|
+
## Installation
|
18
|
+
|
19
|
+
### Command-line usage
|
20
|
+
|
21
|
+
Assuming cem_acpt is already configured in your Puppet module, you can run cem_acpt from your command line.
|
22
|
+
|
23
|
+
`cem_acpt` require JRuby 9.3.3.0 or greater. To install and use JRuby with `rvm`:
|
24
|
+
|
25
|
+
```
|
26
|
+
rvm install jruby-9.3.3.0
|
27
|
+
rvm use jruby-9.3.3.0
|
28
|
+
# If you have a Gemfile.lock already
|
29
|
+
rm Gemfile.lock
|
30
|
+
bundle install
|
31
|
+
jruby --server <jruby opts> -S bundle exec cem_acpt <opts>
|
32
|
+
```
|
33
|
+
|
34
|
+
> If you do not delete Gemfile.lock before running `bundle install`, you will most likely encounter dependency version errors. Just delete Gemfile.lock and run `bundle install` again to get past these.
|
35
|
+
|
36
|
+
### Installing into a Puppet module
|
37
|
+
|
38
|
+
Add this line to your module's Gemfile (usually under `group :development`):
|
39
|
+
|
40
|
+
```ruby
|
41
|
+
gem 'cem_acpt', require: false
|
42
|
+
```
|
43
|
+
|
44
|
+
Then, add the following to your `spec_helper_acceptance.rb` (replacing the Puppet Litmus configuration lines):
|
45
|
+
|
46
|
+
```ruby
|
47
|
+
require 'cem_acpt'
|
48
|
+
|
49
|
+
CemAcpt.configure_spec_helper!
|
50
|
+
```
|
51
|
+
|
52
|
+
To use CemAcpt in your acceptance tests, you must call the method `initialize_test_environment!` in your acceptance test's `describe` block before doing anything else:
|
53
|
+
|
54
|
+
```ruby
|
55
|
+
describe 'cem_linux CIS Level 1' do
|
56
|
+
initialize_test_environment!
|
57
|
+
...
|
58
|
+
```
|
59
|
+
|
60
|
+
## Usage
|
61
|
+
|
62
|
+
### RSpec methods
|
63
|
+
|
64
|
+
CemAcpt enables you to use all ServerSpec methods in your acceptance tests, and adds three new methods that can be used (these methods are used the same as in Litmus):
|
65
|
+
|
66
|
+
- `apply_manifest(manifest, opts = {})`: Applies a Puppet manifest given as a string.
|
67
|
+
- `idempotent_apply(manifest, opts = {})`: Applies a Puppet manifest given as a string twice and fails if the second apply reports changes.
|
68
|
+
- `run_shell(command, opts = {})`: Runs a shell command against the test node.
|
69
|
+
|
70
|
+
### Config file
|
71
|
+
|
72
|
+
CemAcpt can use a config file (default path is `./cem_acpt_config.yaml`) to configure it's settings. Below are some of the options available in the config file:
|
73
|
+
|
74
|
+
- `tests`: An array of test names you want to run. These are assumed to exist in the path `spec/acceptance`. You should leave off the suffix `_spec.rb` from the test file names.
|
75
|
+
- `platform`: The backend platform that acceptance tests will run on. Currently, only `gcp` is supported.
|
76
|
+
- `test_data`: Configurations for test data. Allows assigning variables to test data either dynamically or statically.
|
77
|
+
- `node_data`: Configurations for nodes created by the platform. The available options are platform-dependent.
|
78
|
+
- `image_name_builder`: If this key is specified, platforms will be passed a dynamically generated image name based on the configurations under this key.
|
15
79
|
|
16
80
|
## Concepts
|
17
81
|
|
@@ -79,62 +143,6 @@ Rules that allow for processing variables after all other test data rules are ra
|
|
79
143
|
|
80
144
|
Much like `name_pattern_vars`, specifying the `image_name_builder` top-level key in the config allows you to manipulate acceptance test names to create a special test data variable called `image_name`. This is helpful for when you have multiple platform base images and want to use the correct image with the correct test. See [sample_config.yaml](sample_config.yaml) for an example.
|
81
145
|
|
82
|
-
## Installation
|
83
|
-
|
84
|
-
### Installing from RubyGems
|
85
|
-
|
86
|
-
To install the gem locally to use as a CLI tool:
|
87
|
-
|
88
|
-
`gem install cem_acpt --prerelease`
|
89
|
-
|
90
|
-
### Installing into a Puppet module
|
91
|
-
|
92
|
-
Add this line to your module's Gemfile (usually under `group :development`):
|
93
|
-
|
94
|
-
```ruby
|
95
|
-
gem 'cem_acpt', require: false
|
96
|
-
```
|
97
|
-
|
98
|
-
Then, add the following to your `spec_helper_acceptance.rb` (replacing the Puppet Litmus configuration lines):
|
99
|
-
|
100
|
-
```ruby
|
101
|
-
require 'cem_acpt'
|
102
|
-
|
103
|
-
CemAcpt.configure_spec_helper!
|
104
|
-
```
|
105
|
-
|
106
|
-
To use CemAcpt in your acceptance tests, you must call the method `initialize_test_environment!` in your acceptance test's `describe` block before doing anything else:
|
107
|
-
|
108
|
-
```ruby
|
109
|
-
describe 'cem_linux CIS Level 1' do
|
110
|
-
initialize_test_environment!
|
111
|
-
...
|
112
|
-
```
|
113
|
-
|
114
|
-
## Usage
|
115
|
-
|
116
|
-
### RSpec methods
|
117
|
-
|
118
|
-
CemAcpt enables you to use all ServerSpec methods in your acceptance tests, and adds three new methods that can be used (these methods are used the same as in Litmus):
|
119
|
-
|
120
|
-
- `apply_manifest(manifest, opts = {})`: Applies a Puppet manifest given as a string.
|
121
|
-
- `idempotent_apply(manifest, opts = {})`: Applies a Puppet manifest given as a string twice and fails if the second apply reports changes.
|
122
|
-
- `run_shell(command, opts = {})`: Runs a shell command against the test node.
|
123
|
-
|
124
|
-
### Config file
|
125
|
-
|
126
|
-
CemAcpt can use a config file (default path is `./cem_acpt_config.yaml`) to configure it's settings. Below are some of the options available in the config file:
|
127
|
-
|
128
|
-
- `tests`: An array of test names you want to run. These are assumed to exist in the path `spec/acceptance`. You should leave off the suffix `_spec.rb` from the test file names.
|
129
|
-
- `platform`: The backend platform that acceptance tests will run on. Currently, only `gcp` is supported.
|
130
|
-
- `test_data`: Configurations for test data. Allows assigning variables to test data either dynamically or statically.
|
131
|
-
- `node_data`: Configurations for nodes created by the platform. The available options are platform-dependent.
|
132
|
-
- `image_name_builder`: If this key is specified, platforms will be passed a dynamically generated image name based on the configurations under this key.
|
133
|
-
|
134
|
-
### Semantic acceptance test names
|
135
|
-
|
136
|
-
With CemAcpt, acceptance test names can have semantic meaning and influence how your acceptance test nodes are provisioned and how test data is created. The semantic meaning of the test names can be configured in the config file.
|
137
|
-
|
138
146
|
## Development
|
139
147
|
|
140
148
|
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
|
@@ -105,10 +105,7 @@ module CemAcpt
|
|
105
105
|
if result['examples'].empty? && !result['messages'].empty?
|
106
106
|
logger.error(result['messages'].join("\n"))
|
107
107
|
else
|
108
|
-
|
109
|
-
failed.each do |e|
|
110
|
-
logger.error(test_error_msg(runner.node.node_name, e))
|
111
|
-
end
|
108
|
+
handle_example_error_pending_skipped(runner.node.node_name, result['examples'])
|
112
109
|
end
|
113
110
|
else
|
114
111
|
handle_runner_error_results(runner)
|
@@ -118,6 +115,19 @@ module CemAcpt
|
|
118
115
|
end
|
119
116
|
end
|
120
117
|
|
118
|
+
# Handles logging for any failed / skipped / pending examples.
|
119
|
+
def handle_example_error_pending_skipped(node_name, examples)
|
120
|
+
examples.each do |e|
|
121
|
+
next if e['status'] == 'passed'
|
122
|
+
|
123
|
+
if e['status'] == 'pending'
|
124
|
+
logger.info(test_pending_msg(node_name, e))
|
125
|
+
else
|
126
|
+
logger.error(test_error_msg(node_name, e))
|
127
|
+
end
|
128
|
+
end
|
129
|
+
end
|
130
|
+
|
121
131
|
# Handles logging the results of the runners that errored.
|
122
132
|
def handle_runner_error_results(runner)
|
123
133
|
logger.error("SUMMARY: Encountered an error with test #{runner.node.test_data[:test_name]} on node #{runner.node.node_name}")
|
@@ -136,6 +146,19 @@ module CemAcpt
|
|
136
146
|
"Error: #{err.message}",
|
137
147
|
'Backtrace:',
|
138
148
|
err.backtrace.join("\n"),
|
149
|
+
"\n",
|
150
|
+
].join("\n")
|
151
|
+
end
|
152
|
+
|
153
|
+
# Formats a test result for tests that are pending or skipped. Is used for logging.
|
154
|
+
# @param node [String] the name of the node the test ran on
|
155
|
+
# @param result [Hash] the test result to format
|
156
|
+
# @return [String] the formatted test result
|
157
|
+
def test_pending_msg(_, result)
|
158
|
+
[
|
159
|
+
"TEST PENDING / SKIPPED: #{result['full_description']}",
|
160
|
+
"REASON: #{result['pending_message']}",
|
161
|
+
"\n",
|
139
162
|
].join("\n")
|
140
163
|
end
|
141
164
|
|
data/lib/cem_acpt/version.rb
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: cem_acpt
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.2.
|
4
|
+
version: 0.2.11
|
5
5
|
platform: universal-java-17
|
6
6
|
authors:
|
7
7
|
- puppetlabs
|
8
8
|
autorequire:
|
9
9
|
bindir: exe
|
10
10
|
cert_chain: []
|
11
|
-
date: 2022-
|
11
|
+
date: 2022-08-03 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
requirement: !ruby/object:Gem::Requirement
|