cem_acpt 0.2.10-universal-java-17 → 0.2.12-universal-java-17

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 5d59f3f4432694cd766fc5ca304ade0cad8cb681849181256d8c1ced3ba68438
4
- data.tar.gz: eff162b600769222a8d0670e2a528cc389eae0407e35a1d6671c1518248c0480
3
+ metadata.gz: 3b50bf460a869a9d3d9bc39bfb173ff72a445d1cb0ad530592802dc7746a69ca
4
+ data.tar.gz: 464f0e379e111ca1c7ed6dd0247e1ab693158ed130836d44367d4830310d54e7
5
5
  SHA512:
6
- metadata.gz: a8124eec84379d5737fc4e04327ded0de1da8cb43c724a51cfd892c150823b58b14f9f6f99ec24adff5a7bc69302595e79de34501326c1c6e85fe1b0fa3c99cc
7
- data.tar.gz: c6ea839545a9c00779aec17f331a9769a743baf7e05654f25d9efaa0e7edd8490dc528342ba75cdef171dc79328ad0431b204310c53d736f0b8bd2faf71ac6b4
6
+ metadata.gz: c076c5eba5b8e3c297e1fcdaa39ea1d1a44387d90de40950f4d32e4b95866a9a50054fe4c20b226125535c105b3dd6675e7924f78f106a315112561002f4d0bd
7
+ data.tar.gz: efb086e7b909febc6bd777f1456562125c911ac7216e1a815800a3fcc1c9393b807a685165fe8678259aae6b5bb218cbb4afc7ec0b87416b483eb3fcf3603130
data/Gemfile.lock CHANGED
@@ -1,7 +1,7 @@
1
1
  PATH
2
2
  remote: .
3
3
  specs:
4
- cem_acpt (0.2.10-universal-java-17)
4
+ cem_acpt (0.2.12-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.2)
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 against the CEM modules. It is heavily inspired by Puppet Litmus. CemAcpt is fully compatible with Puppet Litmus 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.
@@ -242,7 +242,7 @@ module CemAcpt::Platform::Gcp
242
242
  apply_cmd << "--hiera_config=#{opts[:apply][:hiera_config]}" if opts[:apply][:hiera_config]
243
243
  apply_cmd << '--debug' if opts[:apply][:debug]
244
244
  apply_cmd << '--noop' if opts[:apply][:noop]
245
- apply_cmd << '--detailed-exitcodes' if opts[:apply][:detailed_exitcodes]
245
+ apply_cmd << '--detailed-exitcodes' if opts[:apply][:detailed_exit_codes]
246
246
 
247
247
  run_shell(
248
248
  instance_name,
@@ -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
- failed = result['examples'].reject { |e| e['status'] == 'passed' }
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
 
@@ -1,5 +1,5 @@
1
1
  # frozen_string_literal: true
2
2
 
3
3
  module CemAcpt
4
- VERSION = '0.2.10'
4
+ VERSION = '0.2.12'
5
5
  end
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.10
4
+ version: 0.2.12
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-07-26 00:00:00.000000000 Z
11
+ date: 2022-09-26 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  requirement: !ruby/object:Gem::Requirement