Seemingly correct test not picking up values

[eugeneromero]

Description :
Hi!
I have a test which seems to be correct, but produces a weird result. It appears that terraform-compliance is chocking on a specific value, but I can't figure out why.

To Reproduce

1. This is the (abbreviated) TF code:

resource "azurerm_virtual_machine" "elasticSearchVM" {
  name = "elasticSearchVM"
  os_profile_linux_config {
    disable_password_authentication = true
    ssh_keys {
      key_data = "ssh-rsa mykey"
      path = "/home/es/.ssh/authorized_keys"
    }
  }
}

Which generates this (abbreviated) JSON:

{
  "address": "module.elasticSearch.azurerm_virtual_machine.elasticSearchVM",
  "mode": "managed",
  "type": "azurerm_virtual_machine",
  "name": "elasticSearchVM",
  "provider_name": "azurerm",
  "schema_version": 0,
  "values": {
    "name": "elasticSearchVM",
    "os_profile_linux_config": [
      {
        "disable_password_authentication": true,
        "ssh_keys": [
          {
            "key_data": "ssh-rsa mykey",
            "path": "/home/es/.ssh/authorized_keys"
          }
        ]
      }
    ],
  }
}

2. Nothing special, just ran terraform-compliance -f test/unit/ -p unit_test.json.

3. Run via Docker container.

4. Output:

Scenario: ElasticSearch VM linux config
        Given I have azurerm_virtual_machine defined
        When its address is module.elasticSearch.azurerm_virtual_machine.elasticSearchVM
        Then it must contain os_profile_linux_config
        And it must contain disable_password_authentication
        And its value must be true

Scenario Outline: ElasticSearch VM linux config ssh
        Given I have azurerm_virtual_machine defined
        When its address is module.elasticSearch.azurerm_virtual_machine.elasticSearchVM
        Then it must contain os_profile_linux_config
        And it must contain ssh_keys
        And it must contain <key>
        And its value must be <value>

    Examples:
        | key      | value                              |
			Failure: module.elasticSearch.azurerm_virtual_machine.elasticSearchVM (azurerm_virtual_machine) does not have key_data property.
        | key_data | ssh-rsa mykey                      |
          Failure: 
			Failure: module.elasticSearch.azurerm_virtual_machine.elasticSearchVM (azurerm_virtual_machine) does not have path property.
        | path     | /home/es/.ssh/authorized_keys |
          Failure: 

5. Here are two scenarios which I think should give the same result:

Scenario: ElasticSearch VM linux config
  Given I have azurerm_virtual_machine defined
  When its address is module.elasticSearch.azurerm_virtual_machine.elasticSearchVM
  Then it must contain os_profile_linux_config
  And it must contain disable_password_authentication
  And its value must be true

Scenario Outline: ElasticSearch VM linux config ssh
  Given I have azurerm_virtual_machine defined
  When its address is module.elasticSearch.azurerm_virtual_machine.elasticSearchVM
  Then it must contain os_profile_linux_config
  And it must contain ssh_keys
  And it must contain <key>
  And its value must be <value>

  Examples:
  | key  | value                              |
  | key_data | ssh-rsa mykey                  |
  | path | /home/esadmin/.ssh/authorized_keys |

Expected behavior :
Since the first test allows me to dig all the way into disable_password_authentication, I would also expect to be able to dig into ssh_keys.

Tested versions :

• <terraform-compliance version (terraform-compliance -v)>
  Old version 1.0.60 passed this test. Updated to 1.1.8, test fails.
• <terraform version (terraform -v)>
  Terraform v0.12.20

Additional context
Thanks for any help!

[eerkunt]

🤔 very interesting. Checking on this now.

Thanks for the issue 🎉

[eerkunt]

Found the problem. I was just thinking of a refactoring for a better code structure, and this issue just hits that spot directly.

Thanks for the issue again 🎉 I will fix it with the refactoring of th problematic step.

[eugeneromero]

@eerkunt amazing! Glad to see I was not missing anything obvious 😁 looking forward to the updated version. Thanks again!

[eerkunt]

Fixed it quickly for unblocking you. I will work on the bigger refactoring on the next releases.

Will release soon, waiting for tests to be passed.

[eerkunt]

Could you please have a try with 1.1.9 and let me know if it works for you ?

Should be in PyPi in few minutes.

[eugeneromero]

Thank you for the quick response! 1.1.9 does indeed solve the issue. Marking as solved. Thanks again and until next time! 😄

[ghost]

This issue's conversation is now locked. If you want to continue this discussion please open a new issue.