|
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
|
2 Comments
comments.show.hideNov 30, 2011
Andrew Crump
Couldn't make the summit, but I've made a start on something similar recently here: https://github.com/acrmp/foodcritic
Dec 08, 2011
Nathaniel Eliot
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:
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.