I’m having a tough time coming up with a way to version chef cookbooks that
makes sense across multiple use cases. I’ve been going around in circles
with this for, well quite honestly, years now.
We originally used Thor ScmVersion but that caused issues when a developer
and Jenkins both tried to bump a cookbook version. I think it was because
each had their local git copies and when git was pushed upstream it caused
a conflict of some sort.
I tried using the knife sport plugin. The issue with that is if jenkins
calls knife spork and that increases the version number in the VERSION
file, that VERSION file needs to be committed back to git. if your building
your cookbook on a git commit, then jenkins builds it again, and again and
again. You get the idea. If you don’t commit the VERSION file back to git,
well then if a developer tries to work with the cookbook their VERSION is
out of sync.
I also tried just having Jenkins write the build number to the VERSION file
and have metadata.rb source from that. That’s fine if only Jenkins ever
needs to test and upload the cookbook. However, if a developer also needs
to work with the cookbook and upload it to say a chef supermarket server
where cookbooks that depend on that can get it from, he is again out of
sync with Jenkins.
How are people solving this issue? It’s never talked about. How about a
script that polls an AWS DynamoDB table and using the cookbook name as a
key, keeps a counter. Each time it’s called it returns the number and bumps
it by one. It wouldn’t matter where it was called from in this case, either
from a developer, Jenkins, or anywhere else.
Doug.