Plugins API v2: Loader, Base API, and Test Harness (#3278)
* Functional tests for userdir option
* Accepts --config-dir CLI option
* Actually loads a config file from the config dir, more cases to test
* Able to load config and verify contents from config-dir
* Functional tests to ensure precedence for config options
* Enable setting config dir via env var
* .inspec, not .inspec.d
* Begin converting PluginCtl to PluginLoader/Registry
* Able to load and partially validate the plugins.json file
* More work on the plugin loader
* Break the world, move next gen stuff to plugin/
* Be sure to require base cli in bundled plugins
* Move test file
* Revert changes to v1 plugin, so we can have a separate one
* Checkpoint commit
* Move v2 plugin work to v2 area
* Move plugins v1 code into an isolated directory
* rubocop fixes
* Rip out the stuff about a user-dir config file, just use a plugin file
* Two psuedocode test file
* Working base API, moock plugin type, and loader.
* Adjust load path to be more welcoming
* Silence circular depencency warning, which was breaking a unit test
* Linting
* Fix plugin type registry, add tests to cover
* Feedback from Jerry
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2018-08-16 22:16:32 +00:00
|
|
|
# Functional tests related to plugin facility
|
2019-06-11 22:24:35 +00:00
|
|
|
require "functional/helper"
|
2018-11-16 22:03:40 +00:00
|
|
|
|
2019-09-17 00:40:51 +00:00
|
|
|
# I wrapped the whole file in a describe to refactor the include and
|
|
|
|
# add parallelization. I didn't want to reindent the whole file until
|
|
|
|
# we know this works well.
|
|
|
|
|
|
|
|
# rubocop:disable Layout/IndentationConsistency
|
|
|
|
|
|
|
|
describe "plugins" do
|
|
|
|
include FunctionalHelper
|
|
|
|
parallelize_me!
|
|
|
|
|
Plugins API v2: Loader, Base API, and Test Harness (#3278)
* Functional tests for userdir option
* Accepts --config-dir CLI option
* Actually loads a config file from the config dir, more cases to test
* Able to load config and verify contents from config-dir
* Functional tests to ensure precedence for config options
* Enable setting config dir via env var
* .inspec, not .inspec.d
* Begin converting PluginCtl to PluginLoader/Registry
* Able to load and partially validate the plugins.json file
* More work on the plugin loader
* Break the world, move next gen stuff to plugin/
* Be sure to require base cli in bundled plugins
* Move test file
* Revert changes to v1 plugin, so we can have a separate one
* Checkpoint commit
* Move v2 plugin work to v2 area
* Move plugins v1 code into an isolated directory
* rubocop fixes
* Rip out the stuff about a user-dir config file, just use a plugin file
* Two psuedocode test file
* Working base API, moock plugin type, and loader.
* Adjust load path to be more welcoming
* Silence circular depencency warning, which was breaking a unit test
* Linting
* Fix plugin type registry, add tests to cover
* Feedback from Jerry
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2018-08-16 22:16:32 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# Loader Errors
|
|
|
|
#=========================================================================================#
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "plugin loader" do
|
|
|
|
it "handles an unloadable plugin correctly" do
|
|
|
|
outcome = inspec_with_env("version", INSPEC_CONFIG_DIR: File.join(config_dir_path, "plugin_error_on_load"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include("ERROR", "Have an error on stdout")
|
|
|
|
_(outcome.stdout).must_include("Could not load plugin inspec-divide-by-zero", "Name the plugin in the stdout error")
|
|
|
|
_(outcome.stdout).wont_include("ZeroDivisionError", "No stacktrace in error by default")
|
|
|
|
_(outcome.stdout).must_include("Errors were encountered while loading plugins", "Friendly message in error")
|
|
|
|
_(outcome.stdout).must_include("Plugin name: inspec-divide-by-zero", "Plugin named in error")
|
|
|
|
_(outcome.stdout).must_include("divided by 0", "Exception message in error")
|
2019-06-11 22:24:35 +00:00
|
|
|
|
2019-07-23 01:44:43 +00:00
|
|
|
assert_exit_code 2, outcome
|
|
|
|
|
|
|
|
# TODO: split
|
2019-06-11 22:24:35 +00:00
|
|
|
outcome = inspec_with_env("version --debug", INSPEC_CONFIG_DIR: File.join(config_dir_path, "plugin_error_on_load"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include("ZeroDivisionError", "Include stacktrace in error with --debug")
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 2, outcome
|
Plugins API v2: Loader, Base API, and Test Harness (#3278)
* Functional tests for userdir option
* Accepts --config-dir CLI option
* Actually loads a config file from the config dir, more cases to test
* Able to load config and verify contents from config-dir
* Functional tests to ensure precedence for config options
* Enable setting config dir via env var
* .inspec, not .inspec.d
* Begin converting PluginCtl to PluginLoader/Registry
* Able to load and partially validate the plugins.json file
* More work on the plugin loader
* Break the world, move next gen stuff to plugin/
* Be sure to require base cli in bundled plugins
* Move test file
* Revert changes to v1 plugin, so we can have a separate one
* Checkpoint commit
* Move v2 plugin work to v2 area
* Move plugins v1 code into an isolated directory
* rubocop fixes
* Rip out the stuff about a user-dir config file, just use a plugin file
* Two psuedocode test file
* Working base API, moock plugin type, and loader.
* Adjust load path to be more welcoming
* Silence circular depencency warning, which was breaking a unit test
* Linting
* Fix plugin type registry, add tests to cover
* Feedback from Jerry
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2018-08-16 22:16:32 +00:00
|
|
|
end
|
|
|
|
end
|
2018-08-17 00:22:28 +00:00
|
|
|
|
2019-01-25 04:24:07 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# Disabling Plugins
|
|
|
|
#=========================================================================================#
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when disabling plugins" do
|
|
|
|
describe "when disabling the core plugins" do
|
|
|
|
it "should not be able to use core-provided commands" do
|
|
|
|
run_result = run_inspec_process("--disable-core-plugins habitat")
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_include 'Could not find command "habitat".'
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-01-25 04:24:07 +00:00
|
|
|
# One might think that this should be code 2 (plugin error)
|
|
|
|
# But because the core plugins are not loaded, 'habitat' is not
|
|
|
|
# a known command, which makes it a usage error, code 1.
|
2019-07-23 01:44:43 +00:00
|
|
|
assert_exit_code 1, run_result
|
2019-01-25 04:24:07 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when disabling the user plugins" do
|
|
|
|
it "should not be able to use user commands" do
|
|
|
|
run_result = run_inspec_process("--disable-user-plugins meaningoflife answer", env: { INSPEC_CONFIG_DIR: File.join(config_dir_path, "meaning_by_path") })
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_include 'Could not find command "meaningoflife"'
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 1, run_result
|
2019-01-25 04:24:07 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-08-17 00:22:28 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# CliCommand plugin type
|
|
|
|
#=========================================================================================#
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "cli command plugins" do
|
|
|
|
it "is able to respond to a plugin-based cli subcommand" do
|
|
|
|
outcome = inspec_with_env("meaningoflife answer", INSPEC_CONFIG_DIR: File.join(config_dir_path, "meaning_by_path"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).wont_include 'Could not find command "meaningoflife"'
|
|
|
|
_(outcome.stderr).must_equal ""
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_equal ""
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 42, outcome
|
2018-08-17 00:22:28 +00:00
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
it "is able to respond to [help subcommand] invocations" do
|
|
|
|
outcome = inspec_with_env("help meaningoflife", INSPEC_CONFIG_DIR: File.join(config_dir_path, "meaning_by_path"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_equal ""
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include "inspec meaningoflife answer"
|
2018-08-17 00:22:28 +00:00
|
|
|
# Full text:
|
|
|
|
# 'Exits immediately with an exit code reflecting the answer to life the universe, and everything.'
|
|
|
|
# but Thor will ellipsify based on the terminal width
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include "Exits immediately"
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-08-17 00:22:28 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
# This is an important test; usually CLI plugins are only activated when their name is present in ARGV
|
2019-06-11 22:24:35 +00:00
|
|
|
it "includes plugin-based cli commands in top-level help" do
|
2019-07-23 01:44:43 +00:00
|
|
|
outcome = inspec_with_env("help", INSPEC_CONFIG_DIR: File.join(config_dir_path, "meaning_by_path"))
|
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include "inspec meaningoflife"
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-08-17 00:22:28 +00:00
|
|
|
end
|
2018-09-18 04:00:54 +00:00
|
|
|
end
|
2018-09-25 14:29:18 +00:00
|
|
|
|
2019-05-02 17:24:18 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# Input plugin type
|
|
|
|
#=========================================================================================#
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "input plugins" do
|
2019-05-03 19:17:12 +00:00
|
|
|
let(:env) { { INSPEC_CONFIG_DIR: "#{config_dir_path}/input_plugin" } }
|
2019-05-02 17:24:18 +00:00
|
|
|
let(:profile) { "#{profile_path}/inputs/plugin" }
|
2019-05-15 22:57:44 +00:00
|
|
|
def run_input_plugin_test_with_controls(controls)
|
|
|
|
cmd = "exec #{profile} --controls #{controls}"
|
|
|
|
run_result = run_inspec_process(cmd, json: true, env: env)
|
|
|
|
run_result.must_have_all_controls_passing
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_be_empty
|
2019-05-15 22:57:44 +00:00
|
|
|
end
|
2019-05-02 17:24:18 +00:00
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when an input is provided only by a plugin" do
|
|
|
|
it "should find the value" do
|
|
|
|
run_input_plugin_test_with_controls("only_in_plugin")
|
2019-05-02 17:24:18 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when an input is provided both inline and by a higher-precedence plugin" do
|
|
|
|
it "should use the value from the plugin" do
|
|
|
|
run_input_plugin_test_with_controls("collide_plugin_higher")
|
2019-05-02 17:24:18 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when an input is provided both inline and by a lower-precedence plugin" do
|
|
|
|
it "should use the value from inline" do
|
|
|
|
run_input_plugin_test_with_controls("collide_inline_higher")
|
2019-05-02 17:24:18 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when examining the event log" do
|
|
|
|
it "should include the expected events" do
|
|
|
|
run_input_plugin_test_with_controls("event_log")
|
2019-05-15 22:01:17 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "when listing available inputs" do
|
|
|
|
it "should list available inputs" do
|
|
|
|
run_input_plugin_test_with_controls("list_events")
|
2019-05-02 17:24:18 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-09-25 14:29:18 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# inspec plugin command
|
|
|
|
#=========================================================================================#
|
|
|
|
# See lib/plugins/inspec-plugin-manager-cli/test
|
2018-09-25 22:51:38 +00:00
|
|
|
|
2019-01-25 04:24:07 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# Plugin Disable Messaging
|
|
|
|
#=========================================================================================#
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "disable plugin usage message integration" do
|
2019-01-25 04:24:07 +00:00
|
|
|
it "mentions the --disable-{user,core}-plugins options" do
|
2019-06-11 22:24:35 +00:00
|
|
|
outcome = inspec("help")
|
|
|
|
["--disable-user-plugins", "--disable-core-plugins"].each do |option|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout).must_include(option)
|
2019-01-25 04:24:07 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# DSL Plugin Support
|
|
|
|
#=========================================================================================#
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "DSL plugin types support" do
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
include PluginFunctionalHelper
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
let(:fixture_path) { File.join(profile_path, "dsl_plugins", "controls", profile_file) }
|
|
|
|
let(:dsl_plugin_path) { File.join(mock_path, "plugins", "inspec-dsl-test", "lib", "inspec-dsl-test.rb") }
|
|
|
|
let(:run_result) { run_inspec_with_plugin("exec #{fixture_path}", plugin_path: dsl_plugin_path) }
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
let(:json_result) { run_result.payload.json }
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "outer profile dsl plugin type support" do
|
|
|
|
let(:profile_file) { "outer_profile_dsl.rb" }
|
|
|
|
it "works correctly with outer_profile dsl extensions" do
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_equal ""
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# The outer_profile_dsl.rb file has control-01, then a call to favorite_grain
|
|
|
|
# (which generates a control), then control-03.
|
|
|
|
# If the plugin exploded, we'd see control-01 but not control-03
|
2019-06-11 22:24:35 +00:00
|
|
|
controls = json_result["profiles"][0]["controls"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(controls.count).must_equal 3
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# We expect the second controls id to be 'sorghum'
|
|
|
|
# (this is the functionality of the outer_profile_dsl we installed)
|
2019-06-11 22:24:35 +00:00
|
|
|
generated_control = json_result["profiles"][0]["controls"][1]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(generated_control["id"]).must_equal "sorghum"
|
|
|
|
_(generated_control["results"][0]["status"]).must_equal "passed"
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "control dsl plugin type support" do
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
let(:profile_file) { "control_dsl.rb" }
|
|
|
|
it "works correctly with control dsl extensions" do
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_equal ""
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# The control_dsl.rb file has one control, with a describe-01, then a call to favorite_fruit, then describe-02
|
|
|
|
# If the plugin exploded, we'd see describe-01 but not describe-02
|
2019-06-11 22:24:35 +00:00
|
|
|
results = json_result["profiles"][0]["controls"][0]["results"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(results.count).must_equal 2
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# We expect the descriptions to include that the favorite fruit is banana
|
|
|
|
# (this is the functionality of the control_dsl we installed)
|
2019-06-11 22:24:35 +00:00
|
|
|
first_description_section = json_result["profiles"][0]["controls"][0]["descriptions"].first
|
2019-09-30 22:31:55 +00:00
|
|
|
_(first_description_section).wont_be_nil
|
|
|
|
_(first_description_section["label"]).must_equal "favorite_fruit"
|
|
|
|
_(first_description_section["data"]).must_equal "Banana"
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "describe dsl plugin type support" do
|
|
|
|
let(:profile_file) { "describe_dsl.rb" }
|
|
|
|
it "works correctly with describe dsl extensions" do
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_equal ""
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# The describe_dsl.rb file has one control, with
|
|
|
|
# describe-01, describe-02 which contains a call to favorite_vegetable, then describe-03
|
|
|
|
# If the plugin exploded, we'd see describe-01 but not describe-02
|
2019-06-11 22:24:35 +00:00
|
|
|
results = json_result["profiles"][0]["controls"][0]["results"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(results.count).must_equal 3
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# We expect the description of describe-02 to include the word aubergine
|
|
|
|
# (this is the functionality of the describe_dsl we installed)
|
2019-06-11 22:24:35 +00:00
|
|
|
second_result = json_result["profiles"][0]["controls"][0]["results"][1]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(second_result).wont_be_nil
|
|
|
|
_(second_result["code_desc"]).must_include "aubergine"
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "test dsl plugin type support" do
|
|
|
|
let(:profile_file) { "test_dsl.rb" }
|
|
|
|
it "works correctly with test dsl extensions" do
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_equal ""
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# The test_dsl.rb file has one control, with
|
|
|
|
# describe-01, describe-02 which contains a call to favorite_legume, then describe-03
|
|
|
|
# If the plugin exploded, we'd see describe-01 but not describe-02
|
2019-06-11 22:24:35 +00:00
|
|
|
results = json_result["profiles"][0]["controls"][0]["results"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(results.count).must_equal 3
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# I spent a while trying to find a way to get the test to alter its name;
|
|
|
|
# that won't work for various setup reasons.
|
|
|
|
# So, it just throws an exception with the word 'edemame' in it.
|
2019-06-11 22:24:35 +00:00
|
|
|
second_result = json_result["profiles"][0]["controls"][0]["results"][1]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(second_result).wont_be_nil
|
|
|
|
_(second_result["status"]).must_equal "failed"
|
|
|
|
_(second_result["message"]).must_include "edemame"
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "resource dsl plugin type support" do
|
|
|
|
let(:profile_file) { "unused" }
|
|
|
|
it "works correctly with test dsl extensions" do
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
# We have to build a custom command line - need to load the whole profile,
|
|
|
|
# so the libraries get loaded.
|
2019-06-11 22:24:35 +00:00
|
|
|
cmd = "exec "
|
|
|
|
cmd += File.join(profile_path, "dsl_plugins")
|
|
|
|
cmd += " --controls=/^rdsl-control/ "
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
run_result = run_inspec_with_plugin(cmd, plugin_path: dsl_plugin_path)
|
2019-09-30 22:31:55 +00:00
|
|
|
_(run_result.stderr).must_equal ""
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# We should have three controls; 01 and 03 just do a string match.
|
|
|
|
# 02 uses the custom resource, which relies on calls to the resource DSL.
|
|
|
|
# If the plugin exploded, we'd see rdsl-control-01 but not rdsl-control-02
|
|
|
|
json_result = run_result.payload.json
|
2019-06-11 22:24:35 +00:00
|
|
|
results = json_result["profiles"][0]["controls"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(results.count).must_equal 3
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
|
|
|
|
# Control 2 has 2 describes; one uses a simple explicit matcher,
|
|
|
|
# while the second uses a matcher defined via a macro provided by the resource DSL.
|
2019-06-11 22:24:35 +00:00
|
|
|
control2_results = results[1]["results"]
|
2019-09-30 22:31:55 +00:00
|
|
|
_(control2_results[0]["status"]).must_equal "passed"
|
|
|
|
_(control2_results[0]["code_desc"]).must_include "favorite_berry"
|
|
|
|
_(control2_results[0]["code_desc"]).must_include "blendable"
|
2019-06-11 22:24:35 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(control2_results[1]["status"]).must_equal "passed"
|
|
|
|
_(control2_results[1]["code_desc"]).must_include "favorite_berry"
|
|
|
|
_(control2_results[1]["code_desc"]).must_include "have drupals"
|
Plugin Type: DSLs (#3557)
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
2018-11-29 19:14:06 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-09-27 22:46:35 +00:00
|
|
|
#=========================================================================================#
|
|
|
|
# Train Plugin Support
|
|
|
|
#=========================================================================================#
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
describe "train plugin support" do
|
|
|
|
describe "when a train plugin is installed" do
|
|
|
|
it "can run inspec detect against a URL target" do
|
|
|
|
outcome = inspec_with_env("detect -t test-fixture://", INSPEC_CONFIG_DIR: File.join(config_dir_path, "train-test-fixture"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2018-09-27 22:46:35 +00:00
|
|
|
lines = outcome.stdout.split("\n")
|
2019-09-30 22:31:55 +00:00
|
|
|
_(lines.grep(/Name/).first).must_include("test-fixture")
|
|
|
|
_(lines.grep(/Name/).first).wont_include("train-test-fixture")
|
|
|
|
_(lines.grep(/Release/).first).must_include("0.1.0")
|
|
|
|
_(lines.grep(/Families/).first).must_include("os")
|
|
|
|
_(lines.grep(/Families/).first).must_include("windows")
|
|
|
|
_(lines.grep(/Families/).first).must_include("unix")
|
|
|
|
_(lines.grep(/Arch/).first).must_include("mock")
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_be_empty
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-09-27 22:46:35 +00:00
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
it "can run inspec detect against a test-fixture backend" do
|
|
|
|
outcome = inspec_with_env("detect -b test-fixture", INSPEC_CONFIG_DIR: File.join(config_dir_path, "train-test-fixture"))
|
2018-09-27 22:46:35 +00:00
|
|
|
lines = outcome.stdout.split("\n")
|
2019-09-30 22:31:55 +00:00
|
|
|
_(lines.grep(/Name/).first).must_include("test-fixture")
|
|
|
|
_(lines.grep(/Name/).first).wont_include("train-test-fixture")
|
|
|
|
_(lines.grep(/Release/).first).must_include("0.1.0")
|
|
|
|
_(lines.grep(/Families/).first).must_include("os")
|
|
|
|
_(lines.grep(/Families/).first).must_include("windows")
|
|
|
|
_(lines.grep(/Families/).first).must_include("unix")
|
|
|
|
_(lines.grep(/Arch/).first).must_include("mock")
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_be_empty
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-09-27 22:46:35 +00:00
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
it "can run inspec shell and read a file" do
|
|
|
|
outcome = inspec_with_env("shell -t test-fixture:// -c 'file(\"any-path\").content'", INSPEC_CONFIG_DIR: File.join(config_dir_path, "train-test-fixture"))
|
2019-07-25 00:26:11 +00:00
|
|
|
skip_windows!
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout.chomp).must_equal "Lorem Ipsum"
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_be_empty
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-09-27 22:46:35 +00:00
|
|
|
end
|
|
|
|
|
2019-06-11 22:24:35 +00:00
|
|
|
it "can run inspec shell and run a command" do
|
|
|
|
outcome = inspec_with_env("shell -t test-fixture:// -c 'command(\"echo hello\").exit_status'", INSPEC_CONFIG_DIR: File.join(config_dir_path, "train-test-fixture"))
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-07-25 00:26:11 +00:00
|
|
|
skip_windows!
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout.chomp).must_equal "17"
|
2018-09-27 22:46:35 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_be_empty
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
|
|
|
|
|
|
|
# TODO: split
|
|
|
|
outcome = inspec_with_env("shell -t test-fixture:// -c 'command(\"echo hello\").stdout'", INSPEC_CONFIG_DIR: File.join(config_dir_path, "train-test-fixture"))
|
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stdout.chomp).must_equal "Mock Command Result stdout"
|
2019-07-23 01:44:43 +00:00
|
|
|
|
2019-09-30 22:31:55 +00:00
|
|
|
_(outcome.stderr).must_be_empty
|
2019-07-23 01:44:43 +00:00
|
|
|
|
|
|
|
assert_exit_code 0, outcome
|
2018-09-27 22:46:35 +00:00
|
|
|
end
|
|
|
|
end
|
2019-01-28 01:46:42 +00:00
|
|
|
end
|
2019-09-17 00:40:51 +00:00
|
|
|
|
|
|
|
end
|