test-kitchen 1.23.3 → 1.23.4

data/docs/content/docs/provisioners/shell.md

@@ -1,31 +0,0 @@
----
-title: Shell
-slug: shell
-menu:
-  docs:
-    parent: provisioners
-    weight: 5
----
-
-The Shell Provisioner can be used instead of managing with one of the supported configuration tools.
-
-If the only value provided to the `provisioner:` configuration is `name: shell`, then Test-Kitchen looks for a file named `bootstrap.sh` or `bootstrap.ps1` in the root of the project.
-
-### Provisioner Default Usage
-~~~
----
-provisioner:
-  name: shell
-~~~
-
-### Provisioner Options
-~~~
----
-provisioner:
-  name: shell
-  script:    'test/scripts/setup.sh' # Optional - default: bootstrap.sh/bootstrap.ps1
-  arguments: ['--debug']             # Optional - Add extra arguments to the converge script.
-  root_path: '/home/vagrant/'        # Optional - default: kitchen_root ('/tmp')
-  command:   'hostname'              # Optioanl - Run a single command instead of managing and running a script.
-~~~
-

data/docs/content/docs/reference/_index.md

@@ -1,5 +0,0 @@
----
-title: "Reference"
-layout: redirect
-redirect_url: /docs/reference/dynamic-configuration
----

data/docs/content/docs/reference/configuration.md

@@ -1,53 +0,0 @@
----
-title: Configuration
-menu:
-  docs:
-    parent: reference
-    weight: 5
----
-
-There are a few basic ways of dynamically configuring Kitchen:
-
-* A local configuration will be looked for in `.kitchen.local.yml` which could be used for development purposes.  This is a file that is not typically checked into version control.
-* A global configuration file will also be looked for in `$HOME/.kitchen/config.yml` to set preferred defaults for all your projects.
-* Each YAML file can contain ERB fragments, which you could use for selecting drivers, etc. based on which platform you're currently running, or based off environment variables.
-* Finally, Kitchen also has several environment variables where you can set a path to a `.kitchen.yml` or `$HOME/.kitchen/config.yml` file. This can be useful if you wish to use Kitchen with a continuous integration (CI) system.
-
-To specify a path to a global `config.yml`, project or local `.kitchen.yml` file, set the following environment variables:
-
-~~~
-export KITCHEN_GLOBAL_YAML=/path/to/your/global/config.yml
-export KITCHEN_YAML=/path/to/your/project/.kitchen.yml
-export KITCHEN_LOCAL_YAML=/path/to/your/local/.kitchen.local.yml
-~~~
-
-**Note:** If `$HOME/.kitchen/config.yml` is present, kitchen will merge this file with your project's `.kitchen.yml`, and/or `.kitchen.local.yml` file. Merge precedence is:
-
-1. `.kitchen.local.yml`
-2. `.kitchen.yml`
-3. `$HOME/.kitchen/config.yml`
-
-For example, one could modify `.kitchen.yml` (or `.kitchen.local.yml`, or `$HOME/.kitchen/config.yml`) to look like:
-
-~~~
----
-driver:
-  name: openstack
-  openstack_username: <%= ENV['YOUR_OPENSTACK_USERNAME'] %>
-  openstack_api_key: <%= ENV['YOUR_OPENSTACK_API_KEY'] %>
-  openstack_auth_url: <%= ENV['YOUR_OPENSTACK_AUTH_URL'] %>
-  image_ref: <%= ENV['SERVER_IMAGE_ID'] %>
-  flavor_ref: <%= ENV['SERVER_FLAVOR_ID'] %>
-~~~
-
-Keep in mind, this assumes you have an OpenStack deployment setup and ready to use. This is only an example so to illustrate using environment variables via ERB snippets in the configuration file.
-
-Another handy use of the ERB fragments is to dynamically override the log_level of
-the provisioner.  Since Kitchen 1.7.0 the log level for the provisioner is now independent of the Kitchen log level.  Using the following snippet, allows the environment to override the provisioner log level without modifying the config file.:
-
-~~~
----
-provisioner:
-  name: chef_zero
-  log_level: <%= ENV['CHEF_LOG_LEVEL'] || "auto" %>
-~~~

