TypeError: no implicit conversion from nil to integer #23
Comments
|
Also, I copy/pasta'd the require 'minitest/spec'
describe_recipe 'spec_examples::default' do
# It's often convenient to load these includes in a separate helper along with
# your own helper methods, but here we just include them directly:
include MiniTest::Chef::Assertions
include MiniTest::Chef::Context
include MiniTest::Chef::Resources
describe "files" do
# = Testing that a file exists =
#
# The simplest assertion is that a file exists following the Chef run:
it "creates the config file" do
file("/etc/fstab").must_exist
end
# All of the matchers starting with 'must_' also have a negative 'wont_'.
# So conversely we can also check that a file does not exist:
it "ensures that the foobar file is removed if present" do
file("/etc/foobar").wont_exist
end
it "has the expected ownership and permissions" do
file("/etc/fstab").must_exist.with(:owner, "root")
end
end
end |
|
Additional testing with Ubuntu 12.04 as well; same error. I believe the problem may lie somewhere around like 24 of lib/minitest-chef-handler/resources.rb as that is where 'with' is defined. |
|
Hi @leifmadsen, thanks for reporting this problem. At first glance, it seems your file resource doesn't have an owner, which can be a Chef bug, I haven't used the version 0.10.12 yet because I found the version 0.10.10 super buggie. You can confirm this printing the owner in the spec with something like this: p file('/etc/fstab').ownerEither way, I'm not sure if our code to extract the name of the owner is the most correct either. As you can see in the method below, we assume Chef stores the owner as a UID (Integer), but if the implementation changes and they decide to store the name (String) the method will fail because I'm going to modify that method to verify how the owner is stored first. If you could confirm that your resource has actually an owner I would really appreciate it. |
|
is that |
|
nah, I mean to put that in your spec. Something like: it "has the expected ownership and permissions" do
p file('/etc/fstab').owner
file("/etc/fstab").must_exist.with(:owner, "root")
endSo we are sure the resource has an owner. |
|
Internally the |
|
I think you're right: p("-------------------------------")
p file('/etc/fstab').owner
p("0000000000000000000000000000000") |
|
Additionally, I noticed the .mode method fails as well, as it returns "" instead of "644" like I would expect. However, the test doesn't seem to actually fail: |
|
Yeah, we can do better and detect those cases in the On Sunday, June 24, 2012 at 2:47 PM, Leif Madsen wrote:
|
|
I wish the .owner and .mode methods actually returned data :) Sounds like I need to go up a level to get this filed and potentially fixed I guess. The fact it is returning 'nil' is especially strange (on ruby 1.8.7 with CentOS 6.2 and 1.9.1 with Ubuntu 12.04). I might go back to an earlier version of chef-client and just see what it returns if anything. Any recommendations for a version I should test out? |
|
I use Chef 0.10.8 because the Link resource in Chef 0.10.10 was completely broken. I think it's fixed in 0.10.12 but I haven't had time to test this version. On Sunday, June 24, 2012 at 2:59 PM, Leif Madsen wrote:
|
|
Wow interesting. If I go back to Chef 0.10.8, things work (and pass). If I use either 0.10.10 or 0.10.12, the tests fail as reported here (so I suspect the changes in 0.10.12 do not address the issues you would expect). btw: thank you for the quick responses |
|
Just for reference, the values returned: |
|
Do you happen to know of the CHEF issue on the tracker I should follow up on? I did a search and can't find anything related. Don't want to file a duplicate. Thanks! |
|
It looks like This behaviour changed in 0.10.10 when changes were made to genericise permissions for windows support. |
|
@acrmp Thanks for finding that commit! I'm going to open a CHEF ticket with the commit as a link. Thanks! |
|
Filed as issue http://tickets.opscode.com/browse/CHEF-3235 |
|
I'm curious if there are new, preferred methods to be using, or a different way that minitest-chef-handler should be utilizing the lookups for a file method. Unfortunately it's hard for me to determine if the way minitest-chef-handler is accessing the methods is deprecated, or if the way the methods were changed in Chef are incorrect. |
|
@leifmadsen the Chef api is not really consistent. I've released the version 0.5.2 that guards the tests from this failure and shows instead something like this: Thanks for reporting this! |
|
Cool thanks! Hopefully in the future this will work correctly on something greater than Chef 0.10.8 as it looks like I'll be stuck on that for now. Thanks for the quick responses and fix! |
|
@calavera I'm using Chef 11.6 with minitest-chef-handler, and still see this issue. That is, the error is now caught correctly (showing the error you provided above), but why is it showing this error? When I ssh into the box, I can see the proper user rights, but minitest-chef-handler still tells me it gets |
|
I am also seeing this error on Chef 11.8. |
When running with Chef 0.10.12, and minitest-handler version 0.0.10, with a very simple test via a private chef server, I get this on a CentOS 6.2 server:
The run_list looks like:
And the autotesting cookbook was crated with 'knife cookbook create autotesting', followed by a 'mkdir -p site-cookbooks/autotesting/files/default/tests/minitest/'
I then added a new 'system_test.rb' file to the minitest directory with the following contents:
However the test will pass if I strip off the
.with(:owner, "root")from the file resource.The text was updated successfully, but these errors were encountered: