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.