data/docs/content/docs/reference/examples.md

@@ -1,97 +0,0 @@
----
-title: "Examples"
-menu:
-  docs:
-    parent: reference
-    weight: 10
----
-
-We've collected a variety of examples to highlight all the different things one can do with kitchen.
-
-#### kitchen-vagrant
-
-The default driver with a default provider of VirtualBox. Here is a fully annotated example of the `.kitchen.yml` generated by `chef generate`
-
-~~~
----
-# Configure the driver (cloud/hypervisor)
-driver:
-  name: vagrant #ec2, dokken, libvirt
-  # provider: virtualbox
-
-# Configure the provisioner (config management)
-provisioner:
-  name: chef_zero #chef_zero, chef_solo, puppet_apply, ansible_playbook, shell
-
-# Configure the verifier (testing framework)
-verifier:
-  name: inspec
-
-# Enumerate platforms
-# A platform represents a single configuration of an operating system
-# While this is often 1:1, the names allow this to be customizable
-# At least 1 platform is **required**
-platforms:
-  # Drivers may support defaults that automatically
-  # map certain names to an image for the given driver
-  - name: ubuntu-16.04
-  - name: centos-7
-
-# Enumerate suites
-# At least 1 suite is **required**
-suites:
-  # The name of each suite maps to a configuration / set of tests
-  # Depending on the verifier, default locations may be inferred based on
-  # directory naming
-  - name: default
-    run_list:
-      - recipe[git_cookbook::default]
-    verifier:
-      inspec_tests:
-        - test/integration/default
-    attributes:
-~~~
-
-Sometimes you'd like to add another NIC to your vm, or bump up the memory. You might have a `forwarded_port` you'd like
-to add also. The following snippet has a couple suggestions how. You can even turn on the `auto_correct` if you think
-you'll need it.
-
-~~~
-  name: vagrant
-  network:
-    - ["forwarded_port", {guest: 80, host: 8080, auto_correct: true}]
-    - ["forwarded_port", {guest: 443, host: 8443}]
-    - ["private_network", {ip: "10.0.0.1"}]
-  customize:
-    cpus: 2
-    memory: 4096
-~~~
-
-The driver tries to closely mirror the upstream, as illustrated by [forwarded_port](https://docs.vagrantup.com/v2/networking/forwarded_ports.html) and [private_network](https://docs.vagrantup.com/v2/networking/private_network.html).
-
-If you would like more information the [kitchen-vagrant](https://github.com/test-kitchen/kitchen-vagrant) github page has more.
-
-[hangops-jobbot/.kitchen.yml](https://github.com/rrxtns/hangops-jobbot/blob/master/cookbooks/hangops-jobbot/.kitchen.yml)
-
-~~~
----
-driver:
-  name: vagrant
-  network:
-    - ["forwarded_port", {guest: 8080, host: 8081}]
-
-provisioner:
-  name: chef_solo
-  data_bags_path: './test/integration/data_bags/'
-  solo_rb:
-    environment: test
-
-platforms:
-  - name: ubuntu-16.04
-
-suites:
-  - name: default
-    run_list:
-      - recipe[hangops-jobbot::default]
-    attributes:
-~~~

data/docs/content/docs/reference/faq.md

@@ -1,58 +0,0 @@
----
-title: "FAQ"
-menu:
-  docs:
-    parent: reference
-    weight: 15
----
-
-### FAQ
-
-These are frequently asked questions or tips that don't have a better home just yet.
-
-
-##### How do I add another driver other than Vagrant?
-
-If you're using ChefDK, check for it`chef gem list | grep $DRIVER` you need to make sure the driver [exists](https://github.com/test-kitchen/test-kitchen/blob/master/ECOSYSTEM.md),
-if it does:
-
-~~~
-~$ gem install kitchen-openstack # for instance
-~$ vi cookbooks/demo/.kitchen.yml # wherever your .kitchen.yml is for your cookbook
-~~~
-
-Examples:
-
-- [kitchen-openstack](https://github.com/test-kitchen/kitchen-openstack#minimum-configuration)
-- [kitchen-digitalocean](https://github.com/test-kitchen/kitchen-digitalocean#installation-and-setup)
-
-Edit the `.kitchen.yml` as appropriate and run `kitchen list` to verify that everything
-is working as expected. There is a strong chance that the flavors, or
-image names are different per driver, so when migrating between drivers be prepared
-to change these at the very least.
-
-Certain drivers, like `kitchen-dokken` [recommend](https://github.com/someara/kitchen-dokken#usage) setting `KITCHEN_LOCAL_YAML` environment variable to ensure these configs are used when there are multiple in a directory.
-
-##### How do I update just test-kitchen if I'm using ChefDK?
-
-Due to the nature of how the ChefDK is built, it is not possible to update a gem that is part of the package. To get the latest versions of component software, builds from the [current](https://downloads.chef.io/chefdk/current) channel can be consumed.
-
-##### How do I change the user to access the instance?
-
-Add/edit the `transport` section in `.kitchen.yml`, for instance:
-
-~~~
-transport:
-  username: ubuntu
-~~~
-
-##### I need to set up a cache or proxy using Vagrant, what are some options for me?
-
-So there are a few things that already exist that sort of cover this in the kitchen world:
-
-- the host ENV vars for proxies are automatically passed to instances
-- Example of using [polipo](https://gist.github.com/fnichol/7551540) locally
-- [vagrant-cachier](https://github.com/fgrehm/vagrant-cachier)
-
-For the system level proxies and the polipo/squid locally you don't need to do much but you'll still need to edit the conf files for yum/apt as appropriate. If vagrant-cachier it will be used by `kitchen-vagrant` as default. This behaviour is documented [here](https://github.com/test-kitchen/kitchen-vagrant#-cachier).
-

data/docs/content/docs/reference/fixtures.md

@@ -1,32 +0,0 @@
----
-title: Fixture Cookbooks  
-menu:
-  docs:
-    parent: reference
-    weight: 20
----
-
-Cookbooks, especially ones that provide resources exclusively, often utilize what are known as "fixture cookbooks". These are cookbooks and recipes included expressly for the purpose of testing. 
-
-Fixture cookbooks are most often made available via a Berksfile:
-
-```
-source 'https://supermarket.chef.io'
-
-metadata
-
-group :integration do
-  cookbook 'test_cookbook', path: './test/cookbooks/test_cookbook'
-end
-```
-
-This will make the cookbook available and it can be called via `run_list`:
-
-```
-suites:
-- name: default
-  run_list:
-    - recipe[test_cookbook::default]
-```
-
-Working examples can be found in many of the chef-cookbooks, like the [openldap cookbok](https://github.com/chef-cookbooks/openldap/tree/master/test/cookbooks/openldap-test)

data/docs/content/docs/reference/glossary.md

@@ -1,34 +0,0 @@
----
-title: Glossary
-menu:
-  docs:
-    parent: reference
-    weight: 25
----
-
-Berksfile 
-: the file `berks` loads to determine sources and dependencies
-
-Berkshelf
-: a tool to resolve cookbook dependencies
-
-hypervisor
-: a piece of software that allows one to create and run virtual machines
-
-regular expression
-: a "a sequence of characters that define a search pattern", in the context of kitchen we allow a user to specify instances with regular expressions like `^default-ubuntu`
-
-Vagrant
-: a piece of software that makes abstracts away hypervisor details to provide a consistent experience and interface to virtual machines
-
-virtual machine
-: a machine that is virtualized, i.e. running on a hypervisor
-
-VirtualBox
-: a freely available hypervisor from Oracle
-
-VMware Fusion
-: a for-pay hypervisor from VMware exclusively for macOS/OS X
-
-VMware Workstation
-: a for-pay hypervisor from VMware for Linux and Windows

data/docs/content/docs/reference/lifecycle-hooks.md

@@ -1,68 +0,0 @@
----
-title: Lifecycle Hooks
-menu:
-  docs:
-    parent: reference
-    weight: 30
----
-
-The life cycle hooks system allows running commands before or after any phase
-of Test Kitchen (`create`, `converge`, `verify`, or `destroy`). Commands can be
-run either locally on your workstation (the default) or remotely on the test instance.
-
-These hooks are configured under a new `lifecycle:` section in `kitchen.yml`:
-
-```
-lifecycle:
-  pre_create: echo before
-  post_create:
-  - echo after
-  - local: echo also after
-  - remote: echo after but in the instance
-```
-
-You can also configure hooks on a single platform or suite:
-
-```
-platforms:
-- name: ubuntu-18.04
-  lifecycle:
-    pre_converge:
-    - remote: apt update
-
-suites:
-- name: default
-  lifecycle:
-    post_verify:
-    - my_coverage_formatter
-```
-
-Local commands automatically get some environment variables with information
-about which instance the hook is evaluating against:
-
-* `KITCHEN_INSTANCE_NAME` - The full name of the instance
-* `KITCHEN_SUITE_NAME` - The name of the suite of the instance
-* `KITCHEN_PLATFORM_NAME` - The name of the platform of the instance
-* `KITCHEN_INSTANCE_HOSTNAME` - The hostname of the instance as reported by the driver plugin
-
-You can also pass additional configuration for local commands:
-
-```
-lifecycle:
-  pre_converge:
-  - local: ./setup.sh
-    environment:
-      API_KEY: asdf1234
-    timeout: 60
-```
-
-Remote commands are normally not allowed during `pre_create` or `post_destroy`
-hooks as there is generally no instance running at that point, but with `pre_destroy`
-hooks you may want to use the `skippable` flag so as to not fail during `kitchen test`:
-
-```
-lifecycle:
-  pre_destroy:
-  - remote: myapp --unregister-license
-    skippable: true
-```

data/docs/content/docs/reference/reboots.md

@@ -1,24 +0,0 @@
----
-title: Reboots
-menu:
-  docs:
-    parent: reference
-    weight: 35
----
-
-Test-kitchen has support for enduring reboots initiated by a Chef provisioner. 
-
-```
-provisioner:
-  name: chef_zero
-  max_retries: 3 # tweak in conjunction with wait_for_retry
-  wait_for_retry: 90 # tweak based on machine shutdown speed
-  retry_on_exit_code: [35, 213] # retry for array of exit codes
-  client_rb:
-    exit_status: :enabled # default in 13+, only required for 12.x
-    client_fork: false # don't fork so we get true exit code, not needed for Windows
-```
-
-`wait_for_retry` is necessary so that Test-kitchen doesn't try to reconnect before the system reboots (or at least before the transport stops taking connections).  This is the most likely option to need tweaking and varies between drivers as well as the specifications of the instances.
-
-`retry_on_exit_code` does not typically need to be set. The default value is `[35, 213]` - `35` from chef-client indicates a reboot has been scheduled during the run, while `213` indicates an exit due to a chef-client upgrade.

data/docs/content/docs/verifiers/_index.md

@@ -1,14 +0,0 @@
----
-title: Verifiers
-menu:
-  docs:
-    parent: verifiers
-    weight: 1
----
-
-A Test-Kitchen *verifier* tests the configuration applied by the *provisioner*. This is most commonly a InSpec or ServerSpec, both of which are included in the ChefDK/Workstation.
-
-Other verifiers:
-
-* shell (built-in)
-* [busser-bats](https://github.com/test-kitchen/busser-bats/)

data/docs/content/docs/verifiers/inspec.md

@@ -1,44 +0,0 @@
----
-title: InSpec
-slug: inspec
-menu:
-  docs:
-    parent: verifiers
-    weight: 5
----
-
-[InSpec](https://www.inspec.io/) framework for testing and auditing your applications and infrastructure. It can be utilized for validating test-kitchen instance via the[kitchen-inspec plugin](https://github.com/inspec/kitchen-inspec).
-
-To enable kitchen-inspec in your `.kitchen.yml`:
-
-```
-verifier:
-  name: inspec
-```
-
-Example test to check that the httpd package is installed:
-
-```
-describe package('httpd') do
-  it { should be_installed }
-end
-```
-
-The plugin requires no configuration by default and expects tests exist as per:
-
-```
-.
-├── Berksfile
-├── Gemfile
-├── README.md
-├── metadata.rb
-├── recipes
-│   ├── default.rb
-│   └── nginx.rb
-└── test
-    └── integration
-        └── default
-            └── web_spec.rb
-```
-
-More configuration options can be found in the project's [README](https://github.com/inspec/kitchen-inspec/blob/master/README.md)