chore: fix terraform/provider testdata to use latest terraform-provider

[defelmnq]

provisioner/terraform/testdata current version has been generated using outdated version of terraform-provider - with some parameters that are not relevant anymore, causing generate.sh to fail when trying to generate new data.

[johnstcn]

Have we validated that using version 1.x of the coder/coder provider still works after this change (in a template)?

[github-actions]

---

🚀 Deploying PR 16309 ...

[dannykopping]

I think we have a wider problem here, if we're concerned about compatibility.

$ grep coder/coder -A1 provisioner/terraform/testdata/**/*.tf -rh | grep version | sort | uniq -c
     20       version = "0.22.0"

We have sprawl across our modules, although they at least all evaluate to the latest version:

$ grep coder/coder -A1 **/*.tf -rh | grep version | sort | uniq -c
      2       version = ">= 0.11"
     11       version = ">= 0.12"
      4       version = ">= 0.12.4"
      9       version = ">= 0.17"
      7       version = ">= 0.23"

Our example templates are a bit all over the place; only 2 of the 18 example templates have any version constraint, and the two that do:

$ grep '"coder/coder"' -A1 examples/templates/**/*.tf -rh | grep version | uniq -c
      2       version = "~> 1.0.0"

will only get patch versions on the 1.0 release (source), i.e. nothing from 1.1 onwards.

I think this is a larger effort that we need to undertake.

We should either remove the version constraint from all modules/templates/testdata to always use the latest version (my preference), or add a linter to ensure they're all set to a specific version.

@defelmnq as an aside, where in this PR did you update the version to the latest? I can't see that in the changes; I just see the result.

[matifali]

Our example templates are a bit all over the place; only 2 of the 18 example templates have any version constraint, and the two that do:

We intentionally dropped the version constraint from example templates so that we could encourage the use of the latest providers. A better option would be to set version constraints that we auto-bump when new provider versions are released.

---

We should definitely drop support for v0.x.x of the provider but ensure we work with version v1.0.0 and above.

[johnstcn]

A better option would be to set version constraints that we auto-bump when new provider versions are released.

We could possibly couple this to the release workflow of the provider:

• After a release, clone the Coder repo at main
• Run a script that updates the provider version in the required places
• Commit and push a branch, and create a PR on coder/coder

WDYT @matifali ?

[matifali]

A better option would be to set version constraints that we auto-bump when new provider versions are released.

We could possibly couple this to the release workflow of the provider:

• After a release, clone the Coder repo at main
• Run a script that updates the provider version in the required places
• Commit and push a branch, and create a PR on coder/coder

WDYT @matifali ?

I agree. This should work. We can move this as an issue to coder/terraform-provider-coder.

[johnstcn]

For now:

• Run a local smoke-test with provider version 1.x to validate
• Address wider issue regarding provider versions in Automatically update provider version in coder/coder upon release terraform-provider-coder#335
• In parallel, address issue with provider data not being updated in CI for a long time (may also be resolved by above issue) -- for example, we could forcefully run the target to update the testdata on each time.

[defelmnq]

Smoke tested as discussed together - with the following steps :

✅ Started Docker in local using this version

✅ Defined the terraform-provider version to 1.0.0 using

    coder = {
      source = "coder/coder"
      version = "1.0.0"
    }

in the Docker template.

✅ Built the template, started a workspace, all good.

✅ Tried to use parameters that are deprecated in >2.0.0 based on that :

data "coder_git_auth" "example" {
  id = "example"
}

Worked, with a deprecated warning. (Failed later due to the example used)

[johnstcn]

Thanks for double-checking @defelmnq !