cem_acpt 0.2.4 → 0.6.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1eb607b0dd6b47c759056a0aa3c1c50d1d304b8aeb604bb7fe2ce5e8738a39b8
-  data.tar.gz: e2733d6abe61cfae7124d4ad8527d2ef2c1862e8ed9aae14933115f3e09ace6f
+  metadata.gz: 4936d14749b4fc458a1eb938299c091e45c28c69a838efe947edb1510a10f151
+  data.tar.gz: 52b205f0be2bffa478a474c50bd0686e4ba32f2cec69d710b2a89ecde94c45c3
 SHA512:
-  metadata.gz: cd2429510a3d927e809b5459c6af5893a1786f19398c861a540de45490ef772944dbd05889a244c5b7be1e2ead068df5547baa9da9f74fed99a3fa47daac8c2d
-  data.tar.gz: 79eb5728f077fadc64eff99ffd8b665c06abf2aa420c3b164991928dfa561af7dc349b570be6ab174e14f0fae87422b10054c79973c0547c5c25338f0861d94c
+  metadata.gz: 96d81ee34960856f0accf22efec6aa3a12f34abf6b9137c43f886102d8a210eca2e907ff2cd2d0d01f6ce37026f9bf6b70c1ba07fd495ff3ad247ae6c3f713fb
+  data.tar.gz: 46a2f685ede232a010f26e8968666011c8ddfdf690f26df1fc11d3aa3e062d021db56df42854964a8b114b2a2d046127c47dba9b1f87334dd18160aeb2ff7367

data/.github/workflows/spec.yml

@@ -0,0 +1,30 @@
+name: Unit Tests
+
+on:
+  workflow_dispatch:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+    branches:
+      - main
+    tags:
+      - v.*
+
+jobs:
+  tests:
+    name: RSpec tests
+    runs-on: ubuntu-20.04
+    steps:
+      - name: Checkout Source
+        uses: actions/checkout@v3
+
+      - name: Set up Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: 3.2
+          bundler-cache: true
+
+      - name: Run RSpec
+        run: |
+          bundle exec rake spec

data/Gemfile

@@ -1,7 +1,8 @@
-source "https://rubygems.org"
+# frozen_string_literal: true
+source 'https://rubygems.org'
 
 # Specify your gem's dependencies in cem_acpt.gemspec
 gemspec
 
-gem "rake", "~> 12.0"
-gem "rspec", "~> 3.0"
+gem 'rake', '>= 12.0'
+gem 'rspec', '>= 3.0'

data/Gemfile.lock

@@ -1,89 +1,141 @@
 PATH
   remote: .
   specs:
-    cem_acpt (0.2.4)
-      concurrent-ruby (~> 1.1.9)
-      deep_merge (~> 1.2.2)
-      net-ssh (~> 7.0.0.beta1)
-      puppet-modulebuilder (> 0.0.1)
-      rake
-      rspec
-      serverspec-cem-acpt
+    cem_acpt (0.6.0)
+      async-http (>= 0.60, < 0.70)
+      bcrypt_pbkdf (>= 1.0, < 2.0)
+      concurrent-ruby (>= 1.1, < 2.0)
+      deep_merge (>= 1.2, < 2.0)
+      ed25519 (>= 1.2, < 2.0)
+      net-ssh (>= 7.1, < 7.2)
+      parallel (~> 1.22)
+      puppet-modulebuilder (>= 0.0.1)
+      ruby-terraform (~> 1.7)
+      serverspec (~> 2.42)
 
 GEM
   remote: https://rubygems.org/
   specs:
     ast (2.4.2)
-    concurrent-ruby (1.1.10)
+    async (2.5.0)
+      console (~> 1.10)
+      io-event (~> 1.1)
+      timers (~> 4.1)
+    async-http (0.60.1)
+      async (>= 1.25)
+      async-io (>= 1.28)
+      async-pool (>= 0.2)
+      protocol-http (~> 0.24.0)
+      protocol-http1 (~> 0.15.0)
+      protocol-http2 (~> 0.15.0)
+      traces (>= 0.8.0)
+    async-io (1.34.3)
+      async
+    async-pool (0.4.0)
+      async (>= 1.25)
+    bcrypt_pbkdf (1.1.0)
+    coderay (1.1.3)
+    concurrent-ruby (1.2.2)
+    console (1.16.2)
+      fiber-local
     deep_merge (1.2.2)
     diff-lcs (1.5.0)
+    ed25519 (1.3.0)
+    fiber-local (1.0.0)
+    hamster (3.0.0)
+      concurrent-ruby (~> 1.0)
+    immutable-struct (2.4.1)
+    io-event (1.1.7)
+    json (2.6.3)
+    lino (3.1.0)
+      hamster (~> 3.0)
+      open4 (~> 1.3)
+    method_source (1.0.0)
     minitar (0.9)
     multi_json (1.15.0)
-    net-scp (3.0.0)
-      net-ssh (>= 2.6.5, < 7.0.0)
-    net-ssh (7.0.0.beta1)
+    net-scp (4.0.0)
+      net-ssh (>= 2.6.5, < 8.0.0)
+    net-ssh (7.1.0)
     net-telnet (0.1.1)
+    open4 (1.3.4)
     parallel (1.22.1)
-    parser (3.1.2.0)
+    parser (3.2.1.1)
       ast (~> 2.4.1)
-    pathspec (1.0.0)
+    pathspec (1.1.3)
+    protocol-hpack (1.4.2)
+    protocol-http (0.24.1)
+    protocol-http1 (0.15.0)
+      protocol-http (~> 0.22)
+    protocol-http2 (0.15.1)
+      protocol-hpack (~> 1.4)
+      protocol-http (~> 0.18)
+    pry (0.14.2)
+      coderay (~> 1.1)
+      method_source (~> 1.0)
     puppet-modulebuilder (0.3.0)
       minitar (~> 0.9)
       pathspec (>= 0.2.1, < 2.0.0)
     rainbow (3.1.1)
-    rake (12.3.3)
-    regexp_parser (2.5.0)
+    rake (13.0.6)
+    regexp_parser (2.7.0)
     rexml (3.2.5)
-    rspec (3.11.0)
-      rspec-core (~> 3.11.0)
-      rspec-expectations (~> 3.11.0)
-      rspec-mocks (~> 3.11.0)
-    rspec-core (3.11.0)
-      rspec-support (~> 3.11.0)
-    rspec-expectations (3.11.0)
+    rspec (3.12.0)
+      rspec-core (~> 3.12.0)
+      rspec-expectations (~> 3.12.0)
+      rspec-mocks (~> 3.12.0)
+    rspec-core (3.12.1)
+      rspec-support (~> 3.12.0)
+    rspec-expectations (3.12.2)
       diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
+      rspec-support (~> 3.12.0)
     rspec-its (1.3.0)
       rspec-core (>= 3.0.0)
       rspec-expectations (>= 3.0.0)
-    rspec-mocks (3.11.1)
+    rspec-mocks (3.12.4)
       diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
-    rspec-support (3.11.0)
-    rubocop (1.30.1)
+      rspec-support (~> 3.12.0)
+    rspec-support (3.12.0)
+    rubocop (1.48.1)
+      json (~> 2.3)
       parallel (~> 1.10)
-      parser (>= 3.1.0.0)
+      parser (>= 3.2.0.0)
       rainbow (>= 2.2.2, < 4.0)
       regexp_parser (>= 1.8, < 3.0)
       rexml (>= 3.2.5, < 4.0)
-      rubocop-ast (>= 1.18.0, < 2.0)
+      rubocop-ast (>= 1.26.0, < 2.0)
       ruby-progressbar (~> 1.7)
-      unicode-display_width (>= 1.4.0, < 3.0)
-    rubocop-ast (1.18.0)
-      parser (>= 3.1.1.0)
-    ruby-progressbar (1.11.0)
-    serverspec-cem-acpt (2.42.0)
+      unicode-display_width (>= 2.4.0, < 3.0)
+    rubocop-ast (1.28.0)
+      parser (>= 3.2.1.0)
+    ruby-progressbar (1.13.0)
+    ruby-terraform (1.7.0)
+      immutable-struct (~> 2.4)
+      lino (~> 3.0)
+    serverspec (2.42.2)
       multi_json
       rspec (~> 3.0)
       rspec-its
