[chef] Re: Re: Re: Re: Re: CI job for cookbook version increment + upload

[David Petzel < >]

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

On Tue, Aug 6, 2013 at 10:13 PM, Jesse Mauntel < " target="_blank"> > wrote:

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. 

It's working out quite nicely for us.