Accessing Test Kitchen YML Attributes


#1

Hi,

I have a simple test kitchen error I’m stuck on, would appreciate some
guidance here.

Working though the tutorial at KitchenCI, I’m having trouble accessing
attributes set inside .kitchen.yml.

The respective code is from:
http://kitchen.ci/docs/getting-started/writing-server-test

If I add a port attribute under suites

suites:

  • name: default
    run_list:
    • recipe[git::default]
      attributes:
  • name: server
    run_list:
    • recipe[git::server]
      attributes:
      port: 9217

Then try to access it like so in:
test/integration/server/serverspec/git_daemon_spec.rb

require ‘serverspec’

Required by serverspec

set :backend, :exec

puts node[‘port’]

describe “Git Daemon” do

/tmp/busser/suites/serverspec/git_daemon_spec.rb:6:in <top (required)>': undefined local variable or methodnode’ for main:Object (NameError)

Can you see where I’m going wrong here?

Thanks.


#2

You can’t refer to the node local accessor outside of the
serverspec/rspec contexts; due to the way it is implemented.

Move puts node[‘port’] approximately 3~4 lines down to within the
describe block, preferably within a before do…end block, or similar.
In general, avoid writing a string to the standard output buffer of
your terminal: many side effects are involved - eventually you will
come to value this less as a diagnostic tool.

cheers,

–aj

On Fri, Mar 6, 2015 at 4:27 PM, Rudi ooly.me@gmail.com wrote:

Hi,

I have a simple test kitchen error I’m stuck on, would appreciate some
guidance here.

Working though the tutorial at KitchenCI, I’m having trouble accessing
attributes set inside .kitchen.yml.

The respective code is from:
http://kitchen.ci/docs/getting-started/writing-server-test

If I add a port attribute under suites

suites:

  • name: default
    run_list:
    • recipe[git::default]
      attributes:
  • name: server
    run_list:
    • recipe[git::server]
      attributes:
      port: 9217

Then try to access it like so in:
test/integration/server/serverspec/git_daemon_spec.rb

require ‘serverspec’

Required by serverspec

set :backend, :exec

puts node[‘port’]

describe “Git Daemon” do

/tmp/busser/suites/serverspec/git_daemon_spec.rb:6:in <top (required)>': undefined local variable or methodnode’ for main:Object (NameError)

Can you see where I’m going wrong here?

Thanks.


#3

On Mar 5, 2015, at 7:27 PM, Rudi ooly.me@gmail.com wrote:

Hi,

I have a simple test kitchen error I’m stuck on, would appreciate some guidance here.

Working though the tutorial at KitchenCI, I’m having trouble accessing attributes set inside .kitchen.yml.

The respective code is from: http://kitchen.ci/docs/getting-started/writing-server-test

If I add a port attribute under suites

suites:

  • name: default
    run_list:
    • recipe[git::default]
      attributes:
  • name: server
    run_list:
    • recipe[git::server]
      attributes:
      port: 9217

Then try to access it like so in: test/integration/server/serverspec/git_daemon_spec.rb

require ‘serverspec’

Required by serverspec

set :backend, :exec

puts node[‘port’]

describe “Git Daemon” do

/tmp/busser/suites/serverspec/git_daemon_spec.rb:6:in <top (required)>': undefined local variable or methodnode’ for main:Object (NameError)

Can you see where I’m going wrong here?

Node attributes are only available (directly) from your Chef recipe code. Serverspec runs independent of Chef so node data isn’t a thing there. There are circuitous ways to expose things but I would avoid them. Assuming the reason you want to get the port in your serverspec to check that it is listening on that port, it is Correct™ to hard-code the port a second time. Test code tends to violate some DRY principles because it is designed to favor safety over maintenance (you run tests more then you edit old ones).

–Noah


#4

Oh, my mistake. I thought/misread this (w)as chefspec, not serverspec.
Indeed. Noah’s answer holds true.

cheers,

–aj

On Fri, Mar 6, 2015 at 4:57 PM, Noah Kantrowitz noah@coderanger.net wrote:

On Mar 5, 2015, at 7:27 PM, Rudi ooly.me@gmail.com wrote:

Hi,

I have a simple test kitchen error I’m stuck on, would appreciate some guidance here.

Working though the tutorial at KitchenCI, I’m having trouble accessing attributes set inside .kitchen.yml.

The respective code is from: http://kitchen.ci/docs/getting-started/writing-server-test

If I add a port attribute under suites

suites:

  • name: default
    run_list:
    • recipe[git::default]
      attributes:
  • name: server
    run_list:
    • recipe[git::server]
      attributes:
      port: 9217

