Inconsitancy with Provider version between github-action/terraform-docs

[Stretch96]

Describe the bug

With a provider version defined like this:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.25.0"
    }
  }
}

Running terraform-docs locally, it produces:

| <a name="provider_azurerm"></a> [azurerm](#provider\_azurerm) | 3.25.0 |

However, the GitHub action then wants to add in the >=:

| <a name="provider_azurerm"></a> [azurerm](#provider\_azurerm) | >= 3.25.0 |

Environment information

• terraform-docs version (use terraform-docs --version): terraform-docs version v0.16.0 darwin/arm64
• OS (e.g. Windows, MacOS): MacOS
• Action version: terraform-docs/gh-actions@v1.0.0

[jonathanio]

I've noticed this one myself over the last few days, and I think it's to do with the initialisation of the configuration. If it's not initialised, which isn't normally the case for me as I just run terraform-docs inside its own job, then it gives you the version constraint configured. If the configuration is initiated, you get the currently configured provider version.

I wonder if we should be using the install provider version at all. If this is documentation, it must be best to use the configured constraints by default. Or can it be a configurable option, so that we can use the version inside the .terraform.lock.hcl file for root configurations, or only use the version constraints configured for modules and examples?

[Stretch96]

Interestingly, I can't reproduce locally what is happening in GitHub actions - Wether or not terraform init has been ran.

[dmccaffery]

This is caused by a .terraform.lock.hcl that is not checked into source control. When the lockfile exists, terraform-docs parses it to determine the provider version. If you are building reusable modules, you probably want the following in .terraform-docs.yaml:

settings:
  lockfile: false

[Stretch96]

Ohhh, didn't realise we hadn't committed that ... wondered why it was just one of our projects Lol

Ta @dmccaffery

I'll test and close the issue 👍

[Stretch96]

Yup, committing the lock file has fixed this for us 👍