We manually update the version number with every change to the cookbook. Then, we have a Jenkins job looking at each cookbook’s git repo and the build triggers on any change to the repo. In each job we run the following:

clone repo

bundle install

foodcritic linting

custom linting (that we haven’t yet migrated to foodcritic)

kitchen destroy

kitchen test

grep the version number from the metadata file and store it in a variable

using the version variable, check and see if there is an existing git tag with the same name, if not, git tag and git push, then upload the cookbook to the chef server via berks upload

The nice thing is that any fail along the way prevents an upload to the chef server.

We do something very similar. We so far have opted for the manual version
bump, but CI reads the version and does all the tagging and auto-uploading
magic.

For us, we’ve discussed the auto version bump vs manual bump many times and
I’d say we are still undecided on what is best. At the end of the day the
main reason that we currently do the version bump manually rather than
letting CI do it all stems around CHANGELOG.md. We wanted to have clear and
concise change log entries and not simply depend on a dump of commit
messages. Consumers of our cookbooks have a very wide range of experience
with both Chef and Ruby, so we try to include a large amount of information
in the change log entry (IE the GitHub issue the release is addressing,
what the change is doing, and any gotchas you need to look out for)

If we had a solution for keeping CHANGELOG entries in sync with
automatically generated versions we would probably move to the auto
increment model as well

We manually update the version number with every change to the cookbook.
Then, we have a Jenkins job looking at each cookbook’s git repo and the
build triggers on any change to the repo. In each job we run the following:

clone repo

bundle install

foodcritic linting

custom linting (that we haven’t yet migrated to foodcritic)

kitchen destroy

kitchen test

grep the version number from the metadata file and store it in a variable

using the version variable, check and see if there is an existing git
tag with the same name, if not, git tag and git push, then upload the
cookbook to the chef server via berks upload

The nice thing is that any fail along the way prevents an upload to the
chef server.