[chef] Re: Chef CI Pipeline

[Dan Adams < >]

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