Update your Style in Test Kitchen

It is surprising how many resources on the Internet are carrying on outdated or deprecated information - the Chef ecosystem is no exception to this. While outdated style in Ruby files has been detected via cookstyle for a while, Test Kitchen files still have no sanity checks yet.

Let’s see what changed in this short post.

Note: As of version 2.5.2, while kitchen doctor does exist only the chef_base.rb file has an actual implementation for the related doctor method. Some of the items below might become common knowledge when this situation changes.

Naming of your Kitchen Files

If you still use files like .kitchen.yml in your projects, you should mark this for refactoring. Test Kitchen made the non-hidden alternative name kitchen.yml and kitchen.local.yml the default some time ago.

Outdated since version 1.21.0 (February 2018)

Legacy Driver Format

This one is present in many well-known examples for Test Kitchen and almost always somewhere in a project. Considering its age, it is surprising that is has survived: Sections like driver_config: or driver_plugin: were renamed to plain driver:. These keys are commonly found under your platforms or suites.

Old Style:

platforms:
  - name: ubuntu18
    driver_config:
      template: ubuntu18-vm

New Style:

platforms:
  - name: ubuntu18
    driver:
      template: ubuntu18-vm

Outdated since version 1.0.0.rc.1 (November 2013)

Legacy Chef Paths

When Test Kitchen was still a tool geared towards Chef, many settings were deeply integrated. As more and more provisioners were added, compatibility was preserved. Still, they are marked as deprecated under suites:

  • data_path
  • data_bags_path
  • encrypted_data_bag_secret_key_path
  • environment_path
  • nodes_path
  • roles_path

As those parameters are Chef-specific, you should put them in a provisioner: subsection instead like this:

Old Style:

suites:
  - name: default
    data_bags_path: test/integration

New Style:

suites:
  - name: default
    provisioner:
      data_bags_path: test/integration

Outdated since version 1.0.0.rc.1 (November 2013)

Pass Chef Data to Provisioner

While not being deprecated yet (probably due to wide-spread use), this fits into the same category as “Legacy Chef Paths”. The same reasoning is applied to:

  • run_list
  • named_run_list
  • attributes

Old Style:

suites:
  - name: default
    run_list:
      - recipe[empty]
    attributes:
      java:
        install_flavor: "oracle"

New Style:

suites:
  - name: default
    provisioner:
      run_list:
        - recipe[empty]
      attributes:
        java:
          install_flavor: "oracle"

Recommended since version 1.0.0.rc.1 (November 2013)

Similar Posts You Might Enjoy

Update your Style in Test Kitchen (Part 2)

It is time for a follow-up to my blog post from last year - especially as Test Kitchen 3.0 changed some defaults. Let’s check some cargo-culted settings out in this blog post. - by Thomas Heinen

Airgapped Testing - VMware Edition

Recently, I got a bug report for the kitchen-vcenter driver, which allows lifecycle management of testing VMs on VMware vCenter environments. Apparently, a customer tried to create a VM without any network interface. The problem was that this crashed in a very unintuitive way. But it made me wonder: Would it be possible to use non-networked machines for tests? It turns out: That’s absolutely possible! - by Thomas Heinen

Third Party Platform Support for Chef

Currently, users of Chef are limited to working with the platforms supported by the Chef core. But with the advancements of Target Mode, the story could change quickly. Learn about the idea of a “Platform Support Pack” and what it could mean for the future. - by Thomas Heinen