This updates the Habitat plugin by doing the following:
- Removing `settings.sh` in favor of Habitat config TOMLs
- Changing deprecated `--format` to `--reporter`
- Cleaning up plan.sh in several ways
- Adding handling for different exit codes
- Removing unnecessary runtime deps
- Vendoring the InSpec archive during build
- Using shebangs that reference Habitat's bash
- Adding error handling for `hab studio enter`/`build` from `habitat/`
- Making `pkg_svc_user` use default `hab` and not `root`
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
* Remove Hab pkg deps in favor of OS binaries
This removes the runtime dependencies on Hab pkgs and instead modifies
the `PATH` environment variable to use the OS binaries where the InSpec
Habitat package is installed.
It should be noted that this is counter to what Habitat intends in most
cases. In general, it is preferable to use only Habitat packages as
runtime dependencies to get all the benefits that Habitat provides.
We elected not to do this for the InSpec Habitat package since the list
of binaries that would need to be installed to support all InSpec
resources would be prohibitively expensive (both in disk space and
network requirements). If you wish to use Habitat packaged binaries with
this package you can use `hab pkg install origin/my-binary --binlink`.
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
* Modify Habitat install example to use `--binlink`
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
* Add `core/git` runtime dep (used for fetching)
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
After digging I see that PR #975 fixed `bundle install` on 2.1.9 about
two years ago. The minimum required version of Ruby for InSpec is 2.2.
This updates our Gemfile to remove any logic for Ruby `< 2.2.2`.
The Gemfile should only be used for development...but I could be wrong
here. Let me know if you think there will be any issues.
Signed-off-by: Jerry Aldrich <jerryaldrichiii@gmail.com>
The artifact doesn't need the gemspec, gemfile or rakefile since we're not shipping tests already. Also there's no need for the changelog or maintainer file. For those a user should reference the github repo since these files are buried deep on the filesystem and not designed to be read through.
Signed-off-by: Tim Smith <tsmith@chef.io>
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.