-      specinfra (~> 2.83.1)
+      specinfra (~> 2.72)
     sfl (2.3)
-    specinfra (2.83.2)
+    specinfra (2.85.0)
       net-scp
       net-ssh (>= 2.7)
       net-telnet (= 0.1.1)
       sfl
-    unicode-display_width (2.1.0)
+    timers (4.3.5)
+    traces (0.9.1)
+    unicode-display_width (2.4.2)
 
 PLATFORMS
-  universal-java-17
-  x86_64-darwin-19
+  x86_64-darwin-20
+  x86_64-linux
 
 DEPENDENCIES
   cem_acpt!
-  rake (~> 12.0)
-  rspec (~> 3.0)
+  pry
+  rake (>= 12.0)
+  rspec (>= 3.0)
   rubocop
 
 BUNDLED WITH
-   2.3.9
+   2.4.6

data/README.md

@@ -1,150 +1,211 @@
 # CemAcpt
 
-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.
+CemAcpt is an acceptance testing library / command line application for running acceptance tests for the CEM modules.
 
-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.
+CemAcpt uses [Terraform](#terraform) for provisioning test nodes, and [Goss](#goss) to execute acceptance tests.
 
-Major differences between Puppet Litmus and CemAcpt are:
+## Installation
 
-- CemAcpt revolves around mapping a single acceptance test file to one or more test hosts.
-- Test node image names can be dynamically defined by configurable parsing of the acceptance test name.
-  - This allows your acceptance test names to define the node it will run against.
-- CemAcpt has it's own CLI for running provisioning of hosts and the test suite and does not use `rake`.
-- 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.
-- CemAcpt is configurable via a YAML file.
+```bash
+gem install cem_acpt
+```
 
-## Concepts
+`cem_acpt` was developed using Ruby 3.2.1, but other Ruby versions may work.
 
-CemAcpt is underpinned with a few core concepts. These concepts shape the architecture and functionality of CemAcpt.
+## Usage
 
-### Platforms
+### Quickstart
 
-Platforms are backends that handle provisioning, interacting with, and destroying test nodes. Platforms typically represent something like a cloud provider or hypervisor, but as long as a platform implements the required methods it could do anything.
+Make sure Terraform is installed and in your PATH. Instructions for installing Terraform can be found [here](https://learn.hashicorp.com/tutorials/terraform/install-cli).Then, navigate to the root of the `cem_linux` module and run the following command:
 
-Platforms are created by creating a file in `lib/cem_acpt/platform`. The name of the platform file is significant as it will be capitalized and used as a classname. PLATFORMS MUST implement the methods stipulated by `lib/cem_acpt/platform/base.rb` in a single module called `Platform` because the platform system will dynamically create the platform class from this module. How the methods are implemented is irrelevant as long as they take the correct input and give the correct output.
+```bash
+cem_acpt --config ./cem_acpt_config.yaml
+```
 
-Platforms will be passed all configuration options under the top-level key `node_data`. Node configuration should be generic and should apply to all test nodes regardless of the test being ran against them. For test-specific configurations, use `test data`.
+### Command-line
 
-See [lib/cem_acpt/platform/gcp.rb](lib/cem_acpt/platform/gcp.rb) for an example of a platform file.
+```bash
+cem_acpt -h | --help
+```
 
-### Tests
+> If you do not delete Gemfile.lock before running `bundle install`, you may encounter dependency version errors. Just delete Gemfile.lock and run `bundle install` again to get past these.
 
-Each acceptance test should be specified in the config under the top-level key `tests`. These tests SHOULD NOT be paths and should not contain the suffix `_spec.rb`. For example, if you have an acceptance test `spec/acceptance/our_acceptance_test_spec.rb`, the tests config would look like this:
+## Test directory structure
 
-```yaml
-tests:
-  - our_acceptance_test
+CemAcpt expects a specific directory structure for your acceptance tests. The directory structure is as follows:
+
+```bash
+spec
+└── acceptance
+    └── <framework>_<os>-<version>_firewalld_<profile>_<level>
+        ├── goss.yaml # Goss test file
+        └── manifest.pp # Puppet manifest to apply
 ```
 
-Aside from ways of manipulating test data outlined below, tests are typically matched one-to-one with a test node.
+For example, the following directory structure would be valid:
 
-### Test data
+```bash
+spec
+└── acceptance
+    └── cis_rhel-8_firewalld_server_2
+        ├── goss.yaml
+        └── manifest.pp
+```
 
-Test data is a collection of data about a specific test that persists through the entire acceptance test suite lifecycle. Specifically, test data is implemented as an array of hashes with each hash representing a single run through the acceptance test suite lifecycle. What this means is that each item in the test data array is couple with a single test node that is provisioned and a single test run against that node. Test data is used to store values that are test-specific, as opposed to node data which is generic.
+The directory name is used to generate test data. See [Test data](#test-data) for more information. The file `goss.yaml` is used as the [Goss](#goss) test file. The file `manifest.pp` is used as the Puppet manifest to apply.
 
-Test data can be configured using the top-level key `test_data`. There are several supported options for manipulating test data:
+## Configuration
 
-#### for_each
+There are several ways to configure CemAcpt which are outlined below in order of precendence. Options specified later in the list will be merged with or override options specified earlier in the list. If an option is specified in multiple places, the last place it is specified will be used.
 
-When specified, should be a hash of `key -> Array` pairs. For each of these pairs, a copy of the test data is made for each item in the array, with that item becoming the value of a variable `key`.
+1. [Environment variables](#environment-variables)
+2. [User-specific config file](#config-file)
+3. [Config file specified by `--config` option](#config-file)
+4. [Command-line options](#command-line-options)
 
-Example:
+You can view your working config by adding the `-Y` flag to any command. This will print the merged config to STDOUT as a YAML document. You can also use the `-X` flag to print an explanation of how the config was merged.
 
-```yaml
-test_data:
-  for_each:
-    collection:
-      - puppet6
-      - puppet7
+### Environment variables
 
-tests:
-  - our_acceptance_test
+Environment variables are the most basic way to configure CemAcpt. They are useful for setting sensitive information like API keys or passwords. Environment variables are prefixed with `CEM_ACPT_` and are converted to the nested structure of the config file, if applicable. Double underscores \(`__`\) are used to separate key levels. For example, the environment variable `CEM_ACPT_NODE_DATA__DISK_SIZE=40` would be converted to the following config:
+
+```yaml
+node_data:
+  disk_size: 40
 ```
 
-In the above config, instead of test data consisting of a single hash, it will have two hashes that have the `collection` variable set to `puppet6` and `puppet7` respectively. This means that there will be two test nodes provisioned and two runs of the test `our_acceptance_test`, one run against each node.
+All environment variables are optional. If an environment variable is not set, the value will be taken from the config file or command-line option. If an environment variable is set, it will be overridden by the same value from the config file or command-line option.
 
-#### vars
+### Config file
 
-Aribitrary key-value pairs that are injected into the test data hashes. Think of these as constants.
+The most common way is to create a config file and pass it to CemAcpt using the `--config` option. The config file should be a YAML file. See [sample_config.yaml](sample_config.yaml) for an example.
 
-#### name_pattern_vars
+You can also create a user-specific config file at `$HOME/.cem_acpt/config.yaml`. This file will be merged with the config file specified by the `--config` option. This is useful for storing sensitive information or making config changes that you don't want to commit to a repo.
 
-A Ruby regex pattern that is matched against the test name with the intent of creating variables from named capture groups. See [sample_config.yaml](sample_config.yaml) for an example.
+Options set in the user-specific config file will be overridden by options set in the config file specified by the `--config` option. Both config files will override options specified by environment variables.
 
-#### vars_post_processing
+### Command-line options
 
-Rules that allow for processing variables after all other test data rules are ran. See [sample_config.yaml](sample_config.yaml) for an example.
+CemAcpt can be configured using command-line options. These options are specified using the `--<option>` syntax. For a full list of options, run `cem_acpt -h`. Options specified on the command-line will override options specified in the config file and environment variables.
 
-### Image name builder
+## Goss
 
-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.
+[Goss](https://github.com/goss-org/goss/blob/master/docs/manual.md) is the core infrastructure testing tool used by CemAcpt. The `goss.yaml` file is used to specify the tests to run. Please see the [Goss documentation](https://github.com/goss-org/goss/blob/master/docs/manual.md#goss-test-creation) for more information on how to write Goss tests.
 
-## Installation
+## Terraform
 
-### Installing from RubyGems
+CemAcpt uses [Terraform](https://www.terraform.io/) for managing the lifecycle of test nodes. Users don't interact with Terraform directly, but you will need it installed to use CemAcpt.
 
-To install the gem locally to use as a CLI tool:
+## Platforms
 
-`gem install cem_acpt --prerelease`
+Platforms are the underlying infrastructure that nodes are provisioned on. Currently, only GCP is supported. Each platform has two parts to it: the [platform](#platform) and the [node data](#node-data).
 
-### Installing into a Puppet module
+### Platform
 
-Add this line to your module's Gemfile (usually under `group :development`):
+A platform represents where nodes are provisioned. Currently, only GCP is supported. Platforms are configured using the top-level key `platform`. For example, the following config would configure a GCP platform:
 
-```ruby
-gem 'cem_acpt', require: false
+```yaml
+platform:
+  name: gcp
+  project: my-project
+  region: us-west1
+  zone: us-west1-b
+  subnetwork: my-subnetwork
 ```
 
-Then, add the following to your `spec_helper_acceptance.rb` (replacing the Puppet Litmus configuration lines):
+### Node data
 
-```ruby
-require 'cem_acpt'
+Node data is a more generic complement to the [platform](#platform) that specifies node-level details for test nodes. Node data is configured using the top-level key `node_data`. For example, the following config would configure node data:
 
-CemAcpt.configure_spec_helper!
+```yaml
+node_data:
+  disk_size: 40
+  machine_type: e2-small
 ```
 
-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:
+### Developing new platforms
+
+Platforms are defined as Ruby files in the `lib/cem_acpt/platform` directory. Each platform file should define a module called `Platform` that implements the following methods:
 
 ```ruby
-describe 'cem_linux CIS Level 1' do
-  initialize_test_environment!
-  ...
+module Platform
+  # @return [Hash] A hash of platform data
+  def platform_data
+    # Return a hash of platform data
+  end
+
+  # @return [Hash] A hash of node data
+  def node_data
+    # Destroy a node
+  end
+end
 ```
 
-## Usage
+Both the `#platform_data` and `#node_data` methods should return a hash. Each method should also also ensure the config is queried for values for each key in each hash. This is enabled by the exposed instance variables `@config` and `@test_data` in the `Platform` module. For an example, see the [GCP platform](lib/cem_acpt/platform/gcp.rb).
 
-### RSpec methods
+## Tests
 
-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):
+Each acceptance test should be specified in the config under the top-level key `tests`. These tests SHOULD NOT be paths, just the test directory name. For example, if you have an acceptance test directory `spec/acceptance/cis_rhel_acceptance_test/*`, the tests config would look like this:
 
-- `apply_manifest(manifest, opts = {})`: Applies a Puppet manifest given as a string.
-- `idempotent_apply(manifest, opts = {})`: Applies a Puppet manifest given as a string twice and fails if the second apply reports changes.
-- `run_shell(command, opts = {})`: Runs a shell command against the test node.
+```yaml
+tests:
+  - our_acceptance_test
+```
 
-### Config file
+Aside from ways of manipulating test data outlined below, tests are typically matched one-to-one with a test node.
+
+## Test data
+
+Test data is a collection of data about a specific test that persists through the entire acceptance test suite lifecycle. Specifically, test data is implemented as an array of hashes with each hash representing a single run through the acceptance test suite lifecycle. What this means is that each item in the test data array is couple with a single test node that is provisioned and a single test run against that node. Test data is used to store values that are test-specific, as opposed to node data which is generic.
+
+Test data can be configured using the top-level key `test_data`. There are several supported options for manipulating test data:
+
+### for_each
+
+When specified, should be a hash of `key -> Array` pairs. For each of these pairs, a copy of the test data is made for each item in the array, with that item becoming the value of a variable `key`.
 
-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:
+Example:
 
-- `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.
-- `platform`: The backend platform that acceptance tests will run on. Currently, only `gcp` is supported.
-- `test_data`: Configurations for test data. Allows assigning variables to test data either dynamically or statically.
-- `node_data`: Configurations for nodes created by the platform. The available options are platform-dependent.
-- `image_name_builder`: If this key is specified, platforms will be passed a dynamically generated image name based on the configurations under this key.
+```yaml
+test_data:
+  for_each:
+    collection:
+      - puppet6
+      - puppet7
 
-### Semantic acceptance test names
+tests:
+  - our_acceptance_test
+```
+
+In the above config, instead of test data consisting of a single hash, it will have two hashes that have the `collection` variable set to `puppet6` and `puppet7` respectively. This means that there will be two test nodes provisioned and two runs of the test `our_acceptance_test`, one run against each node.
+
+### vars
 
-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.
+Aribitrary key-value pairs that are injected into the test data hashes. Think of these as constants.
 
-## Development
+### name_pattern_vars
 
-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.
+A Ruby regex pattern that is matched against the test name with the intent of creating variables from named capture groups. See [sample_config.yaml](sample_config.yaml) for an example.
 
-To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+### vars_post_processing
 
-## Contributing
+Rules that allow for processing variables after all other test data rules are ran. See [sample_config.yaml](sample_config.yaml) for an example.
 
-Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/cem_acpt.
+## Image name builder
 
-## License
+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.
 
-The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
+## The acceptance test lifecycle
+
+- Load and merge the config
+- Create the local test directory under `$HOME/.cem_acpt`
+- Build the Puppet module. Uses current dir if no `module_dir` is specified in the config
+- Copy all relevant files into the local test directory
+  - This includes the Terraform files provided by CemAcpt, as well as the files under the specified acceptance test directory, and the built Puppet module
+- Provision test nodes using Terraform
+  - After the node is created, the contents of the local test directory are copied to the node
+  - Additionally, the Puppet module is installed on the node and Puppet is ran once to apply `manifest.pp`
+  - After, the Goss server endpoints are started and exposed on the node
+- Once node is provisioned, make HTTP get requests to the Goss server endpoints to run the tests
+- Destroy the test nodes
+- Report the results of the tests

data/cem_acpt.gemspec

@@ -26,12 +26,17 @@ Gem::Specification.new do |spec|
   spec.bindir = 'exe'
   spec.executables = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ['lib']
-  spec.add_runtime_dependency 'concurrent-ruby', '~> 1.1.9'
-  spec.add_runtime_dependency 'deep_merge', '~> 1.2.2'
-  spec.add_runtime_dependency 'net-ssh', '~> 7.0.0.beta1'
-  spec.add_runtime_dependency 'puppet-modulebuilder', '> 0.0.1'
-  spec.add_runtime_dependency 'rake'
-  spec.add_runtime_dependency 'rspec'
-  spec.add_runtime_dependency 'serverspec-cem-acpt'
+  #spec.platform = Gem::Platform.local
+  spec.add_runtime_dependency 'async-http', '>= 0.60', '< 0.70'
+  spec.add_runtime_dependency 'concurrent-ruby', '>= 1.1', '< 2.0'
+  spec.add_runtime_dependency 'deep_merge', '>= 1.2', '< 2.0'
+  spec.add_runtime_dependency 'ed25519', '>= 1.2', '< 2.0'
+  spec.add_runtime_dependency 'bcrypt_pbkdf', '>= 1.0', '< 2.0'
+  spec.add_runtime_dependency 'net-ssh', '>= 7.1', '< 7.2'
+  spec.add_runtime_dependency 'parallel', '~> 1.22'
+  spec.add_runtime_dependency 'puppet-modulebuilder', '>= 0.0.1'
+  spec.add_runtime_dependency 'ruby-terraform', '~> 1.7'
+  spec.add_runtime_dependency 'serverspec', '~> 2.42'
+  spec.add_development_dependency 'pry'
   spec.add_development_dependency 'rubocop'
 end