Then try to access it like so in: test/integration/server/serverspec/git_daemon_spec.rb

require ‘serverspec’

Required by serverspec

set :backend, :exec

puts node[‘port’]

describe “Git Daemon” do

/tmp/busser/suites/serverspec/git_daemon_spec.rb:6:in <top (required)>': undefined local variable or methodnode’ for main:Object (NameError)

Can you see where I’m going wrong here?

Node attributes are only available (directly) from your Chef recipe code. Serverspec runs independent of Chef so node data isn’t a thing there. There are circuitous ways to expose things but I would avoid them. Assuming the reason you want to get the port in your serverspec to check that it is listening on that port, it is Correct™ to hard-code the port a second time. Test code tends to violate some DRY principles because it is designed to favor safety over maintenance (you run tests more then you edit old ones).

–Noah


#5

Hi,

Ah OK … that makes sense then, I was really getting frustrated.

What kind of use case is attributes used for then?

From here: https://docs.chef.io/kitchen.html

suites:

  • name: suite_name
    run_list:
    • recipe[cookbook_name::recipe_name]
      attributes: { foo: “bar”}
      excludes:
    • platform-version

Where would you actually use the ‘foo’ property?

My assumption was inside the test suites.

Thanks.

On Fri, Mar 6, 2015 at 12:10 PM, AJ Christensen <aj@junglistheavy.industries

wrote:

Oh, my mistake. I thought/misread this (w)as chefspec, not serverspec.
Indeed. Noah’s answer holds true.

cheers,

–aj

On Fri, Mar 6, 2015 at 4:57 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On Mar 5, 2015, at 7:27 PM, Rudi ooly.me@gmail.com wrote:

Hi,

I have a simple test kitchen error I’m stuck on, would appreciate some
guidance here.

Working though the tutorial at KitchenCI, I’m having trouble accessing
attributes set inside .kitchen.yml.

The respective code is from:
http://kitchen.ci/docs/getting-started/writing-server-test

If I add a port attribute under suites

suites:

  • name: default
    run_list:
    • recipe[git::default]
      attributes:
  • name: server
    run_list:
    • recipe[git::server]
      attributes:
      port: 9217

Then try to access it like so in:
test/integration/server/serverspec/git_daemon_spec.rb

require ‘serverspec’

Required by serverspec

set :backend, :exec

puts node[‘port’]

describe “Git Daemon” do

/tmp/busser/suites/serverspec/git_daemon_spec.rb:6:in <top (required)>': undefined local variable or methodnode’ for main:Object
(NameError)

Can you see where I’m going wrong here?

Node attributes are only available (directly) from your Chef recipe
code. Serverspec runs independent of Chef so node data isn’t a thing there.
There are circuitous ways to expose things but I would avoid them. Assuming
the reason you want to get the port in your serverspec to check that it is
listening on that port, it is Correct™ to hard-code the port a second time.
Test code tends to violate some DRY principles because it is designed to
favor safety over maintenance (you run tests more then you edit old ones).

–Noah


#6

On Mar 5, 2015, at 8:15 PM, Rudi ooly.me@gmail.com wrote:

Hi,

Ah OK … that makes sense then, I was really getting frustrated.

What kind of use case is attributes used for then?

From here: https://docs.chef.io/kitchen.html

suites:

  • name: suite_name

run_list:

  • recipe[cookbook_name::recipe_name]

attributes: { foo: “bar”}

excludes:

  • platform-version

Where would you actually use the ‘foo’ property?
My assumption was inside the test suites.

For when a recipe can be configured via Chef attributes and you want to test how it behaves with non-default values. It is just slightly faster than making a test-only wrapper cookbook and setting them that way even if thats how you would do it in production.

–Noah


#7

Hi,

OK got it.

Thank you kindly.

On Fri, Mar 6, 2015 at 12:35 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On Mar 5, 2015, at 8:15 PM, Rudi ooly.me@gmail.com wrote:

Hi,

Ah OK … that makes sense then, I was really getting frustrated.

What kind of use case is attributes used for then?

From here: https://docs.chef.io/kitchen.html

suites:

  • name: suite_name

run_list:

  • recipe[cookbook_name::recipe_name]

attributes: { foo: “bar”}

excludes:

  • platform-version

Where would you actually use the ‘foo’ property?
My assumption was inside the test suites.

For when a recipe can be configured via Chef attributes and you want to
test how it behaves with non-default values. It is just slightly faster
than making a test-only wrapper cookbook and setting them that way even if
thats how you would do it in production.

–Noah