Check for .kitchen.yml before creating .kitchen

[robertlabrie]

Description

Check for .kitchen.yml before creating .kitchen. I'm used to being able to run rubocop and foodcritic from wherever in the tree, I can't with testkitchen (fine) and it blows up with the missing .kitchen.yml (fine) but after all that I still have to rm -rf .kitchen because it creates one. Would be nice if that wasn't the case.

Kitchen Version

Tell us which version of test-kitchen you are using (kitchen --version).

Test Kitchen version 1.8.0

ChefDK Version

If you are running test-kitchen via ChefDK, chef --version will provide additional relevent version details.

Chef Development Kit Version: 0.12.0
chef-client version: 12.8.1
berks version: 4.3.3
kitchen version: 1.8.0

Ruby Version

If you are not using test-kitchen via ChefDK, please provide the output of ruby --version.

ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]

Platform Version

MacOSX some cat or mountain or park or somesuch. I didn't pick this computer.

Replication Case

run kitchen converge in a directory without a .kitchen.yml file

Kitchen Output

The relevant output of the test-kitchen run or a link to a gist of the entire run, if there is one.

The debug output (kitchen -l debug) may be useful, but please link to a gist, or truncate it.

Please do not paste the full run out put here. If the full output would be useful, link to it in a gist.

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::UserError
>>>>>> Message: Kitchen YAML file /Users/robertlabrie/Documents/code/cookbooks/tropo-ops-jenkins-slave/test/integration/default/bats/.kitchen.yml does not exist.
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

NOTE:

This repository is for core issues with the Test-Kitchen framework, so if the issue is with a plugin you may be referred to file the issue with the appropriate plugin.

[jjasghar]

There are a couple things here.

First, we assume you want to run the kitchen commands in your directory that has the .kitchen.yml.

Example: http://kitchen.ci/docs/getting-started/running-verify

On the other hand, i wrote a wrapper in Emacs to do this: https://github.com/jjasghar/test-kitchen-el I don't think this will be fixed.

[robertlabrie]

So whats the benefit of creating the .kitchen working directory if no .kitchen.yml exists?

[jjasghar]

It's where it dumps the logs for kitchen-vagrant or the like.

[robertlabrie]

Right, but if there was no YML there was literally nothing for kitchen to do right? So it doesn't need that working directory in that case?

[jjasghar]

Then why are you running test-kitchen? You need a configuration to run it right?

[robertlabrie]

OK, but if I run it in the wrong directory by mistake, blowing up with "No .kitchen.yml" is fine, I just don't understand why test-kitchen needs to leave behind a .kitchen directory for me to remove.

[jjasghar]

Ah i get it now. If you'd like to put in a PR to fix this that would be awesome, otherwise I think we have other priorities at this time.

Thanks for the report though!

[smurawski]

@robertlabrie while the most common location for a .kitchen.yml is in the root of the project dir, you can actually point to it (or a kitchen.local.yml) via environmental variable which can change the requirement for where the physical .kitchen.yml is. So, as JJ said, a PR would be great but it's unlikely to be a high priority for us.

[cheeseplus]

Also we don't autoremove the .kitchen because you could have other instances that were converged prior in the folder that'd you'd want the state of in case had KITCHEN_YAML set to something other than default inadvertently and didn't want to lose that state information.

[robbkidd]

I just don't understand why test-kitchen needs to leave behind a .kitchen directory for me to remove.

Test Kitchen's default log configuration writes to {current-working-directory}/.kitchen/logs/kitchen.log. So, aside from any kitchen-managed virtual machine state information—which as has been mentioned doesn't exist if there is no configuration—the directory is created so that the error about missing configuration can get written to a log.

> rm -rf .kitchen*

> tree .kitchen
.kitchen [error opening dir]

> kitchen list
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::UserError
>>>>>> Message: Kitchen YAML file /Users/rkidd/work/test-kitchen/.kitchen.yml does not exist.
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

> tree .kitchen
.kitchen
└── logs
    └── kitchen.log

> cat .kitchen/logs/kitchen.log
E, [2018-02-26T15:52:40.318080 #93436] ERROR -- Kitchen: ------Exception-------
E, [2018-02-26T15:52:40.318254 #93436] ERROR -- Kitchen: Class: Kitchen::UserError
E, [2018-02-26T15:52:40.318306 #93436] ERROR -- Kitchen: Message: Kitchen YAML file /Users/rkidd/work/test-kitchen/.kitchen.yml does not exist.
E, [2018-02-26T15:52:40.318330 #93436] ERROR -- Kitchen: ----------------------
E, [2018-02-26T15:52:40.318358 #93436] ERROR -- Kitchen: ------Backtrace-------
[ ... backtrace snipped ...]

Autoremoving would Be Bad, as @cheeseplus said. Not logging would, I think, also Be Bad.

[cheeseplus]

Thanks for pointing this out @robbkidd somehow I'd totally overlooked that is where we store logs and as such I am entirely in agreement - autoremoving is risky but not logging is way worse. Given the ubiquity in CI pipelines this is indeed the ideal behaviour in the case of needing to troubleshoot, as such I'm closing this one as designed.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.