Closed tbugfinder closed 1 year ago
In addition - actually I'm not clear on how to convert the root_module_directory configuration if it set distinct for multiple suites.
< deprecated >:
suites:
- name: default
driver:
root_module_directory: test/fixtures/default
verifier:
systems:
@tbugfinder that is an odd error π€ can you please share the command from your Makefile that you used to invoke Test Kitchen?
Correct about fixing the deprecated configuration. Those two attributes just need to be moved to the new transport plugin!
Makefile executes
I don't understand how to configure the transport plugin for different systems / test cases. π€
Thanks so much for releasing the new version @aaron-lane! new version + inspec 5 is working great and required basically no changes.
I'm seeing the same error as well.
% bundle exec kitchen converge
-----> Starting Test Kitchen (v3.5.0)
Deprecated configuration detected:
root_module_directory
Run 'kitchen doctor' for details
[...]
-----> The doctor is in
$$$$$$ driver.root_module_directory is deprecated: use transport.root_module_directory instead
% bundle exec kitchen doctor
Deprecated configuration detected:
root_module_directory
Run 'kitchen doctor' for details.
-----> The doctor is in
$$$$$$ driver.root_module_directory is deprecated: use transport.root_module_directory instead
>>>>>> client 'terraform' does not exist
>>>>>> client 'terraform' is not executable
>>>>>> client 'terraform' does not exist
>>>>>> client 'terraform' is not executable
I updated
driver:
name: terraform
root_module_directory: test/integration
to
driver:
name: terraform
transport:
root_module_directory: test/integration
and then kitchen starts, but throws this error
$$$$$$ Validating the Terraform configuration files...
Success! The configuration is valid.
$$$$$$ Finished validating the Terraform configuration files.
$$$$$$ Building the infrastructure based on the Terraform configuration...
β·
β Error: No configuration files
β
β Apply requires configuration to be present. Applying without a
β configuration would mark everything for destruction, which is normally not
β what is desired. If you would like to destroy everything, run 'terraform
β destroy' instead.
β΅
>>>>>> Expected process to exit with [0], but received '1'
---- Begin output of terraform apply -auto-approve -lock=true -lock-timeout=0s -input=false -parallelism=10 -refresh=true ----
STDOUT:
STDERR: β·
β Error: No configuration files
β
β Apply requires configuration to be present. Applying without a
β configuration would mark everything for destruction, which is normally not
β what is desired. If you would like to destroy everything, run 'terraform
β destroy' instead.
Makefile executes
- bundle execute kitchen verify
- bundle execute kitchen destroy
I don't understand how to configure the transport plugin for different systems / test cases. π€
@tbugfinder it's configured in the same manner as the driver, provisioner, and verifier plugins: any provider configuration at the root level will apply to all Kitchen instances, and any provider configuration at the suites level will only apply to Kitchen instances based on the specific suites. You can review this project's own Kitchen configuration file for some examples.
I updated
driver: name: terraform root_module_directory: test/integration
to
driver: name: terraform transport: root_module_directory: test/integration
@wyardley you must specify the name of the terraform
transport plugin as well, or else it will use Test Kitchen's default ssh
transport.
I run into the following "error" message which looks like the deprecation message is forwarded as an argument to
kitchen
@tbugfinder are you able to share the complete Kitchen configuration and Makefile contents? I need to understand how to reproduce the issue that you are seeing.
Good point. I almost wasn't able to reproduce :-D
Within the Makefile we list all the kitchen instances and then use this as an input to execute verify/destroy.
As the listing builds invalid targets the error is subsequently added.
$$$$$$ Deprecated configuration detected:
root_module_directory
Run 'kitchen doctor' for details.
default-aws
replication-aws
bash-4.4#
<<Makefile>>
for suite in $$(bundle exec kitchen list --bare); do \
bundle exec kitchen verify $$suite || { bundle exec kitchen destroy $$suite; exit 1; }; \
bundle exec kitchen destroy $$suite; \
done
Also I had this question about the transport configuration as there are two systems configured. I only had to switch this to (replacing driver by transport):
suites:
- name: default
transport:
root_module_directory: test/fixtures/default
verifier:
systems:
- name: aws
backend: aws
reporter:
- cli
- json:reports/test/data/inspec/default.json
- name: replication
transport:
root_module_directory: test/fixtures/replication
verifier:
systems:
- name: aws
backend: aws
reporter:
- cli
- json:reports/test/data/inspec/replication.json
It looks like the deprecation message is sent to stdout just as the kitchen suites names and it cannot be filtered with redirecting 2>/dev/null.
Overall my bad and sorry for the noise.
@tbugfinder no worries! A lot of the behaviour around output is controlled by Test Kitchen itself so Kitchen-Terraform is limited in what it can change there.
Glad that you're up and running with v7.0.0!
Hello,
thank you very much for v7.0.0. While running some initial testing I run into the following "error" message which looks like the deprecation message is forwarded as an argument to
kitchen
.