Open glensc opened 10 years ago
Run thor version:current
to create the file from current tag. The file should be in the released cookbook on supermarket.
and that requires newer thor? or something else?
$ thor version:current
/home/glen/Dropbox/cookbooks/github/certificate/Thorfile:1:in `require': cannot load such file -- thor/scmversion (LoadError)
from /home/glen/Dropbox/cookbooks/github/certificate/Thorfile:1:in `load_thorfile'
from /usr/share/ruby/vendor_ruby/1.9/thor/util.rb:155:in `class_eval'
from /usr/share/ruby/vendor_ruby/1.9/thor/util.rb:155:in `load_thorfile'
from /usr/share/ruby/vendor_ruby/1.9/thor/runner.rb:214:in `block in initialize_thorfiles'
from /usr/share/ruby/vendor_ruby/1.9/thor/runner.rb:213:in `each'
from /usr/share/ruby/vendor_ruby/1.9/thor/runner.rb:213:in `initialize_thorfiles'
from /usr/share/ruby/vendor_ruby/1.9/thor/runner.rb:32:in `method_missing'
from /usr/share/ruby/vendor_ruby/1.9/thor/command.rb:29:in `run'
from /usr/share/ruby/vendor_ruby/1.9/thor/command.rb:126:in `run'
from /usr/share/ruby/vendor_ruby/1.9/thor/invocation.rb:126:in `invoke_command'
from /usr/share/ruby/vendor_ruby/1.9/thor.rb:359:in `dispatch'
from /usr/share/ruby/vendor_ruby/1.9/thor/base.rb:440:in `start'
from /usr/bin/thor:6:in `<main>'
$ gem list |grep thor
thor (0.19.1)
thor-scmversion
, it should be in the Gemfile.
I don't think that adding this kind of 'magic' to create a simple version information is a good idea. When I wish to use a cookbook, I use the common download, checkout tag, upload system to drop it into Chef. Having these extra steps requires people to use Thor, install the gem required or run your bundle prior to uploading this cookbooks.
IMHO these are unnecessary steps when just uploading cookbooks. These are just my 2 cents though.
i totally agree with @TheSerapher. i just put correct version in my git clone and committed that to local repo
and if maintainer wishes to use such scripting, at least the VERSION file should be kept in git for cookbook users...
Okay, metadata has read long_description from an external file since forever. It is no more magic than that is. The released cookbook on Supermarket ships with a VERSION file, so this isn't an issue for most people. Just like metadata.json is not kept in source control, and treated as a release artifact, so is this version data. The authoritative source of the version becomes the tag in git. It is a tool that makes my maintenance of the cookbook easier, period.
Here is what I think about the issue for developers using the software directly from github. They need to check out the dependencies with bundler in the Gemfile. Why? Because, they should be running the included integration tests for Test-Kitchen, Linting with Rubocop or Foodcritic, or unit tests with Chefspec, when submitting pull requests.
Cookbook users can get released cookbooks, not the source versions, from the Supermarket. If one refuses to use the released version as an end user, and insists on using the source from Github when they are not developing a feature, then that doesn't really seem like my problem to slightly inconvenience them.
If I tag a commit with this tool, and then later commit to metadata.rb or an external VERSION file, then the tag will no longer match the record of authority (i.e. the tag). Whereas, with the tool bumping and tagging are done synchronously. So, no that defeats the whole purpose of the tool to keep the file in source control.
So in the end it's just another way of releasing cookbooks. And I agree on the site download instead of source. GitHub has just been a very convenient way for us to install new versions. Maybe it's time to switch to Supermarket and get used to a new workflow ;-)
And completely agree on ruining bundle as a cookbook dev.
using this cookbook from git checkout causes knife upload to fail. i think it's bad practice to keep the VERSION file in
.gitignore
and not version track it at all. (how do i know what version i'm at?)