Strainer vs Rake

We’re currently working with a chef-repo and I’m wondering what the better solution is, using a Rake or Strainer for testing.

I’m aware that cookbook-repo’s are preferred, but we’re unable to go that route at this time.

Possible options:

  • Repo-level Rakefile
  • Individual Rakefiles per cookbook directory
  • Both repo-level (global testing) and cookbook-level (single cookbook tests) Rakefiles
  • Repo-level Strainerfile
  • Individual Strainerfiles per cookbook directory

I can see advantages for each, wondering what other’s thoughts/preferences/experiences are.

Additional comments/thoughts:

  • Strainer provides complete isolation by copying a cookbook to a $SANDBOX directory.
  • Repo-level Rakefile would run all tests (including running specs in parallel with parallel_specs)

Thanks!
Curtis

I just wanted to bump this thread to see if there were any new thoughts.

Curtis

On Apr 15, 2014, at 11:56 AM, Stewart, Curtis <cstewart@momentumsi.commailto:cstewart@momentumsi.com> wrote:

We’re currently working with a chef-repo and I’m wondering what the better solution is, using a Rake or Strainer for testing.

I’m aware that cookbook-repo’s are preferred, but we’re unable to go that route at this time.

Possible options:

  • Repo-level Rakefile
  • Individual Rakefiles per cookbook directory
  • Both repo-level (global testing) and cookbook-level (single cookbook tests) Rakefiles
  • Repo-level Strainerfile
  • Individual Strainerfiles per cookbook directory

I can see advantages for each, wondering what other’s thoughts/preferences/experiences are.

Additional comments/thoughts:

  • Strainer provides complete isolation by copying a cookbook to a $SANDBOX directory.
  • Repo-level Rakefile would run all tests (including running specs in parallel with parallel_specs)

Thanks!
Curtis

Many people do not put their cookbooks in chef-repo, opting to create a new
repository for each cookbook like the opscode-cookbooks organization on
GitHub, and use Chef Spec to test their cookbooks:

On Tue, Apr 22, 2014 at 6:19 AM, Stewart, Curtis cstewart@momentumsi.comwrote:

I just wanted to bump this thread to see if there were any new thoughts.

Curtis

On Apr 15, 2014, at 11:56 AM, Stewart, Curtis cstewart@momentumsi.com
wrote:

We’re currently working with a chef-repo and I’m wondering what the
better solution is, using a Rake or Strainer for testing.

I’m aware that cookbook-repo’s are preferred, but we’re unable to go
that route at this time.

Possible options:

  • Repo-level Rakefile
  • Individual Rakefiles per cookbook directory
  • Both repo-level (global testing) and cookbook-level (single cookbook
    tests) Rakefiles
  • Repo-level Strainerfile
  • Individual Strainerfiles per cookbook directory

I can see advantages for each, wondering what other’s
thoughts/preferences/experiences are.

Additional comments/thoughts:

  • Strainer provides complete isolation by copying a cookbook to a
    $SANDBOX directory.
  • Repo-level Rakefile would run all tests (including running specs in
    parallel with parallel_specs)

Thanks!
Curtis

we use a single repo for all our cookbooks (in site-cookbooks directory),
and we also use lots of community cookbooks (managed by berkshelf). we use
only rake ( rake rubocop, rake foodcritic, rake spec, rake cucumber). We
also use chefspec (in fact chefspec, rubocop, foodcritic are the only tests
we run locally) against our wrapper cookbooks. Most of the wrapper
cookbooks uses search, databags etc.

if you are maintaining lot of independent cookbooks, strainer might be a
good solution, as the whole test process takes less time and independent.
while for us, testing means unit testing in isolation (but against a set of
cookbooks) and integration testing as whole (which is time consuming). A
popular way to address this is by offloading the whole thing in CI server
and breaking them down into individual stages , establish dependencies etc.
this enables faster feedback (like dont run specs if lint fails, or dont
deploy if integration test fails etc), and for this, rake was more suitable
for us (independent tasks, semantically same as any other ruby projects,
rake tasks are pre-baked in almost all ruby tools etc).

again, if you plan to take the individual repo per cookbook, strainer can
be very useful.
also, given strainer is fairly light weight (and ships its own rake tasks),
you can always keep both and see how it works,
regards
ranjib

On Tue, Apr 22, 2014 at 10:03 AM, Josiah Kiehl bluepojo@gmail.com wrote:

Many people do not put their cookbooks in chef-repo, opting to create a
new repository for each cookbook like the opscode-cookbooks organization on
GitHub, and use Chef Spec to test their cookbooks:
GitHub - chefspec/chefspec: Write RSpec examples and generate coverage reports for Chef recipes!

On Tue, Apr 22, 2014 at 6:19 AM, Stewart, Curtis cstewart@momentumsi.comwrote:

I just wanted to bump this thread to see if there were any new thoughts.

Curtis

On Apr 15, 2014, at 11:56 AM, Stewart, Curtis cstewart@momentumsi.com
wrote:

We’re currently working with a chef-repo and I’m wondering what the
better solution is, using a Rake or Strainer for testing.

I’m aware that cookbook-repo’s are preferred, but we’re unable to go
that route at this time.

Possible options:

  • Repo-level Rakefile
  • Individual Rakefiles per cookbook directory
  • Both repo-level (global testing) and cookbook-level (single
    cookbook tests) Rakefiles
  • Repo-level Strainerfile
  • Individual Strainerfiles per cookbook directory

I can see advantages for each, wondering what other’s
thoughts/preferences/experiences are.

Additional comments/thoughts:

  • Strainer provides complete isolation by copying a cookbook to a
    $SANDBOX directory.
  • Repo-level Rakefile would run all tests (including running specs in
    parallel with parallel_specs)

Thanks!
Curtis