Commit graph

12 commits

Author SHA1 Message Date
Ryan Davis
b1c2af209b Corresponding fixes for the move from test/unit/mock to test/fixtures.
Signed-off-by: Ryan Davis <zenspider@chef.io>
2019-11-08 19:20:12 -08:00
Clinton Wolfe
6a6bf2595c docs for users and devs regarding reading the config elements from the config file
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2019-08-28 13:25:49 -04:00
Clinton Wolfe
425f13ef97 Mission-critical extra newline fix
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2019-06-06 15:26:37 -04:00
Clinton Wolfe
9366804335 PR Feedback
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2019-06-06 12:51:22 -04:00
Clinton Wolfe
93481a5814 Developer docs
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2019-06-06 12:51:22 -04:00
Unknown
5c1467dfe9 Update software name from InSpec to Chef Inspec
Signed-off-by: IanMadd <maddaus@protonmail.com>
2019-04-29 15:16:56 -04:00
Clinton Wolfe
fefa6c2ecd
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 14:14:06 -05:00
Matt Ray
ea8d05881b Minor cleanups of plugin documentation. 'Plugin' instead of 'PluginDefinition' (#3527)
Signed-off-by: Matt Ray <matthewhray@gmail.com>
2018-10-18 15:56:04 -04:00
Jerry Aldrich
0b0a0a4d48 Change Inspec to InSpec where appropriate (#3494)
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
2018-10-15 12:09:46 -04:00
Clinton Wolfe
0ced18841f
CLI Plugin Manager SubCommand (#3414)
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2018-09-25 10:29:18 -04:00
Clinton Wolfe
d24e0f0ec9 Plugins V2 API: CLI Command Plugin Type, Again (#3296)
Plugins V2 API: CLI Command Plugin Type

Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
2018-08-16 20:22:28 -04:00
Clinton Wolfe
811318f2f8 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 18:16:32 -04:00