Skip to end of metadata
Go to start of metadata


Session Title:

Convener:

Tim Dysinger

Participants:

Sean Escriva
Jesse Nelson
Nathaniel Eliot

Summary of discussions:

  • Round trip to chef server to test cookbooks is expensive
  • It is possible to push broken code to the server
  • Would be nice to check things for correctness before upload
    • Is our Ruby code valid?
    • Do our resource blocks & attributes validate against their specs?
    • Basic Json syntax checking
    • Do we have at least default attributes for everything?
  • Would be nice to be able to run a partial chef run (one cookbook or even one resource)
  • Lint checking should be on by default with a flag to turn off
  • Don't throw away all edits to a node when the json isn't quit right

What will we do now? What needs to happen next?

Let's create a basic lint check & continually improve it



Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 30, 2011

    Couldn't make the summit, but I've made a start on something similar recently here: https://github.com/acrmp/foodcritic

  2. Dec 08, 2011

    In my absence at InfoChimps, Flip channeled his frustration at this problem into a couple of tools. The first is the cookbook munger, which sounds like a solid basis for a linter:

    This script reads the actual content of a cookbook – actually interpreting the metadata.rb and attribute files, along with recipes/resources/etc files' headers – and re-generates the metadata.rb and README files.

    The second is a Vagrant-based setup for development. It uses a local chef-server VM, a target VM, a shared drive, and a watchr script to push every change into the target VM as quickly as possible after its made. It's a heavier-weight solution, but can help with deeper iterative debug loops that a linter won't. Contact me (temujin9@infochimps.org) if you have an interest, and I'll work on pushing releasing it up the priority queue.