inspec 4.18.51 → 4.18.85

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/Gemfile

@@ -1,11 +0,0 @@
-source 'https://rubygems.org'
-
-gemspec
-
-group :development do
-  gem 'bundler'
-  gem 'byebug'
-  gem 'minitest'
-  gem 'rake'
-  gem 'rubocop', '= 0.49.1' # Need to keep in sync with main InSpec project, so config files will work
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/LICENSE

@@ -1,2 +0,0 @@
-<%= copyright %>
-<%= license_text %>

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/README.md

@@ -1,28 +0,0 @@
-# <%= module_name %> Plugin
-
-This plugin was generated by `inspec init plugin`, and apparently the author, '<%= author_name %>', did not update the README.
-
-## To Install This Plugin
-
-Assuming it has been published to RubyGems, you can install this gem using:
-
-```
-you@machine $ inspec plugin install <%= plugin_name %>
-```
-
-## What This Plugin Does
-
-No idea.
-
-## Developing This Plugin
-
-The generated plugin contains everything a real-world, industrial grade plugin would have, including:
-
-* an (possibly incomplete) implementation of one or more InSpec Plugin Types
-* documentation (you are reading it now)
-* tests, at the unit and functional level
-* a .gemspec, for packaging and publishing it as a gem
-* a Gemfile, for managing its dependencies
-* a Rakefile, for running development tasks
-* Rubocop linting support for using the base InSpec project rubocop.yml (See Rakefile)
-

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/Rakefile

@@ -1,40 +0,0 @@
-# A Rakefile defines tasks to help maintain your project.
-# Rake provides several task templates that are useful.
-
-#------------------------------------------------------------------#
-#                    Test Runner Tasks
-#------------------------------------------------------------------#
-
-# This task template will make a task named 'test', and run
-# the tests that it finds.
-require 'rake/testtask'
-
-Rake::TestTask.new do |t|
-  t.libs.push 'lib'
-  t.test_files = FileList[
-    'test/unit/*_test.rb',
-    'test/functional/*_test.rb',
-  ]
-  t.verbose = true
-  # Ideally, we'd run tests with warnings enabled,
-  # but the dependent gems have many warnings. As this
-  # is an example, let's disable them so the testing
-  # experience is cleaner.
-  t.warning = false
-end
-
-#------------------------------------------------------------------#
-#                    Code Style Tasks
-#------------------------------------------------------------------#
-require 'rubocop/rake_task'
-
-RuboCop::RakeTask.new(:lint) do |t|
-  # Choices of RuboCop rules to enforce are deeply personal.
-  # Here, we set things up so that your plugin will use the Bundler-installed
-  # inspec gem's copy of the InSpec project's rubocop.yml file (which
-  # is indeed packaged with the inspec gem).
-  require 'inspec/globals'
-  inspec_rubocop_yml = File.join(Inspec.src_root, '.rubocop.yml')
-
-  t.options = ['--display-cop-names', '--config', inspec_rubocop_yml]
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/lib/inspec-plugin-template.rb

@@ -1,14 +0,0 @@
-# This file is known as the "entry point."
-# This is the file InSpec will try to load if it
-# thinks your plugin is installed.
-
-# The *only* thing this file should do is setup the
-# load path, then load the plugin definition file.
-
-# Next two lines simply add the path of the gem to the load path.
-# This is not needed when being loaded as a gem; but when doing
-# plugin development, you may need it.  Either way, it's harmless.
-libdir = File.dirname(__FILE__)
-$LOAD_PATH.unshift(libdir) unless $LOAD_PATH.include?(libdir)
-
-require '<%= plugin_name %>/plugin'

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/lib/inspec-plugin-template/cli_command.rb

