[chef] Re: Re: Re: Accessing Test Kitchen YML Attributes

[Rudi < >]

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 < " target="_blank"> > 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 < "> > wrote:
>
> On Mar 5, 2015, at 7:27 PM, Rudi < "> > 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 method `node' 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
>