verifier on GCP platform

[wyardley]

@aaron-lane: Figured this is different enough that I'll create a new issue; regarding some questions I had brought up in #263

[in test/integration/default/inspec.yml]:

name: inspec-gcp-integration-tests
inspec_version: '>= 2.2.10'
version: 1.0.0
depends:
  - name: inspec-gcp
    url: https://github.com/inspec/inspec-gcp/archive/master.tar.gz
supports:
  - platform: gcp

(so yes, I do have platform: gcp explicitly in the supported platforms).

% grep kitchen Gemfile.lock 
    kitchen-inspec (0.24.0)
      test-kitchen (~> 1.6)
    kitchen-terraform (4.0.1)
      test-kitchen (~> 1.23)
    test-kitchen (1.23.2)
  kitchen-inspec (~> 0.24.0)
  kitchen-terraform (~> 4.0)
  test-kitchen (~> 1.23)

My current kitchen.yml

driver:
  name: "terraform"
  command_timeout: 1800
  root_module_directory: test

provisioner:
  name: "terraform"

transport:
  name: exec

platforms:
  - name: local

# Note: this doesn't yet work
# However, you can converge, and then run:
# bundle exec inspec exec -t gcp:// test/integration/default
verifier:
  name: inspec

suites:
  - name: "default"

Based on the examples, it seems like something like this should work:

verifier:
  name: terraform
  systems:
    - name: local
      backend: gcp
      controls:
        - gke_cluster

% bundle exec kitchen verify 
-----> Starting Kitchen (v1.23.2)
$$$$$$ Running command `terraform version` in directory /Users/wby/git/terraform
       Terraform v0.11.10
       
$$$$$$ Terraform v0.11.10 is supported
bundler: failed to load command: kitchen (/usr/local/bin/kitchen)
KeyError: key not found: :connection_timeout
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:181:in `fetch'
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:181:in `block in transport_connection_options'
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:180:in `tap'
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:180:in `transport_connection_options'
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:111:in `configure_inspec_connection_options'
  /usr/local/lib/ruby/gems/2.4.0/gems/kitchen-terraform-4.0.1/lib/kitchen/verifier/terraform.rb:104:in `finalize_config!'

In this case, I'm running commands locally against the GCP APIs.

As reported elsewhere, and as used in their docs, this works fine for me:
bundle exec inspec exec -t gcp:// test/integration/default
[I did try setting user, host, etc. to nulls or empty strings, but that didn't seem to help]

I recognize this may end up not being an issue with kitchen-terraform itself, but is there a way to accomplish the equivalent of the above command but via kitchen-terraform's verifier?

[wyardley]

Update: removing the exec transport (obvious in retrospect) seems to have helped, and this now works the way I expect:

driver:
  name: "terraform"
  command_timeout: 1800
  root_module_directory: test

provisioner:
  name: "terraform"

platforms:
  - name: local

verifier:
  name: terraform
  systems:
    - name: local-gcp
      backend: gcp
      controls:
        - gke_cluster

[wyardley]

I think this resolves my question. I'm going to close, but feel free to add labels as necessary.

[aaron-lane]

@wyardley You've run in to some obsolete code in the Terraform verifier plugin which is dependent on the SSH transport plugin. It's an artefact from when when the Terraform verifier plugin depended on the InSpec verifier plugin. Unfortunately, the present test coverage fails to include the use case where the transport plugin does not adhere to the SSH interface. Sorry about that 😅.

InSpec has assumed a lot of the connection logic which was traditionally provided by different transport plugins which is why each verifier system includes an independent set of connection logic. I have thought about creating a Terraform transport plugin (#59) but I haven't reached a conclusion on what behaviour that will provide, especially considering that a long term goal is to remove the hard dependency on InSpec so that other test frameworks may be used with other plugins (#256).

[wyardley]

@aaron-lane No worries! Once I got rid of that transport line, everything works the way I had expected. The direct and indirect help is much appreciated.