@@ -1,62 +0,0 @@
-require 'inspec/resource'
-
-module InspecPlugins::<%= module_name %>
-  # This class will provide the actual CLI implementation.
-  # Its superclass is provided by another call to Inspec.plugin,
-  # this time with two args.  The first arg specifies we are requesting
-  # version 2 of the Plugins API.  The second says we are making a CLI
-  # Command plugin component, so please make available any DSL needed
-  # for that.
-  #  In fact, aside from a some housekeeping DSL methods, most of the
-  # DSL provided is that of Thor. Inspec.plugin(2, :cli_command)
-  # promises to return a class that is a subclass of Thor.  So, to add
-  # commands, usage information, and options, use the Thor documentation.
-  class CliCommand < Inspec.plugin(2, :cli_command)
-    # This isn't provided by Thor, but is needed by InSpec so that it can
-    # register the top-level subcommand.  That is to say, subcommand_desc
-    # makes `inspec <%= command_name_dashes %> ...` work.  Args to sub_command_desc are
-    # a usage message, and a short decription.
-    # These will appear when someone has installed the plugin, and then they
-    # run `inspec help`.
-    # Note: if you want your command (or subcommand) to have dashes in it,
-    # use underscores where you want a dash, and Thor will convert them.
-    # Thor will fail to find a command that is directly named with dashes.
-    subcommand_desc '<%= command_name_snake %> [COMMAND]', 'Your Usage Message Here'
-
-    # The usual rhythm for a Thor CLI file is description, options, command method.
-    # Thor just has you call DSL methods in sequence prior to each command.
-
-    # Let's make a command, 'do_something'. This will then be available
-    # as `inspec <%= command_name_dashes %> do-something
-    # (Change this method name to be something sensible for your plugin.)
-
-    # First, provide a usage / description. This will appear
-    # in `inspec help <%= command_name_dashes %>`.
-    # As this is a usage message, you should write the command as it should appear
-    # to the user (if you want it to have dashes, use dashes)
-    desc 'do-something WHAT [OPTIONS]', 'Does something'
-
-    # Let's include an option, -s, to summarize
-    # Refer to the Thors docs; there is a lot you can do here.
-    option :summary, desc: 'Include a total at the bottom', \
-                     type: :boolean, default: true, aliases: [:s]
-
-    # OK, now the actual method itself.  If you provide params, you're telling Thor that
-    # you accept CLI arguments after all options have been consumed.
-    # Note again that the method name has an underscore, but when invoked
-    # on the CLI, use a dash.
-    def do_something(what = 'nothing')
-      # The code here will *only* be executed if someone actually
-      # runs `inspec <%= command_name_dashes %> do-something`.
-
-      # `what` will be the command line arg
-      # `options` will be a hash of CLI option values
-
-      # Talk to the user using the `ui` object (see Inspec::UI)
-      # ui.error('Whoops!')
-
-      ui.warning('This is a generated plugin with a default implementation.  Edit lib/<%= plugin_name %>/cli_command.rb to make it do what you want.')
-      ui.exit(:success) # or :usage_error
-    end
-  end
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/lib/inspec-plugin-template/plugin.rb

@@ -1,53 +0,0 @@
-# Plugin Definition file
-# The purpose of this file is to declare to InSpec what plugin_types (capabilities)
-# are included in this plugin, and provide hooks that will load them as needed.
-
-# It is important that this file load successfully and *quickly*.
-# Your plugin's functionality may never be used on this InSpec run; so we keep things
-# fast and light by only loading heavy things when they are needed.
-
-# Presumably this is light
-require '<%= plugin_name %>/version'
-
-# The InspecPlugins namespace is where all plugins should declare themselves.
-# The 'Inspec' capitalization is used throughout the InSpec source code; yes, it's
-# strange.
-module InspecPlugins
-  # Pick a reasonable namespace here for your plugin.  A reasonable choice
-  # would be the CamelCase version of your plugin gem name.
-  # <%= plugin_name %> => <%= module_name %>
-  module <%= module_name %>
-    # This simple class handles the plugin definition, so calling it simply Plugin is OK.
-    #   Inspec.plugin returns various Classes, intended to be superclasses for various
-    # plugin components. Here, the one-arg form gives you the Plugin Definition superclass,
-    # which mainly gives you access to the hook / plugin_type DSL.
-    #   The number '2' says you are asking for version 2 of the plugin API. If there are
-    # future versions, InSpec promises plugin API v2 will work for at least two more InSpec
-    # major versions.
-    class Plugin < ::Inspec.plugin(2)
-      # Internal machine name of the plugin. InSpec will use this in errors, etc.
-      plugin_name :'<%= plugin_name %>'
-
-      # Define a new CLI subcommand.
-      # The argument here will be used to match against the command line args,
-      # and if the user said `inspec list-resources`, this hook will get called.
-      # Notice that you can define multiple hooks with different names, and they
-      # don't have to match the plugin name.
-
-      # We'd like this to be list-resources, but Thor does not support hyphens
-      # see https://github.com/erikhuda/thor/pull/613
-      cli_command :<%= command_name_snake %> do
-        # Calling this hook doesn't mean the subcommand is being executed - just
-        # that we should be ready to do so. So, load the file that defines the
-        # functionality.
-        # For example, InSpec will activate this hook when `inspec help` is
-        # executed, so that this plugin's usage message will be included in the help.
-        require '<%= plugin_name %>/cli_command'
-
-        # Having loaded our functionality, return a class that will let the
-        # CLI engine tap into it.
-        InspecPlugins::<%= module_name %>::CliCommand
-      end
-    end
-  end
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/lib/inspec-plugin-template/version.rb

