Hi Dan,
I agree - the chefspec documentation does make it difficult to get
started with.
Chefspec expects you to write examples for your recipes that define
what the resources are that you expect to be created by a converge.
You would then run these examples using RSpec. There is an example of
this here:
http://acrmp.github.com/chefspec/#Writing_a_cookbook_example
When you call #converge on the ChefRunner in your tests Chef is
actually run, but in effect with the actions that are normally
performed by the resource providers disabled. Ohai plugins are also
not loaded. The net result is that you can write tests that exercise
your recipes much quicker, without doing a real converge. This kind of
testing has very real limitations but can be useful.
You certainly could use chefspec outside of its intended use by
running through your cookbooks without making assertions. It's not
clear to me how useful this would be, but I'd be interested in
learning what issues you were able to identify that were not picked up
earlier in your pipeline. It may be in the future that Chef's
forthcoming why-run mode might help you here too.
I would highly recommend exploring further the reasons that prevent
you from doing integration testing, and if possible taking this up on
this mailing list or the IRC channel to discuss further:
http://community.opscode.com/chat/chef
Cheers,
Andrew.
On Fri, May 11, 2012 at 5:14 PM, Dan Adams < > wrote:Thanks for the reply. I feel like I might be missing something here. Not
having used rspec before, I'm having a slight problem getting my head around
how chefspec works/how it could be incorporated into my jenkins pipeline. Is
there a simple example out there somewhere because the documentation didn't
make any sense to me.
With regards to chef-minitest, the documentation for that seems to suggest
(unless I'm looking at the wrong thing) that its a report handler that can
run tests at the end of a chef run - in a similar approach to tools such as
chef-cucumber this means you have to first build an infrastructure to test
again - but as in my OP, ai have a pipeline that ends with a git repo of
code, not a built infrastructure with the code applied that I could test
against. So unless I'm missing something, chef-minitest couldn't help me
here? (as mentioned, I cannot go down the path of spinning up some VMs to
apply the cookbooks against for the purposes of testing)
Just to clarify, I'm looking to extend beyond lint tests on a copy of the
codebase, but without having to spin up VMs or similar to then test against.
It may be this tool doesn't exist at the moment?
Cheers
Dan
On 10.05.2012 22:44, AJ Christensen wrote:
chefspec and chef-minitest are both viable for this, but both require
#2 while delivering #1/#3
Cheers,
--AJ
On 11 May 2012 09:40, Dan Adams
< >
wrote:
Hi
I have been looking into options for creating a CI (continuous
integration)
pipeline for my Chef configuration. My CI server of choice is Jenkins,
and I
currently have a pipeline that looks like:
ruby syntax check -> ruby lint check -> chef syntax check -> chef lint
check
using the toolchain:
"ruby -c" -> "nitpick" -> "knife cookbook test" -> "foodcritic"
This gives me a pipeline that runs in under 1 minute for a relatively
large
repo, which is fast enough not to make people want to skip the process,
and
catches a lot of silly problems early.
However, there's still a lot of problems of one sort or another that pass
this chain but fail in one way or another in production. I'm looking for
a
programmatic way to prevent these additional problems by tagging
something
on to the end of my existing pipeline. Something where unit or
integration
testing might sit in a traditional CI pipeline.
[I know that a lot of people use vagrant, VMTH or toft or some other
system
to spin up a temporary VM or set of VMs at the end of their CI chain in
order to prove the recipes in the role that traditionally would be filled
by
integration testing. However, for environmental reasons, this is not an
option for me and I'd like to ignore that option as a solution for the
purposes of this discussion to save getting sidetracked please.]
What I'm looking for basically is something that:
1) provides near to or the same level of understanding as the chef server
API as to whether your chef config is sane
2) Ideally something drop-in that doesn't require writing individual
tests
for each new cookbook/recipe (a la cucumber-chef)
3) It must also be fast, under 1 minute to test a chef repo containing
hundreds of nodes and hundreds of cookbooks
I have no experience with it but it looks as though chefspec
(http://acrmp.github.com/chefspec/) might match at least requirement (1).
Any other suggestions for investigation?
Cheers
Dan
Archive powered by MHonArc 2.6.16.