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.
* Unit tests passing for loading Train plugins
* detect works with a train test fixture
* Update fixture install of train-fixture-plugin
* Add functional tests for detect and shell when talking to a train plugin backend
* Update docs to reflect availability of Train plugins
* Functional test for install train plugin from path
* Working install train plugin from path, more tests for installing from odd locations
* PR Feedback
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
* Sketch out in comments the unit and functional tests for the installer
* Make a test fixture gem, v0.1.0
* Add a 0.2.0 version of the test fixture gem, this one with a dependency
* Add a fixture with a pre-installed gem
* Correct test-fixture 0.1.0 gem
* Moockup of installed inspec-test-fixture gems
* Uggh add gemspec files to mock installs
* Update gem fixtures, and add a script that does it for me
* Able to load from and list privately managed gems
# Conflicts:
# lib/inspec/plugin/v2/loader.rb
* Expanded tests, starting on implementation of installer
# Conflicts:
# test/unit/plugin/v2/loader_test.rb
* Install plugin from local gem file works
* Writes the plugins.json file; needs refactor
* Gem install works; no version pinning
* Install with pinned version works
* Install from path works
* update works
* Validation for uninstall
* Uninstall from path works
* Uninstaller works on gems
* Add search to installer API.
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
* 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>