@@ -1,8 +0,0 @@
-# This file simply makes it easier for CI engines to update
-# the version stamp, and provide a clean way for the gemspec
-# to learn the current version.
-module InspecPlugins
-  module <%= module_name %>
-    VERSION = '0.1.0'.freeze
-  end
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/fixtures/README.md

@@ -1,24 +0,0 @@
-# Test Fixtures Area
-
-In this directory, you would place things that you need during testing.  For example, if you were making a plugin that counts the number of controls in a profile, you might have a directory tree like this:
-
-```
-  fixtures/
-    profiles/
-      zero-controls/
-        inspec.yml
-        controls/
-      twelve-controls/
-        inspec.yml
-        controls/
-          nine.rb
-          three.rb
-```
-
-When writing your functional tests, you can point InSpec at the various test fixture profiles, and know that when it points at the zero-controls profile, it should find no controls; and when pointed at the twelve-controls profile, it should find 12.
-
-## Using test fixtures provided with the `inspec` source code
-
-InSpec itself ships with many test fixtures - not just profiles, but attribute files, configuration directories, and more.  Examine them at [the fixtures directory](https://github.com/inspec/inspec/tree/master/test/fixtures)
-
-To use them, see the helper.rb file included in the example at test/helper.rb .

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/functional/README.md

@@ -1,12 +0,0 @@
-# Functional Testing Area for Plugins
-
-## What are functional tests?
-
-Functional tests are tests that verify that your plugin works _as would be seen by a user_. Functional tests generally do not have inside knowledge about the inner workings of the plugin.  However a functional test is very interested in changes that your plugin makes to the outside world: exit codes, command output, changes to files on the filesystem, etc.
-
-To be picked up by the Rake tasks as tests, each test file should end in `_test.rb`.
-
-## Unit vs Functional Tests
-
-A practical difference between unit tests and functional tests is that unit tests all run within one process, while functional tests might exercise a CLI plugin by shelling out to an `inspec` invocation in a subprocess, and examining the results.
-

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/functional/inspec_plugin_template_test.rb

@@ -1,110 +0,0 @@
-# Functional Tests for Example Plugin, Resource Lister
-
-# Functional tests are used to verify the behavior of the plugin are as expected, to a user.
-# Functional tests generally do not have inside knowledge of how the plugin works.
-
-# Include our test harness
-require_relative '../helper'
-
-# Because InSpec is a Spec-style test suite, we're going to use Minitest::Spec
-# here, for familiar look and feel. However, this isn't InSpec (or RSpec) code.
-describe 'inspec list-resources core' do
-  # Our helper.rb locates this library from the InSpec install that
-  # Bundler installed for us. If we want its methods, we still must
-  # import it.  Including it here will make it available in all child
-  # 'describe' blocks.
-  include CorePluginFunctionalHelper
-
-  # When thinking up scenarios to test, start with the simplest.
-  # Then think of each major feature, and exercise them.
-  # Running combinations of features makes sense if it is very likely,
-  # or a difficult / dangerous case.  You can always add more tests
-  # here as users find subtle problems.  In fact, having a user submit
-  # a PR that creates a failing functional test is a great way to
-  # capture the reproduction case.
-  # The simplest case:
-  describe "when run without an argument" do
-
-    # run_inspec_process_with_this_plugin is a helper provided by
-    # CoreFunctionalHelper. It makes the InSpec that Bundler installed
-    # think that this plugin we are currently testing is installed as a
-    # user plugin, by writing a plugin config file in a temp dir.
-    # To use it, just provide a command line, minus the word `inspec`.
-    let(:outcome) { run_inspec_process_with_this_plugin("listresources core") }
-
-    # Some tests through here use minitest Expectations, which attach to all
-    # Objects, and begin with 'must' (positive) or 'wont' (negative)
-    # See http://docs.seattlerb.org/minitest/Minitest/Expectations.html
-    it("should exit successfully") { assert_exit_code 0, outcome }
-    it("should be silent on stderr") { outcome.stderr.must_be_empty }
-
-    # A selection of core resources, just spot checking.
-    # This is an example of using Ruby to define sets of tests.
-    ['process', 'service', 'user', 'file'].each do |resource_name|
-      it "should mention the '#{resource_name}' resource" do
-        outcome.stdout.must_include(resource_name)
-      end
-    end
-
-    # Check for the summary
-    it "should mention the summary" do
-      outcome.stdout.must_include('resources total')
-    end
-  end
-
-  # Test the search pattern feature, in a couple of ways.
-  describe "when run with a search pattern that matches things" do
-    # Notice that the command line is changed here:
-    # "list all resources that have the word user in them"
-    let(:outcome) { run_inspec_process_with_this_plugin("listresources core user") }
-
-    # Should be well-behaved...
-    it("should exit successfully") { assert_exit_code 0, outcome }
-    it("should be silent on stderr") { outcome.stderr.must_be_empty }
-
-    # Here, we want to know it DID match some things, and NOT some others.
-    ['user', 'users'].each do |resource_name|
-      it "should mention the '#{resource_name}' resource" do
-        outcome.stdout.must_include(resource_name)
-      end
-    end
-    ['process', 'service', 'file'].each do |resource_name|
-      it "should NOT mention the '#{resource_name}' resource" do
-        outcome.stdout.wont_include(resource_name)
-      end
-    end
-  end
-  describe "when run with a search pattern that matches nothing" do
-    # Unlikely we'll have a resource with the string 'autogyro' in it.
-    let(:outcome) { run_inspec_process_with_this_plugin("listresources core autogyro") }
-
-    # Should be well-behaved...
-    it("should exit successfully") { assert_exit_code 0, outcome }
-    it("should be silent on stderr") { outcome.stderr.must_be_empty }
-
-    # Output lines should be just two, for the summary.
-    it "should only have two output lines" do
-      outcome.stdout.split("\n").count.must_equal(2)
-    end
-
-    # Check for the summary
-    it "should mention a zero-resource summary" do
-      outcome.stdout.must_include('0 resources total')
-    end
-  end
-
-  # Exercise the summary option, which defaults to 'true'.
-  describe "when run with the no-summary flag" do
-    # Alter the command string to include the no-summary option
-    let(:outcome) { run_inspec_process_with_this_plugin('listresources core --no-summary') }
-
-    # Should be well-behaved...
-    it("should exit successfully") { assert_exit_code 0, outcome }
-    it("should be silent on stderr") { outcome.stderr.must_be_empty }
-
-    # Check for the summary
-    it "should NOT mention summary" do
-      outcome.stdout.wont_include('0 resources total')
-    end
-  end
-end

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/helper.rb

@@ -1,24 +0,0 @@
-# Test helper file for non-core plugins
-
-# This file's job is to collect any libraries needed for testing, as well as provide
-# any utilities to make testing a plugin easier.
-
-# InSpec core provides a number of such libraries and facilities, in the file
-# lib/plugins/shared/core_plugin_test_helper.rb . So, one job in this file is
-# to locate and load that file.
-require 'inspec/../plugins/shared/core_plugin_test_helper'
-
-# Also load the InSpec plugin system. We need this so we can unit-test the plugin
-# classes, which will rely on the plugin system.
-require 'inspec/plugin/v2'
-
-# Caution: loading all of InSpec (i.e. require 'inspec') may cause interference with
-# minitest/spec; one symptom would be appearing to have no tests.
-# See https://github.com/inspec/inspec/issues/3380
-
-# You can select from a number of test harnesses.  Since InSpec uses Spec-style controls
-# in profile code, you will probably want to use something like minitest/spec, which provides
-# Spec-style tests.
-require 'minitest/autorun' # loads all styles and runs tests automatically
-
-# You might want to put some debugging tools here.  We run tests to find bugs, after all.

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/unit/README.md

@@ -1,17 +0,0 @@
-# Unit Testing Area for Plugins
-
-## What Tests are Provided?
-
- * plugin_def_test.rb - Would be useful in any plugin.  Verifies that the plugin is properly detected and registered.
- <% if hooks.key?(:cli_command) %>
- * cli_args_test.rb - Tests the CLI options for a CLI Command plugin
- <% end %>
-
-## What are Unit Tests?
-
-Unit tests are tests that verify that the individual components of your plugin work as intended.  To be picked up by the Rake tasks as tests, each test file should end in `_test.rb`.
-
-## Unit vs Functional Tests
-
-A practical difference between unit tests and functional tests is that unit tests all run within one process, while functional tests might exercise a CLI plugin by shelling out to an inspec command in a subprocess, and examining the results.
-

data/lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/unit/cli_args_test.rb

@@ -1,67 +0,0 @@
-# This unit test performs some tests to verify that the command line options for
-# <%= plugin_name %> are correct.
-
-# Include our test harness
-require_relative '../helper'
-
-# Load the class under test, the CliCommand definition.
-require '<%= plugin_name %>/cli_command'
-
-# Because InSpec is a Spec-style test suite, we're going to use Minitest::Spec
-# here, for familiar look and feel. However, this isn't InSpec (or RSpec) code.
-describe InspecPlugins::<%= module_name %>::CliCommand do
-
-  # When writing tests, you can use `let` to create variables that you
-  # can reference easily.
-
-  # This is the CLI Command implementation class.
-  # It is a subclass of Thor, which is a CLI framework.
-  # This unit test file is mostly about verifying the Thor settings.
-  let(:cli_class) { InspecPlugins::<%= module_name %>::CliCommand }
-
-  # From this point onwards, this test file assumes you did not rename
-  # the provided 'do_something' subcommand.  As you implement your plugin,
-  # modify and add to the lines below to test your actual options.
-
-  # This is a Hash of Structs that tells us details of options for the 'do_something' subcommand.
-  let(:do_something_options) { cli_class.all_commands['do_something'].options }
-
-  # To group tests together, you can nest 'describe' in minitest/spec
-  describe 'the do-something subcommand' do
-
-    # Some tests through here use minitest Expectations, which attach to all
-    # Objects, and begin with 'must' (positive) or 'wont' (negative)
-    # See http://docs.seattlerb.org/minitest/Minitest/Expectations.html
-
-    # Option count OK?
-    it "should take one option" do
-      do_something_options.count.must_equal(1)
-    end
-
-    # Summary option
-    describe "the summary option" do
-      it "should be present" do
-        do_something_options.keys.must_include(:summary)
-      end
-      it "should have a description" do
-        do_something_options[:summary].description.wont_be_nil
-      end
-      it "should not be required" do
-        do_something_options[:summary].required.wont_equal(true)
-      end
-      it "should have a single-letter alias" do
-        do_something_options[:summary].aliases.must_include(:s)
-      end
-    end
-
-    # Argument count
-    # The 'do-something' command takes one optional argument. According to the
-    # metaprogramming rules of Ruby, the do_something() method should thus have an
-    # arity of -1. See http://ruby-doc.org/core-2.5.1/Method.html#method-i-arity
-    # for how that number is caclulated.
-    it "should take one optional argument" do
-      cli_class.instance_method(:do_something).arity.must_equal(-1)
-    end
-
-  end
-end