Skip to content

Instantly share code, notes, and snippets.

Created August 20, 2012 02:32
Show Gist options
  • Save jtimberman/3399547 to your computer and use it in GitHub Desktop.
Save jtimberman/3399547 to your computer and use it in GitHub Desktop.
knife community release plugin

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.

Copy link


  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?

Copy link

  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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment