Cookbook CI with
Who Am I?
• "zts" most places on the internet
• Mostly Ops, Background, Mostly
• Co-founder Elastera
Who Are You?
• foodcritic, chefspec, test-kitchen
• Get things right
• Keep things right
• System for running actions on every commit
• Identify problems early
• Jenkins, GoCD, TravisCI, Wercker, etc
• Good Chef Cookbook
Why Not Jenkins?
• XML, so much XML
• Automation is not a joy
• Install Jenkins & Plugins
• Create jobs
• Run commands and scripts
• Cooking With Jenkins
• ...and Kitchen, and Docker
• Federated Jenkins with Chef
• Install Plugins
• Configure Plugins
• Configure Jenkins
• No dependency resolution
• Restart may be required
• XML :(
• ...containing module version strings :((
• Hold nose and use cookbook_file
• Job DSL plugin
• Jenkins Job Builder
And after publish?
• That's why this is Part 1...
• Warnings plugin :)
• XML config :(
• yarjuf gem
• Publish JUnit test result report
• Matrix jobs
• EnvInject and AnsiColor plugins
• upload to Chef server
• record version as artifact
• curl -s https://jenkins.example/job/berks-upload/
Gluing it together
• Publish Artifact
• Copy Artifact
• Build Pipeline
• Build Pipeline plugin
• Build Graph View plugin
• Build Flow DSL
• ...and more
• JUnit output from serverspec
• View most recent run of all pipelines
Not the whole story...
• Testing a set of cookbooks
• Testing multiple nodes
• Promoting releases
• Not that hard to get started
• Immediately valuable
• Share your work!
Yes, we’re hiring.
Let’s get the “hands up” out of the way…
Who tests their cookbooks, chefspec and/or kitchen?
Who practices TDD for their cookbooks?
Who automatically runs tests on commits?
Not here to sell you on TDD, but it’s worth trying if you haven’t. Can encourage better design, as well as building a library of useful tests.
Addresses a problem on large, shared codebases - parallel streams of activity, on branches, taking a lot of effort to merge. Not such a huge problem on single cookbook repo’s (in my experience).
However, the tooling to support this is useful.
With a good set of tests, prevents a whole class of errors caused by haste/impatience/divergent dev envs/etc.
Also worth mentioning - pipelines are something of an afterthought
Early this year, I demonstrated how to use Chef to configure Jenkins to run cookbook tests. This demonstrated some of the things I’m using today, but it was pretty rough. It was already due for an update two weeks after it was published (thanks to a new Jenkins cookbook), and I haven’t gone back to it yet…
Meanwhile, Eric Helgeson wrote a great post (with example cookbook) showing how he was using Jenkins. This includes groovy scripts for configuring authentication, and use of the Jenkins DSL plugin (which we’ll come to later). This motivated me to have another crack at the problem.
Add slides with examples of each
This needs to be a better way to solve this, but it wasn’t immediately apparent and pragmatism triumphed.
Idempotent? Well, you’ll get the same result but it will run every time…
If you’ve used these tools, you’ll know that foodcritic is very fast, chefspec is relatively fast, and kitchen tests are relatively slow. If your chefspec tests fail, you won’t even bother running Kitchen. Only if everything passes will you publish that commit to the Chef server.
Why not use kitchen parallel runner? Documented as intended for interactive use. Hard to read interleaved output.
What’s an artifact? For compiled languages, a build step compiles the source code, the resulting artifact is passed to subsequent jobs. In my pipeline, the primary artifact is Berksfile.lock
Others? Build Graph(?), Build Flow DSL (?), etc
Subjects for a later talk…
Sharing useful nuggets makes it easier for others to get started and contribute. Special thanks (again) to Eric Hegelson for this.
Add contact details