Implement chef test unit command that can run ChefSpec

[smith]

In order to run my ChefSpec tests I have to use /opt/chefdk/embedded/bin/rspec. This is weird. It would be nice if I could just run chefspec (as some kind of alias to chefdk's rspec) or a command like chef test unit.

[jtimberman]

👍 for chef test unit or even chef spec.

[lamont-granquist]

we could easily put rspec in /opt/chefdk/bin and setup a symlink from /usr/bin to there, but i worry a bit about it getting into fights with rspec installed into system gems (more so that i worry about any of the binaries that are specific to the chef ecosystem that we have in there so far).

[danielsdeleo]

Running tests via the chef command is already on the roadmap.

[sethvargo]

So, ChefSpec is just RSpec. I'm generally 👎 on a separate binary called chefspec or a magical command called chef spec run. I think that further obfuscates that it's just RSpec.

[smith]

@sethvargo I totally understand that, but when we put "includes ChefSpec" on the tin and then hide it in the embedded directory and tell people to f with their paths and what-not, it doesn't feel like a good experience.

@lamont-granquist already mentioned the possible problems with just putting rspec in /opt/chefdk/bin, so what's a better solution that finds some middle ground here?

I just want a command that's easily and reliably available to run my unit specs on my cookbooks. It can be called sethspec for all I care.

[lamont-granquist]

ln -sf /opt/chef/embedded/bin/rspec /usr/bin/sethspec

must.... resist... urge... to... submit... patch...

i think we should probably have a 'chef run ' that just throws /opt/chef/bin + /opt/chef/embedded/bin in the PATH and then execs the command (and sets ruby env vars to escape rvm, etc).

i don't think that's the final solution, but this isn't likely to be the first time we hit this, and it gives us a stock answer in the general case.

could also be 'chef exec ' or other names...

[danielsdeleo]

I wrote some thoughts about that here: #16

[sethvargo]

@lamont-granquist I really like that chef run. I think it is the least resistance and will work for any gem installed via chef gem.

[lamont-granquist]

I like dan's thoughts about having commands to either drop into .bashrc and/or to setup .bashrc to manage the PATH as well.

But managing state like that will probably cause issues, and i still kinda like the idea of just executing an arbitrary command with the right environment, which we can get right more often than not.

I'd sort of like the all-of-the-above solution -

• way to exec arbitrary commands with the right environment chef run
• command to add to .bashrc to setup environment chef init?
• command to automagically add that command to .bashrc chef setup?
• command that invokes chefspec specifically chef test unit

[sethvargo]

I personally think chef run is:

• the path of least resistance
• super testable
• "dynamic"

With the .bash* options, what if I use ZSH? Or FISH? And that's MY .bashrc - you're basically telling me that Chef now owns my laptop, and I'm not sure I'm on board with that.

On the flip side, if I have no idea what shell I want to use, you've added an additional layer of abstraction. What the heck is a .bashrc and why are things being added?

I think the profile approach just isn't sustainable. Like @lamont-granquist said, maintaining that state will be hard and a source of headache. Just a sample ideaish thing of what I'm thinking:

#!/bin/sh
GEM_HOME=/opt/chefdk/embedded/lib/ruby/gems/whatever GEM_ROOT=/some/path $@

Just like chef gem does magic inside of the ChefDK, I'd expect chef exec to run the gems inside ChefDK.

Just a note - I'm preferential to chef exec because of it's similarity to bundle exec. chef run seems like it would refer to the Chef Client, and that might be confusing.

[lamont-granquist]

Yeah, I was just not sure if there was a better logical feature for chef exec in the future or not. If that is the right thing for chef exec to do then we should probably name it that.

[lamont-granquist]

And yeah, from the perspective of, say, answering a question on stack exchange. I don't really want to have to walk the user through setting up bash/zsh/fish/whatever first. If I can just have them fire off a chef exec and be guaranteed it works, then i want to be able to do that. Then I can follow that up with 'if typing chef exec all the time is a PITA, then you can... blah blah blah..' which they can ignore if they don't care...

[danielsdeleo]

@sethvargo I don't think supporting bash and zsh is hard, and anyone using any other shell will probably be a power user who can get a path into their PATH with no problem. I don't think chefdk should modify your shellrc, but it's pretty easy to put "add exec $(chef init-shell)" in the install instructions. This will put us in a good spot to add shell completion stuff, too, and no one will ever have to type chef exec bundle exec poo if they don't want to.

That said, I think a chef exec command is fine and probably good enough for people who don't frequently need to use executables installed to ChefDK.

[jtimberman]

I like chef run to run arbitrary "chef gem-installed" commands with the right Ruby environment, without munging anything in the shell environment. I think that will also be maximally cross-platform for Windows users.

[lamont-granquist]

There's a WIP patch for the chef exec idea. You can leave feedback on that approach there.

[ivey]

I like chef exec but still think there's value in a top-level chef test command that does all the tests: chefspec, tk, rubocop, foodcritic

[lamont-granquist]

Yeah, I think we agree to do all-the-things. chef exec plus chef shell-init, and chef test has always been on the roadmap.

[sersut]

chef exec is implemented now. chef shell-init is coming soon. Therefore I've changed the title of this issue to be "Implement chef test unit command that can run ChefSpec".

[danielsdeleo]

Added chef shell-init #63

[jperry]

what is the preferred way to run chefspecs if I only have chefdk installed? Right now providing the full path to where the gem was installed is my only option. Thanks!

[danielsdeleo]

@jperry At the moment, either chef exec rspec or using chef shell-init (see README) will configure your environment to use chef-dk as your primary ruby. This requires ChefDK 0.2.0, which is built and in our package archive, but isn't yet linked on the downloads page (that should happen later today).

[jperry]

@danielsdeleo - ah great. Thanks! I am grabbing this one: https://opscode-omnibus-packages.s3.amazonaws.com/mac_os_x/10.9/x86_64/chefdk-0.2.0-1.dmg

[jperry]

@danielsdeleo - seems to have issues after running rspec with 0.2.0

> chef exec rspec
/opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:118:in `require': unable to find a version of 'rspec' to activate (Gem::LoadError)
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chefspec-3.4.0/lib/chefspec.rb:1:in `<top (required)>'
    from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `require'
    from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
    from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:144:in `require'
    from /Users/jperry/workspace/bithub/cookbooks-org/bce_dangerzone/spec/spec_helper.rb:1:in `<top (required)>'
    from /Users/jperry/workspace/bithub/cookbooks-org/bce_dangerzone/spec/recipes/default_spec.rb:1:in `require_relative'
    from /Users/jperry/workspace/bithub/cookbooks-org/bce_dangerzone/spec/recipes/default_spec.rb:1:in `<top (required)>'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/configuration.rb:1057:in `load'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/configuration.rb:1057:in `block in load_spec_files'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/configuration.rb:1057:in `each'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/configuration.rb:1057:in `load_spec_files'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/runner.rb:97:in `setup'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/runner.rb:85:in `run'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/runner.rb:70:in `run'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/lib/rspec/core/runner.rb:38:in `invoke'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/rspec-core-3.0.2/exe/rspec:4:in `<top (required)>'
    from /opt/chefdk/embedded/bin/rspec:23:in `load'
    from /opt/chefdk/embedded/bin/rspec:23:in `<main>'

my Path

/opt/chefdk/bin:/Users/jperry/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/packer

[danielsdeleo]

The root cause of this is that chefspec 3.4.0 requires rspec ~> 2.14, but running rspec on the command line is activating rspec 3.x. If you don't have a need to use older chefspec, you can chef gem install chefspec to get the newer version that's compatible with rspec 3, or else you probably need to use bundler. If you go the bundler route, I'd recommend trying chef shell-init otherwise you'd have to chef exec bundle exec rspec which makes me throw up in my mouth a little.

[jperry]

thanks I'll give that a try.

[jperry]

@danielsdeleo - did the chef gem install chefspec and now I get this when running chef exec rspec.

/opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `exec': No such file or directory - rspec (Errno::ENOENT)
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/exec.rb:27:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/command/base.rb:57:in `run_with_default_options'
    from /opt/chefdk/embedded/apps/chef-dk/lib/chef-dk/cli.rb:66:in `run'
    from /opt/chefdk/embedded/apps/chef-dk/bin/chef:25:in `<top (required)>'
    from /usr/bin/chef:41:in `load'
    from /usr/bin/chef:41:in `<main>'

I tried doing chef shell-init bash and when I do that it can't find rspec. Any other ideas?

[jperry]

Update: I wasn't running the chef shell-init with eval which was my second problem. Now after running eval "$(chef shell-init bash)", running rspec now works. The first still doesn't work.

[danielsdeleo]

@jperry Can you file a new issue for this, since it's only tangentially related to adding a chef test unit subcommand? Also, in your last statement, it's not clear what you mean by "The first still doesn't work." In the new ticket, can you recap your original problem, what you did to make progress, and what error you're still experiencing?

[jperry]

sure will do.

[charlesjohnson]

It's still subject to change but you can see commits to delivery-cli about prototyping something very close to this functionality now in chef-boneyard/delivery-cli@51974bb .