knife community release plugin

gistfile1.md

This is idea brainstorming for a community plugin for releasing cookbooks per Opscode's current process. This would replace the functionality of the "cookbook site share" plugin that is built into Chef, as I believe the cookbook site plugins should use "community" rather than "cookbook site" and be a separate plugin instead of built into Chef and tied to its release cycle.

knife community release COOKBOOK VERSION

Assumes that the repository is release ready, e.g., the current HEAD is the commit that should be released, CHANGELOG is updated already, etc.

1. sets metadata version to the specified VERSION
2. makes a git commit with the release VERSION in the metadata
3. creates a git tag with the bare version, e.g. "1.0.1" not "v1.0.2"
4. pushes to the opscode (or other upstream as apropos) master branch, takes --remote argument as alternate, and pushes git tags
5. update the metadata version to a +1 development version, e.g. "1.0.2" to "1.0.3".
6. commits and pushes to master again with the development version

Command-line argument brainstorming:

--remote - the remote tracking repository that is "upstream" if it isn't origin. E.g., I use "opscode" for my forks of our cookbooks.

--version - the release version, if it shouldn't just be automatically incremented. The version should be even numbered per Opscode general release conventions.

--category - The category should be automatically determined by retrieving the category from the metadata from the community site API, if the cookbook exists.

Of course, this could be useful for other cookbook maintainers than just Opscode.

1. The current "site share" really only tarballs and uploads, right? It looks like you're bundling in a lot of git release process in this, is that overkill?
2. Not everyone follows the 'odd = dev; even = prod' version numbering scheme (I know I don't), should that be default? Or an option? Steps 5&6 generate more commits/pushes that way.
3. Is there a doc/site for the community site API?

And yes, not "could be useful" - "should be useful". :)

Hi Mike,

1. Yeah this is to enhance my workflow so I don't forget things like this
2. Sure, and I don't think it should be default. Maybe an option?
3. Yes, documentation on the wiki.

Follow-ups:

1. We seem to be missing uploading to the community site. That's an important step, no?
2. Do we want to be 'smart' and exclude any files that are listed in chefignore so they aren't included in the release package?
3. From #4 - pushing to upstream - maybe --remote is misleading, is --branch better?

1. Yes - I took that for granted :). We should definitely leverage the existing "cookbook site share".
2. I think the chefignore files are handled in "site share".
3. In git parlance, the remote is the remote repository, branch would be a branch on that repository, default is master. perhaps both options? or parse --remote name:branch like git does?